From lukeh at padl.com Thu Jan 1 05:36:55 2009 From: lukeh at padl.com (Luke Howard) Date: Thu, 1 Jan 2009 21:36:55 +1100 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 In-Reply-To: References: Message-ID: On 01/01/2009, at 3:43 AM, Love H?rnquist ?strand wrote: > Sam, Luke, > > In heimdal I use KRB5_PRINCIPAL_UNPARSE_NO_REALM for the logon name, > and not SHORT name. OK, fixed in r21656. -- Luke From lukeh at padl.com Thu Jan 1 08:03:07 2009 From: lukeh at padl.com (Luke Howard) Date: Fri, 2 Jan 2009 00:03:07 +1100 Subject: Session key extraction In-Reply-To: <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> Message-ID: > Two additional APIs are defined, gssspi_set_cred_option() (which sets > an attribute on a credential) and gssspi_mech_invoke() (which is a > catch-all context/credential-handle-less mechanism for invoking a > mechanism-specific API). I should add some rationale as to why gssspi_mech_invoke() exists, as I almost forgot this morning (and ended up deleting and then reinstating a bunch of code). On some platforms, applications might link against the mechanism plugin itself to get mechanism-specific APIs. This happens on OpenSolaris (where the Kerberos mechanism is built dynamically), however it is not portable; in particular, on Darwin, libraries and loadable modules not interchangeable. Instead, one can place mechanism- specific API in a separate library; that library can, internally, use gssspi_set_cred_option(), gssspi_mech_invoke(), etc, to call into the mechanism without linking against it. So, mechglue might live in libgss[api]; mechanism-specific API in libgssapi_somemech; and the mechanism itself in mech_somemech. gssspi_mech_invoke() thus allows a way to modify internal mechanism- state without linking against the mechanism (for APIs such as krb5_gss_use_kdc_context()). The alternative of modifying that state using, say, weak symbols, is less portable. There is no requirement the mechanism provide mechanism-specific functionality through a wrapper library, although it is intended that the APIs prefixes with gssspi are only used by such a library. For SSPI session key extraction, for example, the application will call gss_inquire_sec_context_by_oid(GSS_C_INQ_SSPI_SESSION_KEY). Recall gss_set_sec_context_option(), gssspi_set_cred_option(), etc, are necessary not only for this but also to unwrap context and credential handles, thus supporting stacked mechanisms. Note there's presently no support in the Makefile for building the Kerberos mechanism dynamically. For ABI compatibility, we'll have to support both mechglue and mech_krb5 in libgssapi_krb5 for some time to come, and I haven't had time to do the necessary Makefile magic to support both types of builds. Steps for the interested reader: (a) build gssapi/mechglue as libgss[api] (b) build gssapi/spnego as mech_spnego (without -D_GSS_STATIC_LINK) (c) build gssapi/krb5 as mech_krb5 (without -D_GSS_STATIC_LINK) except for krb5_gss_glue.c, which should be built as libgssapi_krb5 (d) configure /etc/gss/mech appropriately Finally, note that the configuration of dynamically loadable mechanisms is identical to Solaris, with the addition of supporting mechanisms that simply export the GSS-API themselves, rather than the mechglue dispatch table. Happy new year to everyone. -- Luke From hartmans at MIT.EDU Fri Jan 2 13:30:03 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 02 Jan 2009 13:30:03 -0500 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 In-Reply-To: (Luke Howard's message of "Thu, 1 Jan 2009 21:36:55 +1100") References: Message-ID: >>>>> "Luke" == Luke Howard writes: Luke> On 01/01/2009, at 3:43 AM, Love H?rnquist ?strand Luke> wrote: >> Sam, Luke, >> >> In heimdal I use KRB5_PRINCIPAL_UNPARSE_NO_REALM for the logon >> name, and not SHORT name. Luke> OK, fixed in r21656. Does this create a problem if you have cross-domain PACs? From hartmans at MIT.EDU Fri Jan 2 13:36:05 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 02 Jan 2009 13:36:05 -0500 Subject: Kadmin, portmap and mskrb-integ Message-ID: Luke has significantly abstracted the networking code of kadmind on the mskrb-integ branch. However, doing so creates some behavior changes. On the trunk, if svc_register for the kadmin service fails, then we fail to start kadmind. However we do not try to register with portmap: the final argument to svc_register is 0. On the trunk, we try to register iprop and if portmap registration fails, we continue anyway. On mskr b-integ, we try to register everything with portmap, but if portmap registration fails, we shut down the RPC service in question and continue anyway. Unfortunately, portmap registration seems somewhat fragile in practice. As a result, you basically never make it through the regression tests on the mskrb-integ branch because kadmind will end up failing to register its rpc service at once. You also get the very confusing situation of a kadmind that is responding to change password requests but not RPC requests. In the interests of making forward progress I'm disabling all portmap registrations on the mskrb-integ branch, but this is probably not the ideal long-term solution. I think the abstraction Luke has done is good, but it makes us think a bit more about the behavior we want. --Sam From lukeh at padl.com Fri Jan 2 16:58:20 2009 From: lukeh at padl.com (Luke Howard) Date: Sat, 3 Jan 2009 08:58:20 +1100 Subject: Kadmin, portmap and mskrb-integ In-Reply-To: References: Message-ID: <88107616-A62C-473B-94B3-371308EAD380@padl.com> On 03/01/2009, at 5:36 AM, Sam Hartman wrote: > > > Luke has significantly abstracted the networking code of kadmind on > the mskrb-integ branch. > However, doing so creates some behavior changes. > > On the trunk, if svc_register for the kadmin service fails, then we > fail to start kadmind. However we do not try to register with > portmap: the final argument to svc_register is 0. > > On the trunk, we try to register iprop and if portmap registration > fails, we continue anyway. > > On mskr b-integ, we try to register everything with portmap, but if > portmap registration fails, we shut down the RPC service in question > and continue anyway. Ah, OK, I obviously didn't look at the original code too closely. > Unfortunately, portmap registration seems somewhat fragile in > practice. As a result, you basically never make it through the > regression tests on the mskrb-integ branch because kadmind will end up > failing to register its rpc service at once. You also get the very > confusing situation of a kadmind that is responding to change password > requests but not RPC requests. > > In the interests of making forward progress I'm disabling all > portmap registrations on the mskrb-integ branch, but this is > probably not the ideal long-term solution. > > I think the abstraction Luke has done is good, but it makes us think a > bit more about the behavior we want. We can make RPC registration failure a fatal error, perhaps? --luke From lukeh at padl.com Fri Jan 2 17:01:21 2009 From: lukeh at padl.com (Luke Howard) Date: Sat, 3 Jan 2009 09:01:21 +1100 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 In-Reply-To: References: Message-ID: <3ECA81D5-2E98-41A7-8A9A-25EB429BE457@padl.com> According to the spec it's always unqualified except for the case of cross-realm S4U2Self referrals. See [MS-KILE] Appendix A<9>. Does it create a problem? Possibly, if two identically named accounts in different domains can collude and swap their PACs to the same service (and they have the same authtime). I would need to think about it some more. Surely Microsoft have thought about this case. --luke On 03/01/2009, at 5:30 AM, Sam Hartman wrote: >>>>>> "Luke" == Luke Howard writes: > > Luke> On 01/01/2009, at 3:43 AM, Love H?rnquist ?strand > Luke> wrote: > >>> Sam, Luke, >>> >>> In heimdal I use KRB5_PRINCIPAL_UNPARSE_NO_REALM for the logon >>> name, and not SHORT name. > > > Luke> OK, fixed in r21656. > > Does this create a problem if you have cross-domain PACs? > -- www.padl.com | www.fghr.net From tlyu at MIT.EDU Fri Jan 2 22:02:47 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Fri, 02 Jan 2009 22:02:47 -0500 Subject: Possible bug in "kg_ctx_internalize()" function in MIT 1.6.3 In-Reply-To: (Tom Yu's message of "Wed, 24 Dec 2008 01:23:17 -0500") References: <9549b1d80812232149k375130cic12bed9585025add@mail.gmail.com> Message-ID: Tom Yu writes: > "Sachin Punadikar" writes: > >> Hi, >> I think, people from krbdev mailing list might have answer to below >> Awaiting clarification. > > It looks like you have found a bug. It would be helpful if you would > submit a bug report by sending mail to krb5-bugs at mit.edu. If you have > a suggested patch, please include that as well. Thanks. This is now ticket #6312 in our bug database. http://krbdev.mit.edu/rt/Ticket/Display.html?id=6312 From hartmans at painless-security.com Fri Jan 2 22:28:23 2009 From: hartmans at painless-security.com (Sam Hartman) Date: Fri, 02 Jan 2009 22:28:23 -0500 Subject: mskrb-integ branch -> trunk this weekend Message-ID: Folks, the mskrb-integ branch has the joined contents of the trunk and mskrb-integ branch. That means, very soon, we will be merging mskrb-integ onto the trunk. I plan to do that over the weekend, probably tomorrow. Doubtless the merge will break something. Doubtless there will be bugs; I'm tracking a number of open issue I'll post when I actually do the merge. However I definitely think this code is ready for wider testing. I've reviewed all segments of it at least once, although I need to go over the KDC changes and a couple of GSS changes again. I'm very happy with the progress on this project, and would like to thank Luke, Love, the MIT staff and Larry for their efforts that have made this possible. --Sam From lukeh at padl.com Fri Jan 2 22:42:55 2009 From: lukeh at padl.com (Luke Howard) Date: Sat, 3 Jan 2009 14:42:55 +1100 Subject: mskrb-integ branch -> trunk this weekend In-Reply-To: References: Message-ID: > I'm very happy with the progress on this project, and would like to > thank Luke, Love, the MIT staff and Larry for their efforts that have > made this possible. Likewise BIG thanks from me to Sam, Love, the MIT staff, Larry, Metze; and everyone in Novell engineering and management that worked on open sourcing the DSfW (nee XAD) changes. -- Luke From hartmans at MIT.EDU Sat Jan 3 18:20:10 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Sat, 3 Jan 2009 18:20:10 -0500 (EST) Subject: mskrb-integ merged to trunk Message-ID: <20090103232010.58DE8451B@carter-zimmerman.suchdamage.org> Folks, I'm pleased to announce that the mskrb-integ branch has been merged onto the trunk. There are a number of issues still open, many of which we'll still want to deal with for the 1.7 release. However this will get everyone testing the code and honestly I think it's in quite good shape for a project of this size going to the trunk. * I still need to review the KDC changes. I've reviewed parts of them, and attempted to review the whole set, but they were changing too fast. Now that they have ] settled I need to do a complete walk-tthrough. * I need to review some of the GSS-API changes to util_*.c I had not previously reviewed. * Review *.exports changes one last time and sync against project write-ups. The following changes may want to happen: * Remove gss_export_name_object: conflicts with kitten work and is unused * Remove enc_padata; not sure it is usefully used in the current code and would require complicated negotiations with OS vendors because of ABI stability concerns. Bugs: * Tom reports some problems with password changes * The tgs and AS logging needs to be updated to support protocol transition and other MS features * Luke is still having trouble getting DCE RPC with integrity working. encryption works OK as I understand. * This probably breaks Windows builds; we need to find out how and fix. * This probably breaks KFM; we need to find out how and fix. * This probably breaks the lite client builds; we need to find out how and fix I'd also like to see us coordinate with Umich to see if they can retire their mechglue library. They indicated a desire to do that when we ship a real mechglue. It will be somewhat tricky. Needless to say this is not a 1.7 blocker. Thanks for working with us, and we look forward to a great 1.7 release. --Sam From sbuckley at MIT.EDU Sat Jan 3 18:25:29 2009 From: sbuckley at MIT.EDU (Stephen C. Buckley) Date: Sat, 3 Jan 2009 18:25:29 -0500 Subject: mskrb-integ merged to trunk In-Reply-To: <20090103232010.58DE8451B@carter-zimmerman.suchdamage.org> References: <20090103232010.58DE8451B@carter-zimmerman.suchdamage.org> Message-ID: <88A342EE-CC60-411B-A863-E1C51FBFE503@mit.edu> On Jan 3, 2009, at 6:20 PM, Sam Hartman wrote: > > > > Thanks for working with us, and we look forward to a great 1.7 > release. > Yay! Thanks guys. You are one heck of a team! s From lukeh at padl.com Sun Jan 4 06:26:39 2009 From: lukeh at padl.com (Luke Howard) Date: Sun, 4 Jan 2009 22:26:39 +1100 Subject: mskrb-integ merged to trunk In-Reply-To: <20090103232010.58DE8451B@carter-zimmerman.suchdamage.org> References: <20090103232010.58DE8451B@carter-zimmerman.suchdamage.org> Message-ID: > * Remove gss_export_name_object: conflicts with kitten work and is > unused > > * Remove enc_padata; not sure it is usefully used in the current > code and would require complicated negotiations with OS vendors > because of ABI stability concerns. That is fine by me. > * Luke is still having trouble getting DCE RPC with integrity > working. encryption works OK as I understand. Correct. I'm stumped with the integrity issue, it might not be a MIT bug though (DCE RPC with integrity should work with an unmodified gss_get_mic()). --luke From tlyu at MIT.EDU Sun Jan 4 20:45:01 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Sun, 04 Jan 2009 20:45:01 -0500 Subject: svn rev #21693: trunk/src/ include/ kdc/ In-Reply-To: <200901032320.SAA27478@drugstore.mit.edu> (hartmans@MIT.EDU's message of "Sat, 3 Jan 2009 18:20:32 -0500 (EST)") References: <200901032320.SAA27478@drugstore.mit.edu> Message-ID: hartmans at MIT.EDU writes: > http://src.mit.edu/fisheye/changelog/krb5/?cs=21693 > Commit By: hartmans > Log Message: > xrealm_non_transitive not trust_non_transitive > > Kerberos does not imply trust in the existence of a cross-realm key. > Trust is implied when a foreign principal is placed on an ACL: the remote realm > is trusted to authenticate that principal and is trusted > not to confuse one principal with another. > Keep terminology consistent. > > > Changed Files: > U trunk/src/include/kdb_ext.h > U trunk/src/kdc/kdc_util.c > Modified: trunk/src/include/kdb_ext.h > =================================================================== > --- trunk/src/include/kdb_ext.h 2009-01-03 23:20:26 UTC (rev 21692) > +++ trunk/src/include/kdb_ext.h 2009-01-03 23:20:31 UTC (rev 21693) > @@ -39,8 +39,8 @@ > #define KRB5_KDB_NO_AUTH_DATA_REQUIRED 0x00400000 > /* Private flag used to indicate principal is local TGS */ > #define KRB5_KDB_TICKET_GRANTING_SERVICE 0x01000000 > -/* Private flag used to indicate trust is non-transitive */ > -#define KRB5_KDB_TRUST_NON_TRANSITIVE 0x02000000 > +/* Private flag used to indicate xrealm relationship is non-transitive */ > +#define KRB5_KDB_xrealm_NON_TRANSITIVE 0x02000000 Is "xrealm" intentionally lowercase? From abartlet at samba.org Mon Jan 5 01:17:00 2009 From: abartlet at samba.org (Andrew Bartlett) Date: Mon, 05 Jan 2009 17:17:00 +1100 Subject: Session key extraction In-Reply-To: <180FCEC9-F29A-4453-99F3-626C10FC64C2@padl.com> References: <180FCEC9-F29A-4453-99F3-626C10FC64C2@padl.com> Message-ID: <1231136220.11903.1.camel@naomi.s4.naomi.abartlet.net> On Tue, 2008-12-23 at 10:10 +1100, Luke Howard wrote: > > I don't know of anyone who plans to use this feature with MIT Kerberos > > right now. So, my approach is to pull any public exposure of the > > feature and add a comment encouraging people who want to use it to > > negotiate an interface with us. I think if we're going to do this, we > > need to commit to being willing to add an interface in a point > > release. > > (Luke, if you know of users now, we could short circuit and start > > that discussion now.) > > > Microsoft protocols that need this include SMB and DRS (replication > service). I believe Samba, Novell, and Likewise will require this. > > Presently there is no explicit API for this, it is indirected through > gss_inquire_sec_context_by_oid() with GSS_C_INQ_SESSION_KEY. Indeed. Keeping this, and keeping this as close to the Heimdal API as possible is critical for a future where Samba (4 in particular) can use either MIT Kerberos or Heimdal. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090105/a830302d/attachment.bin From lukeh at padl.com Mon Jan 5 02:11:38 2009 From: lukeh at padl.com (Luke Howard) Date: Mon, 5 Jan 2009 18:11:38 +1100 Subject: Session key extraction In-Reply-To: <1231136220.11903.1.camel@naomi.s4.naomi.abartlet.net> References: <180FCEC9-F29A-4453-99F3-626C10FC64C2@padl.com> <1231136220.11903.1.camel@naomi.s4.naomi.abartlet.net> Message-ID: <974FE041-84A0-4BE0-AF31-CC37ABF53AD9@padl.com> On 05/01/2009, at 5:17 PM, Andrew Bartlett wrote: > On Tue, 2008-12-23 at 10:10 +1100, Luke Howard wrote: >>> I don't know of anyone who plans to use this feature with MIT >>> Kerberos >>> right now. So, my approach is to pull any public exposure of the >>> feature and add a comment encouraging people who want to use it to >>> negotiate an interface with us. I think if we're going to do >>> this, we >>> need to commit to being willing to add an interface in a point >>> release. >>> (Luke, if you know of users now, we could short circuit and start >>> that discussion now.) >> >> >> Microsoft protocols that need this include SMB and DRS (replication >> service). I believe Samba, Novell, and Likewise will require this. >> >> Presently there is no explicit API for this, it is indirected through >> gss_inquire_sec_context_by_oid() with GSS_C_INQ_SESSION_KEY. > > Indeed. Keeping this, and keeping this as close to the Heimdal API as > possible is critical for a future where Samba (4 in particular) can > use > either MIT Kerberos or Heimdal. Well, Heimdal can implement GSS_C_INQ_SSPI_SESSION_KEY :-) -- Luke From hartmans at MIT.EDU Mon Jan 5 07:51:45 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 05 Jan 2009 07:51:45 -0500 Subject: svn rev #21693: trunk/src/ include/ kdc/ In-Reply-To: (Tom Yu's message of "Sun, 04 Jan 2009 20:45:01 -0500") References: <200901032320.SAA27478@drugstore.mit.edu> Message-ID: Sorry about the capitalization problem. I'm going to be busy today on another projeect, but will fix this and other things that have been sent to me tomorrow if it is not dealt with by someone else sooner. From ghudson at MIT.EDU Mon Jan 5 16:00:04 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Mon, 5 Jan 2009 16:00:04 -0500 (EST) Subject: Projects/replay_cache_collision_avoidance and replay cache uses Message-ID: <200901052100.n05L044G019967@outgoing.mit.edu> In the process of preparing to implement Projects/replay_cache_collision_avoidance I noticed that we don't just use the replay cache for received authenticators. The full range of uses are: * krb5_rd_req (the basic authenticator case) * krb5_mk_priv/krb5_rd_priv * krb5_mk_safe/krb5_rd_safe * verify_sam_response (KDC preauth) (mk_priv and mk_safe store replay records presumably so that an attacker cannot reflect messages back at the sender.) First, mk_priv/rd_priv and mk_safe/rd_priv use an empty server name for their replay records. (KDC preauth uses a server name of "SAM/rc".) Therefore, using an empty server name to identify extension records is not as robust as one might hope. I will change the proposal to use empty client names instead, with the extension record value stored in the server name field instead of the client name field. Second, we have to decide what string to hash in each use case. If people would like to sanity check, my plan is: rd_req: Ciphertext of authenticator (as passed to krb5_c_decrypt) mk_priv/rd_priv: Ciphertext of message (as passed to krb5_c_decrypt) mk_safe/rd_safe: String against which checksum is computed (see below) verify_sam_response: sam_track_id field of response (as passed to krb5_c_decrypt) For mk_safe/rd_safe, what our code does is encode the KRB_SAFE message with a zeroed checksum, compute the checksum, and then re-encode the message with the checksum set. On the receiving end, the message is decoded, re-encoded with a zeroed checksum, and the received checksum is verified against the re-encoded message. It's this message-encoded-without-checksum string which should be hashed in the replay record (even though that string never appears on the wire), since that is what the attacker would have difficulty modifying without invalidating the checksum. From ghudson at MIT.EDU Mon Jan 5 16:11:23 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Mon, 05 Jan 2009 16:11:23 -0500 Subject: Projects/replay_cache_collision_avoidance and replay cache uses In-Reply-To: <200901052100.n05L044G019967@outgoing.mit.edu> References: <200901052100.n05L044G019967@outgoing.mit.edu> Message-ID: <1231189883.6322.95.camel@ray> On Mon, 2009-01-05 at 16:00 -0500, ghudson at MIT.EDU wrote: > In the process of preparing to implement > Projects/replay_cache_collision_avoidance I noticed that we don't just > use the replay cache for received authenticators. The full range of > uses are: > > * krb5_rd_req (the basic authenticator case) > * krb5_mk_priv/krb5_rd_priv > * krb5_mk_safe/krb5_rd_safe > * verify_sam_response (KDC preauth) I failed to list: * krb5_mk_cred/krb5_rd_cred For these uses, my plan is to hash the ciphertext of the encrypted part of the KRB_CRED message, as passed to krb5_c_decrypt. However, in some cases decryption does not occur during krb5_rd_cred, so I need to understand that case better. From Nicolas.Williams at sun.com Mon Jan 5 16:34:35 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 5 Jan 2009 15:34:35 -0600 Subject: Projects/replay_cache_collision_avoidance and replay cache uses In-Reply-To: <200901052100.n05L044G019967@outgoing.mit.edu> References: <200901052100.n05L044G019967@outgoing.mit.edu> Message-ID: <20090105213435.GD1872@Sun.COM> On Mon, Jan 05, 2009 at 04:00:04PM -0500, ghudson at mit.edu wrote: > In the process of preparing to implement > Projects/replay_cache_collision_avoidance I noticed that we don't just > use the replay cache for received authenticators. The full range of > uses are: > > * krb5_rd_req (the basic authenticator case) > * krb5_mk_priv/krb5_rd_priv > * krb5_mk_safe/krb5_rd_safe > * verify_sam_response (KDC preauth) Ah, right. And don't forget KRB-CRED. > (mk_priv and mk_safe store replay records presumably so that an > attacker cannot reflect messages back at the sender.) KRB-SAFE and KRB-PRIV have an s-address field that can prevent reflection (yes, yes, NAT, multi-homing, ...). And then there's sub-session keys. > [...] > > Second, we have to decide what string to hash in each use case. If > people would like to sanity check, my plan is: > > rd_req: Ciphertext of authenticator (as passed to krb5_c_decrypt) As discussed. > mk_priv/rd_priv: Ciphertext of message (as passed to krb5_c_decrypt) > mk_safe/rd_safe: String against which checksum is computed (see below) > verify_sam_response: sam_track_id field of response (as passed to > krb5_c_decrypt) If it's easy enough, sure. But just so we're clear: KRB-PRIV/SAFE are not (or should not be) remotely the motivator for this project. In the case of KRB-PRIV/SAFE the best thing to do is to always use sequence numbers, not time, and to always assert sub-session keys. I'm not sure what protocols exist that use KRB-PRIV/SAFE much, but these come to mind: - kprop (but not iprop, which is RPC based) (uses sequence numbers) - kpasswd and RFC3244 (uses sequence numbers (at least in the MIT code-base) - set/change password v2 (I forget what the I-D says; I'll make sure it says to use sequence numbers) Are there others? (UName*It uses KRB-PRIV/SAFE, someone might want to check what it does. What about Zephyr and other Athena friends?) > For mk_safe/rd_safe, what our code does is encode the KRB_SAFE message > with a zeroed checksum, compute the checksum, and then re-encode the > message with the checksum set. On the receiving end, the message is > decoded, re-encoded with a zeroed checksum, and the received checksum > is verified against the re-encoded message. It's this > message-encoded-without-checksum string which should be hashed in the > replay record (even though that string never appears on the wire), > since that is what the attacker would have difficulty modifying > without invalidating the checksum. Sounds reasonable to me, though likely unnecessary. I assume there will be testing (remember, it's likely that no commonly used apps will use this feature). Nico -- From abartlet at samba.org Mon Jan 5 16:43:52 2009 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 06 Jan 2009 08:43:52 +1100 Subject: Session key extraction In-Reply-To: <974FE041-84A0-4BE0-AF31-CC37ABF53AD9@padl.com> References: <180FCEC9-F29A-4453-99F3-626C10FC64C2@padl.com> <1231136220.11903.1.camel@naomi.s4.naomi.abartlet.net> <974FE041-84A0-4BE0-AF31-CC37ABF53AD9@padl.com> Message-ID: <1231191832.3664.0.camel@naomi.s4.naomi.abartlet.net> On Mon, 2009-01-05 at 18:11 +1100, Luke Howard wrote: > On 05/01/2009, at 5:17 PM, Andrew Bartlett wrote: > > > On Tue, 2008-12-23 at 10:10 +1100, Luke Howard wrote: > >>> I don't know of anyone who plans to use this feature with MIT > >>> Kerberos > >>> right now. So, my approach is to pull any public exposure of the > >>> feature and add a comment encouraging people who want to use it to > >>> negotiate an interface with us. I think if we're going to do > >>> this, we > >>> need to commit to being willing to add an interface in a point > >>> release. > >>> (Luke, if you know of users now, we could short circuit and start > >>> that discussion now.) > >> > >> > >> Microsoft protocols that need this include SMB and DRS (replication > >> service). I believe Samba, Novell, and Likewise will require this. > >> > >> Presently there is no explicit API for this, it is indirected through > >> gss_inquire_sec_context_by_oid() with GSS_C_INQ_SESSION_KEY. > > > > Indeed. Keeping this, and keeping this as close to the Heimdal API as > > possible is critical for a future where Samba (4 in particular) can > > use > > either MIT Kerberos or Heimdal. > > Well, Heimdal can implement GSS_C_INQ_SSPI_SESSION_KEY :-) I do have to say, it looks like a nicer API. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090106/aad4a7a1/attachment.bin From lukeh at padl.com Mon Jan 5 16:51:05 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 6 Jan 2009 08:51:05 +1100 Subject: Session key extraction In-Reply-To: <1231191832.3664.0.camel@naomi.s4.naomi.abartlet.net> References: <180FCEC9-F29A-4453-99F3-626C10FC64C2@padl.com> <1231136220.11903.1.camel@naomi.s4.naomi.abartlet.net> <974FE041-84A0-4BE0-AF31-CC37ABF53AD9@padl.com> <1231191832.3664.0.camel@naomi.s4.naomi.abartlet.net> Message-ID: >> Well, Heimdal can implement GSS_C_INQ_SSPI_SESSION_KEY :-) > > I do have to say, it looks like a nicer API. If you think so :-) It has the advantage of being mechanism-independent (Likewise, and possibly Samba, need it for NTLM). Moreover, there was a desire to fashion the interface such that consumers would be discouraged from using the session key except for SSPI interoperability. You might want to look at the gss_wrap_iov() stuff as well as the KDC changes, too. -- Luke From jaltman at secure-endpoints.com Mon Jan 5 16:51:37 2009 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Mon, 05 Jan 2009 16:51:37 -0500 Subject: Projects/replay_cache_collision_avoidance and replay cache uses In-Reply-To: <20090105213435.GD1872@Sun.COM> References: <200901052100.n05L044G019967@outgoing.mit.edu> <20090105213435.GD1872@Sun.COM> Message-ID: <496280E9.8000504@secure-endpoints.com> Nicolas Williams wrote: > In the case of KRB-PRIV/SAFE the best thing to do is to always use > sequence numbers, not time, and to always assert sub-session keys. I'm > not sure what protocols exist that use KRB-PRIV/SAFE much, but these > come to mind: > > - kprop (but not iprop, which is RPC based) (uses sequence numbers) > - kpasswd and RFC3244 (uses sequence numbers (at least in the MIT > code-base) > - set/change password v2 (I forget what the I-D says; I'll make sure it > says to use sequence numbers) > > Are there others? (UName*It uses KRB-PRIV/SAFE, someone might want to > check what it does. What about Zephyr and other Athena friends?) Untold thousands of proprietary in-house applications. Jeffrey Altman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3355 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090105/a3549fd1/smime.bin From hartmans at MIT.EDU Mon Jan 5 17:16:46 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 05 Jan 2009 17:16:46 -0500 Subject: Projects/replay_cache_collision_avoidance and replay cache uses In-Reply-To: <496280E9.8000504@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 05 Jan 2009 16:51:37 -0500") References: <200901052100.n05L044G019967@outgoing.mit.edu> <20090105213435.GD1872@Sun.COM> <496280E9.8000504@secure-endpoints.com> Message-ID: The problem with sequence numbers is they depend on sequencing. krb-priv and -safe do not have an ESP-like window. So, if you have a UDP application and you want to support out-of-order packets, you're stuck using time. Now if you use subsession keys and we could assume that the scope of a subsession key is a single authcontext, we would not need to write out replay data. However that may be a bad assumption in some of the cases where krb-priv is most attractive. From Nicolas.Williams at sun.com Mon Jan 5 17:22:45 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 5 Jan 2009 16:22:45 -0600 Subject: Projects/replay_cache_collision_avoidance and replay cache uses In-Reply-To: References: <200901052100.n05L044G019967@outgoing.mit.edu> <20090105213435.GD1872@Sun.COM> <496280E9.8000504@secure-endpoints.com> Message-ID: <20090105222244.GH1872@Sun.COM> I agree that the replay cache should do better for KRB-PRIV/SAFE/CRED. The rest of this is really off-topic, but I can't resist. On Mon, Jan 05, 2009 at 05:16:46PM -0500, Sam Hartman wrote: > The problem with sequence numbers is they depend on sequencing. > krb-priv and -safe do not have an ESP-like window. So, if you have a > UDP application and you want to support out-of-order packets, you're > stuck using time. If you're using time then out-of-order delivery is OK and so sequenceing with a sliding window (like the GSS mech) should do. > Now if you use subsession keys and we could assume that the scope of a > subsession key is a single authcontext, we would not need to write out > replay data. Indeed. (And if one is careful then one could avoid use of the replay cache for authenticators in the case of certain protocols, like RPCSEC_GSS.) > However that may be a bad assumption in some of the > cases where krb-priv is most attractive. I don't understand this last comment. Are you saying that there are apps that use KRB-PRIV but not sub-session keys? Or that it is sometimes desirable to do just that? If the latter, when? Nico -- From hartmans at MIT.EDU Mon Jan 5 17:46:21 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 05 Jan 2009 17:46:21 -0500 Subject: Projects/replay_cache_collision_avoidance and replay cache uses In-Reply-To: <20090105222244.GH1872@Sun.COM> (Nicolas Williams's message of "Mon, 5 Jan 2009 16:22:45 -0600") References: <200901052100.n05L044G019967@outgoing.mit.edu> <20090105213435.GD1872@Sun.COM> <496280E9.8000504@secure-endpoints.com> <20090105222244.GH1872@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> If you're using time then out-of-order delivery is OK and Nicolas> so sequenceing with a sliding window (like the GSS mech) Nicolas> should do. Sure, but unlike GSS, krb5 does not specify sliding-window. That is my point with the ESP reference. From ls.niks at gmail.com Mon Jan 5 23:30:52 2009 From: ls.niks at gmail.com (Nikhil Mishra) Date: Tue, 6 Jan 2009 10:00:52 +0530 Subject: Constraint delegation support ( Microsoft extensions ) Message-ID: <35dad1db0901052030h2d252552w195860825e0dda94@mail.gmail.com> Hello All , I am working with MIT kerberos library and I have a requirement for a feature using costraint delegation mechanism provided by microsoft. Does MIT kerberos implements constraint delegation feature ? If Not Is there a plan to implement one ? I have surfed around for this topic a bit and saw some older emails (September 2007 ) on this mailing list asking similar question but there was no reply . Other than that I could not find any relevant discussion on similar topic . Please provide pointers If there are any . Thanks & Regards Nikhil From lukeh at padl.com Mon Jan 5 23:39:42 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 6 Jan 2009 15:39:42 +1100 Subject: Constraint delegation support ( Microsoft extensions ) In-Reply-To: <35dad1db0901052030h2d252552w195860825e0dda94@mail.gmail.com> References: <35dad1db0901052030h2d252552w195860825e0dda94@mail.gmail.com> Message-ID: There is support in trunk for this in the KDC but nothing yet in the client library. Sent from my iPhone On 06/01/2009, at 3:30 PM, "Nikhil Mishra" wrote: > Hello All , > > I am working with MIT kerberos library and I have a requirement for a > feature using costraint delegation mechanism provided by microsoft. > Does MIT kerberos implements constraint delegation feature ? If Not > Is > there a plan to implement one ? > I have surfed around for this topic a bit and saw some older emails > (September 2007 ) on this mailing list asking similar question but > there was > no reply . > Other than that I could not find any relevant discussion on similar > topic . > Please provide pointers If there are any . > > > Thanks & Regards > > Nikhil > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > From lukeh at padl.com Tue Jan 6 00:23:42 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 6 Jan 2009 16:23:42 +1100 Subject: Constraint delegation support ( Microsoft extensions ) In-Reply-To: <03CAA2C09532074C985C6D8D9EBAC89C0C7C1C@lwlexch02.olympus.f5net.com> References: <35dad1db0901052030h2d252552w195860825e0dda94@mail.gmail.com> <03CAA2C09532074C985C6D8D9EBAC89C0C7C1C@lwlexch02.olympus.f5net.com> Message-ID: <8AED4EA8-394F-480F-A64F-F4271361C118@padl.com> On 06/01/2009, at 3:49 PM, JC Ferguson wrote: > > Are there any technical/design documents describing what has been > done to-date? There is some background at: http://msdn.microsoft.com/en-us/magazine/cc188757.aspx It was implemented some years ago from the above article, although Microsoft have recently published more detailed protocol documentation in [MS-SFU]. A quick summary is: an intermediary service does a TGS-REQ to the target service, presenting the client's ticket to itself in the additional tickets field and setting KDC_OPT_CNAME_IN_ADDL_TKT. The client ticket must be forwardable and the target service must be listed in the "allowed to delegate to" property of the intermediary service (this is exposed via KRB5_TL_CONSTRAINED_DELEGATION_ACL). The returned ticket identifies the client to the target service. > Are there plans for the client library? Are there any technical > documents for this available? Client library would be good to have, but there are no plans I'm aware of right now. Certainly, some thought would be necessary as to whether the existing delegation abstractions in GSS-API could be used, and what the API should look like at the krb5 layer. -- Luke From jc at F5.com Mon Jan 5 23:49:48 2009 From: jc at F5.com (JC Ferguson) Date: Mon, 5 Jan 2009 23:49:48 -0500 Subject: Constraint delegation support ( Microsoft extensions ) In-Reply-To: References: <35dad1db0901052030h2d252552w195860825e0dda94@mail.gmail.com> Message-ID: <03CAA2C09532074C985C6D8D9EBAC89C0C7C1C@lwlexch02.olympus.f5net.com> Are there any technical/design documents describing what has been done to-date? Are there plans for the client library? Are there any technical documents for this available? thanks -jc > -----Original Message----- > From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] > On Behalf Of Luke Howard > Sent: Monday, January 05, 2009 23:40 > To: Nikhil Mishra > Cc: krbdev at mit.edu > Subject: Re: Constraint delegation support ( Microsoft extensions ) > > There is support in trunk for this in the KDC but nothing yet > in the client library. > > Sent from my iPhone > > On 06/01/2009, at 3:30 PM, "Nikhil Mishra" wrote: > > > Hello All , > > > > I am working with MIT kerberos library and I have a > requirement for a > > feature using costraint delegation mechanism provided by microsoft. > > Does MIT kerberos implements constraint delegation feature > ? If Not Is > > there a plan to implement one ? > > I have surfed around for this topic a bit and saw some older emails > > (September 2007 ) on this mailing list asking similar question but > > there was no reply . > > Other than that I could not find any relevant discussion on similar > > topic . > > Please provide pointers If there are any . > > > > > > Thanks & Regards > > > > Nikhil > > _______________________________________________ > > krbdev mailing list krbdev at mit.edu > > https://mailman.mit.edu/mailman/listinfo/krbdev > > > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > From hartmans at MIT.EDU Tue Jan 6 10:40:11 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 06 Jan 2009 10:40:11 -0500 Subject: // comments Message-ID: I noticed Ken made a check-in to remove ISO C 99 style comments from the source tree. Do we have compilers old enough that they don't support these comments in C mode? If not, why do we care? --Sam From raeburn at MIT.EDU Tue Jan 6 11:50:15 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Tue, 6 Jan 2009 11:50:15 -0500 Subject: // comments In-Reply-To: References: Message-ID: <0C7FE06B-F974-4794-B401-0C5E65099F2F@mit.edu> On Jan 6, 2009, at 10:40, Sam Hartman wrote: > I noticed Ken made a check-in to remove ISO C 99 style comments from > the source tree. Do we have compilers old enough that they don't > support these comments in C mode? > If not, why do we care? I can't assert offhand that there's a compiler (or static analysis tool) that we care about for which it'll be a problem. On the other hand, it's not one of the aspects of C 99 that we've decided to require, so far (as opposed to, say, 64-bit support). Ken From hartmans at MIT.EDU Tue Jan 6 12:15:10 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 06 Jan 2009 12:15:10 -0500 Subject: // comments In-Reply-To: <0C7FE06B-F974-4794-B401-0C5E65099F2F@mit.edu> (Ken Raeburn's message of "Tue, 6 Jan 2009 11:50:15 -0500") References: <0C7FE06B-F974-4794-B401-0C5E65099F2F@mit.edu> Message-ID: >>>>> "Ken" == Ken Raeburn writes: Ken> On Jan 6, 2009, at 10:40, Sam Hartman wrote: >> I noticed Ken made a check-in to remove ISO C 99 style comments >> from the source tree. Do we have compilers old enough that >> they don't support these comments in C mode? If not, why do we >> care? Ken> I can't assert offhand that there's a compiler (or static Ken> analysis tool) that we care about for which it'll be a Ken> problem. On the other hand, it's not one of the aspects of C Ken> 99 that we've decided to require, so far (as opposed to, say, Ken> 64-bit support). I'd like to argue that we should. The rest of the world seems to generate patches and diffs using C99 comments. Transforming them introduces unnecessary differences, and I don't see any compelling reason not to accept this aspect of C99. --Sam From hartmans at MIT.EDU Tue Jan 6 12:26:18 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 06 Jan 2009 12:26:18 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/RFC_4537 concluding January 10 2009 Message-ID: RFC 4537 defines an encryption type negotiation extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client. --Sam From ghudson at MIT.EDU Tue Jan 6 15:09:56 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Tue, 06 Jan 2009 15:09:56 -0500 Subject: // comments In-Reply-To: References: <0C7FE06B-F974-4794-B401-0C5E65099F2F@mit.edu> Message-ID: <1231272596.6555.8.camel@ray> On Tue, 2009-01-06 at 12:15 -0500, Sam Hartman wrote: > I'd like to argue that we should. The rest of the world seems to > generate patches and diffs using C99 comments. Transforming them > introduces unnecessary differences, and I don't see any compelling > reason not to accept this aspect of C99. I'm a little surprised by this argument. We have a coding style which calls for comments in a particular form: http://k5wiki.kerberos.org/wiki/Coding_style/Formatting#Comment_formatting Assuming, for the sake of argument, that C99 comments won't break anyone's build, are you arguing that: 1. We shouldn't have a coding style (accept all contributions as-is) 2. Our coding style is outdated and should call for C99 comments instead 3. Our coding style shouldn't address comment formatting Opinions among the other MIT staff vary. I favor having a fairly strict coding style and adjusting people's contributions to match it. This is the first argument I've seen in a while in favor of being lax in order to reduce merge-back effort. From hartmans at MIT.EDU Tue Jan 6 16:32:32 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 06 Jan 2009 16:32:32 -0500 Subject: // comments In-Reply-To: <1231272596.6555.8.camel@ray> (Greg Hudson's message of "Tue, 06 Jan 2009 15:09:56 -0500") References: <0C7FE06B-F974-4794-B401-0C5E65099F2F@mit.edu> <1231272596.6555.8.camel@ray> Message-ID: Greg, I'm arguing that both comment formatting options should be accepted by our coding style. I would not go so far as to say we should not address comment formatting, simply that if we do address comment formatting I see no reason to reject // style comments at the ends of lines in functions. I'd expect a block comment to use /*, although I would be fine with not addressing comment formatting. But yes, I am effectively proposing a change to the coding style. --Sam From lukeh at padl.com Tue Jan 6 16:46:36 2009 From: lukeh at padl.com (Luke Howard) Date: Wed, 7 Jan 2009 08:46:36 +1100 Subject: // comments In-Reply-To: References: <0C7FE06B-F974-4794-B401-0C5E65099F2F@mit.edu> <1231272596.6555.8.camel@ray> Message-ID: <59CFF337-71DA-4656-ADA2-25A0BFA0106D@padl.com> Call me old fashioned, and at the risk of getting involved in the sort of discussion I would normally stay out of, but something irks me about // comments in C code. (ducks) -- Luke On 07/01/2009, at 8:32 AM, Sam Hartman wrote: > Greg, I'm arguing that both comment formatting options should be > accepted by our coding style. I would not go so far as to say we > should not address comment formatting, simply that if we do address > comment formatting I see no reason to reject // style comments at the > ends of lines in functions. I'd expect a block comment to use /*, > although I would be fine with not addressing comment formatting. > > But yes, I am effectively proposing a change to the coding style. > > --Sam > > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > -- www.padl.com | www.fghr.net From ghudson at MIT.EDU Tue Jan 6 20:03:28 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Tue, 06 Jan 2009 20:03:28 -0500 Subject: Projects/replay_cache_collision_avoidance and replay cache uses In-Reply-To: <20090105213435.GD1872@Sun.COM> References: <200901052100.n05L044G019967@outgoing.mit.edu> <20090105213435.GD1872@Sun.COM> Message-ID: <1231290208.6555.15.camel@ray> On Mon, 2009-01-05 at 15:34 -0600, Nicolas Williams wrote: > If it's easy enough, sure. But just so we're clear: KRB-PRIV/SAFE are > not (or should not be) remotely the motivator for this project. It's not terribly easy in all cases; sometimes, internal abstraction barriers would have to be changed to make the appropriate data available to the code which sets up the replay cache record. After some discussion, I'm changing my plan regarding these other uses of the replay cache. For now, they won't supply message hashes, which means they won't cause extension records to be written. Only rd_req will supply a message hash. The door will still be open to making the other uses supply message hashes in the future, of course. If people know of real-life problems involving false positive replays on mk_priv/rd_priv, mk_safe/rd_safe, mk_cred/rd_cred, or verify_sam_response, speak up and I'll reconsider. From kenh at cmf.nrl.navy.mil Wed Jan 7 11:33:47 2009 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Wed, 07 Jan 2009 11:33:47 -0500 Subject: // comments In-Reply-To: <59CFF337-71DA-4656-ADA2-25A0BFA0106D@padl.com> Message-ID: <200901071633.n07GXmaQ019675@hedwig.cmf.nrl.navy.mil> >Call me old fashioned, and at the risk of getting involved in the sort >of discussion I would normally stay out of, but something irks me >about // comments in C code. +1 --Ken, old fashioned programmer From hotz at jpl.nasa.gov Fri Jan 9 13:27:48 2009 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Fri, 9 Jan 2009 10:27:48 -0800 Subject: // comments In-Reply-To: References: Message-ID: <509E2E90-1F59-4006-926C-F07A2B4EF712@jpl.nasa.gov> On Jan 7, 2009, at 9:14 AM, krbdev-request at mit.edu wrote: > Date: Wed, 07 Jan 2009 11:33:47 -0500 > From: Ken Hornstein > Subject: Re: // comments > To: krbdev at mit.edu > Message-ID: <200901071633.n07GXmaQ019675 at hedwig.cmf.nrl.navy.mil> > >> Call me old fashioned, and at the risk of getting involved in the >> sort >> of discussion I would normally stay out of, but something irks me >> about // comments in C code. > > +1 > > --Ken, old fashioned programmer I might or might not agree per-se, but it seems to me that how you delineate right-of-code comments is pretty minor compared to the things we really need to worry about: 1) code correctness 2) ease of accepting "free" contributions 3) ease of code maintenance I guess that equates to "allow //, at least for right-of-code comments". I'll shut up now. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu From raeburn at MIT.EDU Fri Jan 9 13:44:10 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Fri, 9 Jan 2009 13:44:10 -0500 Subject: // comments In-Reply-To: <509E2E90-1F59-4006-926C-F07A2B4EF712@jpl.nasa.gov> References: <509E2E90-1F59-4006-926C-F07A2B4EF712@jpl.nasa.gov> Message-ID: <73606F6E-5C31-409F-AC85-896E72CB13BB@mit.edu> On Jan 9, 2009, at 13:27, Henry B. Hotz wrote: > I might or might not agree per-se, but it seems to me that how you > delineate right-of-code comments is pretty minor compared to the > things we really need to worry about: Agreed. > 2) ease of accepting "free" contributions > 3) ease of code maintenance Accepting too wide a range of coding styles in contributions, without enforcing any consistency, makes the code harder to read and maintain. So does accepting code that unconditionally uses newer language features that may not be available from the standard compilers on platforms we want the code to work on, like, well, much of C 99 on Windows. That said, I don't think "//" vs "/* */" is a big deal stylistically. It'd just be the compilers I'd be concerned about -- e.g., Sun, HP, IBM native compilers, and those of anyone else importing our code (and not using gcc) whom we might care about. Unless we know none of them would have a problem with it, we should be conservative. Ken From kenh at cmf.nrl.navy.mil Fri Jan 9 13:52:52 2009 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Fri, 09 Jan 2009 13:52:52 -0500 Subject: // comments In-Reply-To: <73606F6E-5C31-409F-AC85-896E72CB13BB@mit.edu> Message-ID: <200901091852.n09Iqrwf027204@hedwig.cmf.nrl.navy.mil> >That said, I don't think "//" vs "/* */" is a big deal stylistically. >It'd just be the compilers I'd be concerned about -- e.g., Sun, HP, >IBM native compilers, and those of anyone else importing our code (and >not using gcc) whom we might care about. Unless we know none of them >would have a problem with it, we should be conservative. I agree it's not a big deal stylistically; my personal preference is to not use //, but that's not really a valid consideration. I just wanted to agree with Luke that it bugs me too. But ... FWIW, within the last couple of years, I ran into an issue with the C compiler that we were using under Solaris not working with // comments (at the time, gcc accepted them). That may no longer be a concern, but it certainly was. No, I don't remember which version of the Sun C compiler this was. --Ken From jhutz at cmu.edu Fri Jan 9 16:35:51 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Fri, 09 Jan 2009 16:35:51 -0500 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs endi ng January 10 In-Reply-To: <200812311058.mBVAwcAV027089@raisinbran.srv.cs.cmu.edu> References: <200812311058.mBVAwcAV027089@raisinbran.srv.cs.cmu.edu> Message-ID: <8399AE8A2116DF6953BC862B@atlantis.pc.cs.cmu.edu> --On Wednesday, December 31, 2008 05:57:29 AM -0500 Sam Hartman wrote: > Luke, even the KDC may not have the same default_realm as the realm it > serves. First, in various ways KDCs can serve multiple realms. > Secondly, it's nice to share a krb5.conf between a KDC and a client; > I've run into cases where a machine was a KDC in one realm but I want > kinit to default to another. I _run_ such a KDC. From jhutz at cmu.edu Fri Jan 9 16:49:37 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Fri, 09 Jan 2009 16:49:37 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: <200812311104.mBVB4tAJ018557@toasties.srv.cs.cmu.edu> References: <200812302232.mBUMW8uq027734@outgoing.mit.edu> <200812311104.mBVB4tAJ018557@toasties.srv.cs.cmu.edu> Message-ID: <02AC63EE31DBC7318B8121A3@atlantis.pc.cs.cmu.edu> --On Wednesday, December 31, 2008 06:03:52 AM -0500 Sam Hartman wrote: > I was writing up a message to disagree with Greg; in particular I > think that you only need to pay the complexity cost of algorithm > agility when you support the second algorithm. > > However I considered his argument that the hash is not security > sensitive and agree. I'd like to expand on that a bit because I get > nervous when people claim that a hash is not security sensitive > without more detail. We depend on the hash to hash identical inputs > to the same output; this seems quite safe as it is a function. If an > attacker can cause non-identical inputs to collide,the worst they can > get is false positives. So, I agree the hash is not likely to need to > change for security reasons. OK; I find this argument reasonably persuasive. Greg also makes the argument that there is a general extensibility mechanism in place which could reasonably be used to indicate a change in hash algorithm or in the data being hashed, and that given such a mechanism From jhutz at cmu.edu Fri Jan 9 16:52:52 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Fri, 09 Jan 2009 16:52:52 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: <200812302232.mBUMWg7U029084@toasties.srv.cs.cmu.edu> References: <200812302232.mBUMWg7U029084@toasties.srv.cs.cmu.edu> Message-ID: <5D271BAF383EB1AB757CE07D@atlantis.pc.cs.cmu.edu> --On Tuesday, December 30, 2008 05:32:08 PM -0500 ghudson at mit.edu wrote: > 1. Supporting multiple algorithm identifiers is not simple. With a > fixed hash algorithm, you can hash a received authenticator once, use > it to check each record, and (if the authenticator is accepted) use > the same hash value to write out a new record. With multiple > algorithms, the checking loop has to be prepared to re-hash the > received authenticator for each record. (Note that I am addressing > the complexity cost here, not the performance cost. The performance > cost is negligible since in almost every practical scenario, the > expected number of re-hashes is zero.) If a transition were ever to actually occur, you'd have to either be ready to do this, or hash with multiple algorithms up front, or require that all entries in the replay cache use the same hash. In the last case, a per-record hash algorithm ID would turn out to be superfluous. I previously avoided considering that model because it would make transparent transition impossible; however, I can think of ways to make it feasible. In any case, such complexity would be needed only in the future, not now, and is brought on by the desire to perform the transition, not by planning for it. So this, alone, is not really an argument for not identifying the hash used for each record. > 2. Since the hash algorithm is not security-critical in this > application, it is vanishingly unlikely that we will ever need to > change it. Agree, particularly in light of Sam's additional detail. > 3. Extensibility mechanisms, where they exist, should be general. An > algorithm identifier does not help us if we need to add another piece > of information to records, or if we want to change the data string > being hashed, both of which are much more likely than us needing to > change the algorithm. Agree. In fact, now that I think about it, I can imagine ways in which a general extension mechanism could be used to enable transition without requiring storing a hash algorithm ID on every record today. > In fact, we already have a more general > extensibility hook: the four-byte extension magic number extension > magic number 0x48415348 ("HASH"). I'll take your word for that. > 4. The proposal does not define the meaning of the algorithm > identifier, and it is easier to simply remove it than it is to define > its meaning. Eh. Not that much easier, but OK. Overall, I find the argument compelling. -- Jeff From jhutz at cmu.edu Fri Jan 9 16:57:39 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Fri, 09 Jan 2009 16:57:39 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: <02AC63EE31DBC7318B8121A3@atlantis.pc.cs.cmu.edu> References: <200812302232.mBUMW8uq027734@outgoing.mit.edu> <200812311104.mBVB4tAJ018557@toasties.srv.cs.cmu.edu> <02AC63EE31DBC7318B8121A3@atlantis.pc.cs.cmu.edu> Message-ID: <340F6F68A6ECA8F069B6C566@atlantis.pc.cs.cmu.edu> --On Friday, January 09, 2009 04:49:37 PM -0500 Jeffrey Hutzelman wrote: > --On Wednesday, December 31, 2008 06:03:52 AM -0500 Sam Hartman > wrote: > >> I was writing up a message to disagree with Greg; in particular I >> think that you only need to pay the complexity cost of algorithm >> agility when you support the second algorithm. >> >> However I considered his argument that the hash is not security >> sensitive and agree. I'd like to expand on that a bit because I get >> nervous when people claim that a hash is not security sensitive >> without more detail. We depend on the hash to hash identical inputs >> to the same output; this seems quite safe as it is a function. If an >> attacker can cause non-identical inputs to collide,the worst they can >> get is false positives. So, I agree the hash is not likely to need to >> change for security reasons. > > OK; I find this argument reasonably persuasive. > > Greg also makes the argument that there is a general extensibility > mechanism in place which could reasonably be used to indicate a change in > hash algorithm or in the data being hashed, and that given such a > mechanism Oops; I meant to delete this, rather than send it. See my more verbose reply to Greg From hartmans at MIT.EDU Sun Jan 11 16:58:22 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Sun, 11 Jan 2009 16:58:22 -0500 Subject: mskrb-integ merged to trunk In-Reply-To: <7CC66E45-A844-462C-ABD3-B601864DD34C@apple.com> (Love =?iso-8859-1?Q?H=F6rnquist_=C5strand's?= message of "Sun, 11 Jan 2009 13:02:57 -0800") References: <20090103232010.58DE8451B@carter-zimmerman.suchdamage.org> <7CC66E45-A844-462C-ABD3-B601864DD34C@apple.com> Message-ID: Love, I'd like you to read Projects/Aliases and describe in more detail what problem you're seeing. I believe that with the current code * user connects to vnc/server * KDC knows vnc/server is an alias for host/server * server has host/server and nothing else wil work and: * host/server replay cache will be used From hartmans at MIT.EDU Mon Jan 12 07:03:34 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 12 Jan 2009 07:03:34 -0500 Subject: mskrb-integ merged to trunk In-Reply-To: <823D46F0-E92A-4717-81F5-C9AB6AE5857C@apple.com> (Love =?iso-8859-1?Q?H=F6rnquist_=C5strand's?= message of "Sun, 11 Jan 2009 14:04:33 -0800") References: <20090103232010.58DE8451B@carter-zimmerman.suchdamage.org> <7CC66E45-A844-462C-ABD3-B601864DD34C@apple.com> <823D46F0-E92A-4717-81F5-C9AB6AE5857C@apple.com> Message-ID: >>>>> "Love" == Love H?rnquist ?strand writes: Love> My concern is that the service doesn't know that vnc is an Love> alias for host. I consider this a feature, not a bug. We have significant evidence that it works well on Windows even if a service does not know all its aliases. What problems are you seeing with this situation? --Sam From lha at apple.com Sun Jan 11 16:02:57 2009 From: lha at apple.com (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Sun, 11 Jan 2009 13:02:57 -0800 Subject: mskrb-integ merged to trunk In-Reply-To: <20090103232010.58DE8451B@carter-zimmerman.suchdamage.org> References: <20090103232010.58DE8451B@carter-zimmerman.suchdamage.org> Message-ID: <7CC66E45-A844-462C-ABD3-B601864DD34C@apple.com> 3 jan 2009 kl. 15:20 skrev Sam Hartman: > Folks, I'm pleased to announce that the mskrb-integ branch has been > merged onto the trunk. There are a number of issues still open, many > of which we'll still want to deal with for the 1.7 release. However > this will get everyone testing the code and honestly I think it's in > quite good shape for a project of this size going to the trunk. After think more about the keytab changes I belive its also problematic of using the principal in the keytab since that will contain a service that the server is not expecting. Example: client connects to vnc/server, vnc/server is an alias, and the server only have host/server in the keytab. Now the server software have to aware that vnc and server is aliases of each other and indeed the replay caches are shared and not just something that tries to do a replay attack. Love From lha at apple.com Sun Jan 11 17:04:33 2009 From: lha at apple.com (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Sun, 11 Jan 2009 14:04:33 -0800 Subject: mskrb-integ merged to trunk In-Reply-To: References: <20090103232010.58DE8451B@carter-zimmerman.suchdamage.org> <7CC66E45-A844-462C-ABD3-B601864DD34C@apple.com> Message-ID: <823D46F0-E92A-4717-81F5-C9AB6AE5857C@apple.com> 11 jan 2009 kl. 13.58 skrev Sam Hartman: > Love, I'd like you to read Projects/Aliases and describe in more > detail what problem you're seeing. > > I believe that with the current code > > * user connects to vnc/server > * KDC knows vnc/server is an alias for host/server > * server has host/server and nothing else > > wil work and: > * host/server replay cache will be used My concern is that the service doesn't know that vnc is an alias for host. Love From hartmans at MIT.EDU Mon Jan 12 14:00:11 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 12 Jan 2009 14:00:11 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Aliases ending January 16, 2009 Message-ID: This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search. Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases. From ghudson at MIT.EDU Tue Jan 13 11:58:22 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Tue, 13 Jan 2009 11:58:22 -0500 (EST) Subject: Replay cache extension design issue Message-ID: <200901131658.n0DGwMHB005428@outgoing.mit.edu> Having just yesterday finished implementing the replay cache proposal, I realized a design issue this morning. Our expunge code neatly reverses the orders of entries in the file; I've included some output of a test utility at the end showing this. When new code does an expunge, this is not a problem, since the pairs are read into a single in-memory data structure. But when old code does an expunge, the extension records will be written out after the regular records they apply to, instead of before. When new code reads the expunged replay cache, it will apply hash values to the wrong records, which has the effect of allowing most replay attacks to succeed. Obviously, this needs to be fixed (or the implementation reverted) before 1.7 ships, since it's a reduction in security. My first idea for a band-aid is to make the extension records include the client and server principle strings, so that they stand alone (superceding, rather than augmenting, the old-style records which are also written out). Of course, that requires cramming the client principal string, server principal string, and hash string into the server principal field of a record. Maybe someone else has a more elegant idea. equal-rites$ ./t_replay dump /var/tmp/test Lifespan: 300 --- Client: firstclient Server: firstserver Microseconds: 0 Timestamp: 1000 --- Client: secondclient Server: secondserver Microseconds: 0 Timestamp: 1001 --- equal-rites$ ./t_replay expunge dfl:test 1002 0 Cache successfully expunged equal-rites$ ./t_replay dump /var/tmp/test Lifespan: 300 --- Client: secondclient Server: secondserver Microseconds: 0 Timestamp: 1001 --- Client: firstclient Server: firstserver Microseconds: 0 Timestamp: 1000 --- From ghudson at MIT.EDU Tue Jan 13 12:20:38 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Tue, 13 Jan 2009 12:20:38 -0500 Subject: Replay cache extension design issue In-Reply-To: <200901131658.n0DGwMHB005428@outgoing.mit.edu> References: <200901131658.n0DGwMHB005428@outgoing.mit.edu> Message-ID: <1231867238.6555.40.camel@ray> On Tue, 2009-01-13 at 11:58 -0500, ghudson at MIT.EDU wrote: > My first idea for a band-aid is to make the extension records include > the client and server principle strings, so that they stand alone > (superceding, rather than augmenting, the old-style records which are > also written out). Of course, that requires cramming the client > principal string, server principal string, and hash string into the > server principal field of a record. Maybe someone else has a more > elegant idea. Tom had the interesting idea of writing out triplets: extension record containing hash old-style record extension record containing hash That's resistant to precise reversal (which is what our code does), though not to arbitrary reordering. From Nicolas.Williams at sun.com Tue Jan 13 12:17:07 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 13 Jan 2009 11:17:07 -0600 Subject: Projects/replay_cache_collision_avoidance and replay cache uses In-Reply-To: <200901052100.n05L044G019967@outgoing.mit.edu> References: <200901052100.n05L044G019967@outgoing.mit.edu> Message-ID: <20090113171706.GN6457@Sun.COM> Back to hash agility for a moment. As discussed, it's really hard to do hash agility per-entry, and I won't propose that we do. But it'd be nice if there was an rcache header entry naming the hash function to use for that rcache. New rcache implementations that support the hash named in the rcache header entry should use it, otherwise they should act as old rcache implementations. Finally, allow for the hash function for new rcaches to be specified in krb5.conf. This gets us hash agility at little cost. And not all of it need be implemented now -- it suffices to have the header entry, with the rest to be added later. But NOT having such a header entry (naming a hash funciton, or rcache version, or something) WILL complicate hash agility later. Nico -- From Nicolas.Williams at sun.com Tue Jan 13 12:17:49 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 13 Jan 2009 11:17:49 -0600 Subject: Replay cache extension design issue In-Reply-To: <200901131658.n0DGwMHB005428@outgoing.mit.edu> References: <200901131658.n0DGwMHB005428@outgoing.mit.edu> Message-ID: <20090113171748.GO6457@Sun.COM> On Tue, Jan 13, 2009 at 11:58:22AM -0500, ghudson at mit.edu wrote: > My first idea for a band-aid is to make the extension records include > the client and server principle strings, so that they stand alone > (superceding, rather than augmenting, the old-style records which are > also written out). Of course, that requires cramming the client > principal string, server principal string, and hash string into the > server principal field of a record. Maybe someone else has a more > elegant idea. That's fine with me. From jhutz at cmu.edu Tue Jan 13 13:18:42 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Tue, 13 Jan 2009 13:18:42 -0500 Subject: Projects/replay_cache_collision_avoidance and replay cache uses In-Reply-To: <200901131726.n0DHQdBD009784@toasties.srv.cs.cmu.edu> References: <200901052100.n05L044G019967@outgoing.mit.edu> <200901131726.n0DHQdBD009784@toasties.srv.cs.cmu.edu> Message-ID: <5CCEECE95F239AC935981DFC@minbar.fac.cs.cmu.edu> --On Tuesday, January 13, 2009 11:17:07 AM -0600 Nicolas Williams wrote: > Back to hash agility for a moment. As discussed, it's really hard to do > hash agility per-entry, and I won't propose that we do. > > But it'd be nice if there was an rcache header entry naming the hash > function to use for that rcache. > > New rcache implementations that support the hash named in the rcache > header entry should use it, otherwise they should act as old rcache > implementations. > > Finally, allow for the hash function for new rcaches to be specified in > krb5.conf. > > This gets us hash agility at little cost. And not all of it need be > implemented now -- it suffices to have the header entry, with the rest > to be added later. > > But NOT having such a header entry (naming a hash funciton, or rcache > version, or something) WILL complicate hash agility later. Is there currently any kind of header? I guess I sort of assumed there was an extensible header there. From jhutz at cmu.edu Tue Jan 13 13:20:05 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Tue, 13 Jan 2009 13:20:05 -0500 Subject: Replay cache extension design issue In-Reply-To: <200901131755.n0DHtdMD016714@toasties.srv.cs.cmu.edu> References: <200901131658.n0DGwMHB005428@outgoing.mit.edu> <200901131755.n0DHtdMD016714@toasties.srv.cs.cmu.edu> Message-ID: <50DF699311B78D2077FD6691@minbar.fac.cs.cmu.edu> --On Tuesday, January 13, 2009 12:20:38 PM -0500 Greg Hudson wrote: > On Tue, 2009-01-13 at 11:58 -0500, ghudson at MIT.EDU wrote: >> My first idea for a band-aid is to make the extension records include >> the client and server principle strings, so that they stand alone >> (superceding, rather than augmenting, the old-style records which are >> also written out). Of course, that requires cramming the client >> principal string, server principal string, and hash string into the >> server principal field of a record. Maybe someone else has a more >> elegant idea. > > Tom had the interesting idea of writing out triplets: > > extension record containing hash > old-style record > extension record containing hash > > That's resistant to precise reversal (which is what our code does), > though not to arbitrary reordering. Perhaps, but do you want to write _every_ extension record in duplicate? From Nicolas.Williams at sun.com Tue Jan 13 13:21:06 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 13 Jan 2009 12:21:06 -0600 Subject: Projects/replay_cache_collision_avoidance and replay cache uses In-Reply-To: <5CCEECE95F239AC935981DFC@minbar.fac.cs.cmu.edu> References: <200901052100.n05L044G019967@outgoing.mit.edu> <200901131726.n0DHQdBD009784@toasties.srv.cs.cmu.edu> <5CCEECE95F239AC935981DFC@minbar.fac.cs.cmu.edu> Message-ID: <20090113182105.GU6457@Sun.COM> On Tue, Jan 13, 2009 at 01:18:42PM -0500, Jeffrey Hutzelman wrote: > --On Tuesday, January 13, 2009 11:17:07 AM -0600 Nicolas Williams > wrote: > >But NOT having such a header entry (naming a hash funciton, or rcache > >version, or something) WILL complicate hash agility later. > > Is there currently any kind of header? I guess I sort of assumed there was > an extensible header there. We can use rcache entries as headers (or trailers, given the order reversal during expunge...). Such a thing could be done to record an rcache creation timestamp and initial time skew for that rcache. From Nicolas.Williams at sun.com Tue Jan 13 13:29:27 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 13 Jan 2009 12:29:27 -0600 Subject: Replay cache extension design issue In-Reply-To: <50DF699311B78D2077FD6691@minbar.fac.cs.cmu.edu> References: <200901131658.n0DGwMHB005428@outgoing.mit.edu> <200901131755.n0DHtdMD016714@toasties.srv.cs.cmu.edu> <50DF699311B78D2077FD6691@minbar.fac.cs.cmu.edu> Message-ID: <20090113182926.GV6457@Sun.COM> On Tue, Jan 13, 2009 at 01:20:05PM -0500, Jeffrey Hutzelman wrote: > --On Tuesday, January 13, 2009 12:20:38 PM -0500 Greg Hudson > wrote: > > > On Tue, 2009-01-13 at 11:58 -0500, ghudson at MIT.EDU wrote: > >> My first idea for a band-aid is to make the extension records include > >> the client and server principle strings, so that they stand alone > >> (superceding, rather than augmenting, the old-style records which are > >> also written out). Of course, that requires cramming the client > >> principal string, server principal string, and hash string into the > >> server principal field of a record. Maybe someone else has a more > >> elegant idea. > > > > Tom had the interesting idea of writing out triplets: > > > > extension record containing hash > > old-style record > > extension record containing hash > > > > That's resistant to precise reversal (which is what our code does), > > though not to arbitrary reordering. > > Perhaps, but do you want to write _every_ extension record in duplicate? Also, there's no guarantee that other implementations don't merely reverse, but re-order the rcache in other ways on expunge. From ghudson at MIT.EDU Tue Jan 13 16:36:40 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Tue, 13 Jan 2009 16:36:40 -0500 Subject: Projects/replay_cache_collision_avoidance and replay cache uses In-Reply-To: <20090113171706.GN6457@Sun.COM> References: <200901052100.n05L044G019967@outgoing.mit.edu> <20090113171706.GN6457@Sun.COM> Message-ID: <1231882600.6555.53.camel@ray> On Tue, 2009-01-13 at 11:17 -0600, Nicolas Williams wrote: > But it'd be nice if there was an rcache header entry naming the hash > function to use for that rcache. [...] > But NOT having such a header entry (naming a hash funciton, or rcache > version, or something) WILL complicate hash agility later. First, I don't think it would be hard to implement hash agility without such a header. We'd just introduce a new kind of extension record using "HASH2:" instead of "HASH:" as the prefix in the server field. Second, your suggestion introduces what I'd consider a lot of additional bookkeeping in anticipation of a very specific kind of extension which is very unlikely to happen. Needing to change the hash algorithm is much less likely than needing to change what data is hashed, or needing to add some other piece of information to replay records. From ls.niks at gmail.com Sat Jan 17 09:33:52 2009 From: ls.niks at gmail.com (Nikhil Mishra) Date: Sat, 17 Jan 2009 20:03:52 +0530 Subject: Building mit kerberos trunk Message-ID: <35dad1db0901170633y53a07efkac1756a0d67fe5b4@mail.gmail.com> Hi All , I dont see any Makefile in trunk of Mit kerberos source repository . I want to try out the MS-extensions feature being committed by hartmans in trunk. I think help docs are designed for stable releases only . Where do I get the configure scripts for building trunk ? I tried using latest configure scripts from 1.6.4 . It didnt work and I dont think is advisable as well . Pardon me for being naive . Any help is appreciated . Thanks & Regards Nikhil From ghudson at MIT.EDU Sat Jan 17 10:38:13 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Sat, 17 Jan 2009 10:38:13 -0500 Subject: Building mit kerberos trunk In-Reply-To: <35dad1db0901170633y53a07efkac1756a0d67fe5b4@mail.gmail.com> References: <35dad1db0901170633y53a07efkac1756a0d67fe5b4@mail.gmail.com> Message-ID: <1232206693.6555.101.camel@ray> On Sat, 2009-01-17 at 20:03 +0530, Nikhil Mishra wrote: > Where do I get the configure scripts for building trunk ? Normally, you run: cd src util/reconf followed by the usual "./configure" and "make". You'll need autoconf 2.52 or higher installed. Best of luck! From tlyu at MIT.EDU Sat Jan 17 11:15:52 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Sat, 17 Jan 2009 11:15:52 -0500 Subject: Building mit kerberos trunk In-Reply-To: <35dad1db0901170633y53a07efkac1756a0d67fe5b4@mail.gmail.com> (Nikhil Mishra's message of "Sat, 17 Jan 2009 20:03:52 +0530") References: <35dad1db0901170633y53a07efkac1756a0d67fe5b4@mail.gmail.com> Message-ID: Nikhil Mishra writes: > Hi All , > > I dont see any Makefile in trunk of Mit kerberos source repository . > I want to try out the MS-extensions feature being committed by hartmans in > trunk. > I think help docs are designed for stable releases only . > > Where do I get the configure scripts for building trunk ? > I tried using latest configure scripts from 1.6.4 . It didnt work and I dont > think is advisable as well . > > > Pardon me for being naive . Any help is appreciated . http://k5wiki.kerberos.org/wiki/Building_from_checked-out_source This is part of a preliminary "Lore" category on the wiki. It is also described in the installation documentation, but I believe it can be difficult to find. From dalmeida at MIT.EDU Wed Jan 21 00:26:41 2009 From: dalmeida at MIT.EDU (Danilo Almeida) Date: Tue, 20 Jan 2009 21:26:41 -0800 Subject: svn rev #21766: trunk/src/lib/rpc/ In-Reply-To: <200901202349.SAA01484@drugstore.mit.edu> References: <200901202349.SAA01484@drugstore.mit.edu> Message-ID: <014c01c97b88$d8c1ad70$8a450850$@edu> Ken, Why not do something like: #ifdef USE_VALGRIND #include #else #define VALGRIND_CHECK_DEFINED(x) #endif Instead of the #ifdef USE_VALGRIND around uses of VALGRIND_CHECK_DEFINED? - Danilo -----Original Message----- From: cvs-krb5-bounces at MIT.EDU [mailto:cvs-krb5-bounces at MIT.EDU] On Behalf Of raeburn at MIT.EDU Sent: Tuesday, January 20, 2009 3:49 PM To: cvs-krb5 at mit.edu Subject: svn rev #21766: trunk/src/lib/rpc/ http://src.mit.edu/fisheye/changelog/krb5/?cs=21766 Commit By: raeburn Log Message: When encoding, and compiling with -DUSE_VALGRIND, explicitly get valgrind to check the inputs. Changed Files: U trunk/src/lib/rpc/xdr.c Modified: trunk/src/lib/rpc/xdr.c =================================================================== --- trunk/src/lib/rpc/xdr.c 2009-01-20 22:52:29 UTC (rev 21765) +++ trunk/src/lib/rpc/xdr.c 2009-01-20 23:49:08 UTC (rev 21766) @@ -54,6 +54,10 @@ #define XDR_TRUE ((long) 1) #define LASTUNSIGNED ((u_int) 0-1) +#ifdef USE_VALGRIND +#include +#endif + /* * for unit alignment */ @@ -93,6 +97,9 @@ switch (xdrs->x_op) { case XDR_ENCODE: +#ifdef USE_VALGRIND + VALGRIND_CHECK_DEFINED(*ip); +#endif if (*ip > 0x7fffffffL || *ip < -0x7fffffffL - 1L) return (FALSE); @@ -126,6 +133,9 @@ switch (xdrs->x_op) { case XDR_ENCODE: +#ifdef USE_VALGRIND + VALGRIND_CHECK_DEFINED(*up); +#endif if (*up > 0xffffffffUL) return (FALSE); @@ -158,6 +168,9 @@ switch (xdrs->x_op) { case XDR_ENCODE: +#ifdef USE_VALGRIND + VALGRIND_CHECK_DEFINED(*lp); +#endif if (*lp > 0x7fffffffL || *lp < -0x7fffffffL - 1L) return (FALSE); @@ -181,6 +194,9 @@ switch (xdrs->x_op) { case XDR_ENCODE: +#ifdef USE_VALGRIND + VALGRIND_CHECK_DEFINED(*ulp); +#endif if (*ulp > 0xffffffffUL) return (FALSE); @@ -206,6 +222,9 @@ switch (xdrs->x_op) { case XDR_ENCODE: +#ifdef USE_VALGRIND + VALGRIND_CHECK_DEFINED(*sp); +#endif l = (long) *sp; return (XDR_PUTLONG(xdrs, &l)); @@ -236,6 +255,9 @@ switch (xdrs->x_op) { case XDR_ENCODE: +#ifdef USE_VALGRIND + VALGRIND_CHECK_DEFINED(*usp); +#endif l = (u_long) *usp; return (XDR_PUTLONG(xdrs, (long *) &l)); @@ -261,6 +283,15 @@ { int i; +#ifdef USE_VALGRIND + switch (xdrs->x_op) { + case XDR_ENCODE: + VALGRIND_CHECK_DEFINED(*cp); + break; + default: + break; + } +#endif i = (*cp); if (!xdr_int(xdrs, &i)) { return (FALSE); @@ -277,6 +308,15 @@ { u_int u; +#ifdef USE_VALGRIND + switch (xdrs->x_op) { + case XDR_ENCODE: + VALGRIND_CHECK_DEFINED(*cp); + break; + default: + break; + } +#endif u = (*cp); if (!xdr_u_int(xdrs, &u)) { return (FALSE); @@ -296,6 +336,9 @@ switch (xdrs->x_op) { case XDR_ENCODE: +#ifdef USE_VALGRIND + VALGRIND_CHECK_DEFINED(*bp); +#endif lb = *bp ? XDR_TRUE : XDR_FALSE; return (XDR_PUTLONG(xdrs, &lb)); @@ -324,6 +367,15 @@ /* * enums are treated as ints */ +#ifdef USE_VALGRIND + switch (xdrs->x_op) { + case XDR_ENCODE: + VALGRIND_CHECK_DEFINED(*ep); + break; + default: + break; + } +#endif if (sizeof (enum sizecheck) == sizeof (long)) { return (xdr_long(xdrs, (long *)ep)); } else if (sizeof (enum sizecheck) == sizeof (int)) { @@ -373,6 +425,9 @@ } if (xdrs->x_op == XDR_ENCODE) { +#ifdef USE_VALGRIND + VALGRIND_CHECK_READABLE((volatile void *)cp, cnt); +#endif if (!XDR_PUTBYTES(xdrs, cp, cnt)) { return (FALSE); } @@ -463,6 +518,9 @@ switch (xdrs->x_op) { case XDR_ENCODE: +#ifdef USE_VALGRIND + VALGRIND_CHECK_DEFINED(*ip); +#endif l = *ip; return (xdr_long(xdrs, &l)); @@ -487,6 +545,9 @@ switch (xdrs->x_op) { case XDR_ENCODE: +#ifdef USE_VALGRIND + VALGRIND_CHECK_DEFINED(*up); +#endif ul = *up; return (xdr_u_long(xdrs, &ul)); _______________________________________________ cvs-krb5 mailing list cvs-krb5 at mit.edu https://mailman.mit.edu/mailman/listinfo/cvs-krb5 From raeburn at MIT.EDU Thu Jan 22 01:04:03 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 22 Jan 2009 01:04:03 -0500 Subject: svn rev #21766: trunk/src/lib/rpc/ In-Reply-To: <014c01c97b88$d8c1ad70$8a450850$@edu> References: <200901202349.SAA01484@drugstore.mit.edu> <014c01c97b88$d8c1ad70$8a450850$@edu> Message-ID: <7278455F-2B74-4B53-BA8D-610493DCE43A@mit.edu> On Jan 21, 2009, at 00:26, Danilo Almeida wrote: > Ken, > > Why not do something like: > > #ifdef USE_VALGRIND > #include > #else > #define VALGRIND_CHECK_DEFINED(x) > #endif > > Instead of the #ifdef USE_VALGRIND around uses of > VALGRIND_CHECK_DEFINED? No good reason. :-) Ken From William.Fiveash at Sun.COM Thu Jan 22 21:42:26 2009 From: William.Fiveash at Sun.COM (Will Fiveash) Date: Thu, 22 Jan 2009 20:42:26 -0600 Subject: MIT krb db2 hash test failures on Solaris Message-ID: <20090123024226.GD112@sun.com> Ken/Tom, On Solaris 5.11 snv_96 i86pc I'm seeing failures when running the db2 hash tests found in src/plugins/kdb/db2/libdb2/test. What is happening is in test1 there is a put() followed by a get() which is failing with this error message: get failed, no such key I'm running: ./dbtest -o ./t3 hash ./t2 Its failing because in: __get_item() there is this code to calculate the key->size: if (KEY_OFF(cursorp->pagep, cursorp->pgndx) != BIGPAIR) { if ((i = prev_realkey(cursorp->pagep, cursorp->pgndx)) == cursorp->pgndx) key->size = hashp->hdr.bsize - KEY_OFF(cursorp->pagep, cursorp->pgndx); Now I know that the put() key->size was 5 but after the assignment above key->size is 65541. The problem is that on Solaris: KEY_OFF(cursorp->pagep, cursorp->pgndx) = 65531 hashp->hdr.bsize = 131072 And hashp->hdr.bsize is being set in init_hash here: /* Fix bucket size to be optimal for file system */ if (file != NULL) { if (stat(file, &statbuf)) return (NULL); hashp->hdr.bsize = statbuf.st_blksize; And statbuf.st_blksize = 131072. Note that I'm running dbtest on a ZFS filesystem. And googling I notice some posts about how ZFS uses variable block sizes. So either is the above code is making some bad assumptions or stat() is buggy. Thoughts? -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ From jhutz at cmu.edu Thu Jan 22 22:06:02 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Thu, 22 Jan 2009 22:06:02 -0500 Subject: MIT krb db2 hash test failures on Solaris In-Reply-To: <200901230251.n0N2paYb029456@grapenut.srv.cs.cmu.edu> References: <200901230251.n0N2paYb029456@grapenut.srv.cs.cmu.edu> Message-ID: --On Thursday, January 22, 2009 08:42:26 PM -0600 Will Fiveash wrote: > So either is the above code is making some bad assumptions or stat() is > buggy. Thoughts? Ugh ugh ugh. If I understand the code you've quoted correctly (without going back to read the rest of it), the bucket size, and therefore the file format, varies depending on the result from st_blksize. This is hideous; UNIX files are flat byte streams and their format and interpretation should not be dependent on the properties of the filesystem on which they happen to be located. It seems to me that the code is making some extremely bad assumptions, but I can't imagine how to fix it without rendering existing db files unusable. -- Jeff From jhutz at cmu.edu Thu Jan 22 22:57:18 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Thu, 22 Jan 2009 22:57:18 -0500 Subject: [kerberos-discuss] MIT krb db2 hash test failures on Solaris In-Reply-To: <20090123034428.GJ1044@Sun.COM> References: <200901230251.n0N2paYb029456@grapenut.srv.cs.cmu.edu> <20090123034428.GJ1044@Sun.COM> Message-ID: <13D0B66D03AE87A3773BB16B@atlantis.pc.cs.cmu.edu> --On Thursday, January 22, 2009 09:44:28 PM -0600 Nicolas Williams wrote: > On Thu, Jan 22, 2009 at 10:06:02PM -0500, Jeffrey Hutzelman wrote: >> --On Thursday, January 22, 2009 08:42:26 PM -0600 Will Fiveash >> wrote: >> > So either is the above code is making some bad assumptions or stat() is >> > buggy. Thoughts? >> >> Ugh ugh ugh. >> If I understand the code you've quoted correctly (without going back to >> read the rest of it), the bucket size, and therefore the file format, >> varies depending on the result from st_blksize. This is hideous; UNIX >> files are flat byte streams and their format and interpretation should >> not be dependent on the properties of the filesystem on which they >> happen to be located. > > Actually, sizing database pages so they match the natural block size of > a filesystem is very important for performance. Sure, it's one thing to choose parameters based on the filesystem, and quite another for them to be defined in terms of the filesystem, such that... > then you cannot safely move > the database from one filesystem to another! From Nicolas.Williams at sun.com Thu Jan 22 22:44:28 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 22 Jan 2009 21:44:28 -0600 Subject: [kerberos-discuss] MIT krb db2 hash test failures on Solaris In-Reply-To: References: <200901230251.n0N2paYb029456@grapenut.srv.cs.cmu.edu> Message-ID: <20090123034428.GJ1044@Sun.COM> On Thu, Jan 22, 2009 at 10:06:02PM -0500, Jeffrey Hutzelman wrote: > --On Thursday, January 22, 2009 08:42:26 PM -0600 Will Fiveash > wrote: > > So either is the above code is making some bad assumptions or stat() is > > buggy. Thoughts? > > Ugh ugh ugh. > If I understand the code you've quoted correctly (without going back to > read the rest of it), the bucket size, and therefore the file format, > varies depending on the result from st_blksize. This is hideous; UNIX > files are flat byte streams and their format and interpretation should not > be dependent on the properties of the filesystem on which they happen to be > located. Actually, sizing database pages so they match the natural block size of a filesystem is very important for performance. The thing is though that if you make the page size depend on the fs block size then you must record the page size in the database's headers when the DB is created. If that's not done then you cannot safely move the database from one filesystem to another! Nico -- From Nicolas.Williams at sun.com Fri Jan 23 12:31:39 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 23 Jan 2009 11:31:39 -0600 Subject: [kerberos-discuss] MIT krb db2 hash test failures on Solaris In-Reply-To: <13D0B66D03AE87A3773BB16B@atlantis.pc.cs.cmu.edu> References: <200901230251.n0N2paYb029456@grapenut.srv.cs.cmu.edu> <20090123034428.GJ1044@Sun.COM> <13D0B66D03AE87A3773BB16B@atlantis.pc.cs.cmu.edu> Message-ID: <20090123173139.GM1044@Sun.COM> On Thu, Jan 22, 2009 at 10:57:18PM -0500, Jeffrey Hutzelman wrote: > --On Thursday, January 22, 2009 09:44:28 PM -0600 Nicolas Williams > wrote: > > >On Thu, Jan 22, 2009 at 10:06:02PM -0500, Jeffrey Hutzelman wrote: > >>--On Thursday, January 22, 2009 08:42:26 PM -0600 Will Fiveash > >> wrote: > >>> So either is the above code is making some bad assumptions or stat() is > >>> buggy. Thoughts? Looking at this again my guess is that there's a hard maximum of what the bdb2 page size can be, and that the default ZFS record size (128KB) is larger than that max page size. Something like that is true of SQLite3 too, for example, where the max page size due to internal pointer sizes is 32KB. For now try setting your dataset's recordsize to increasingly smaller powers of two until you find one that works. That will likely turn out to be the largest page size for bdb2, and then you can fix bdb2 to enforce it so that this never happens to someone else. > >>Ugh ugh ugh. > >>If I understand the code you've quoted correctly (without going back to > >>read the rest of it), the bucket size, and therefore the file format, > >>varies depending on the result from st_blksize. This is hideous; UNIX > >>files are flat byte streams and their format and interpretation should > >>not be dependent on the properties of the filesystem on which they > >>happen to be located. > > > >Actually, sizing database pages so they match the natural block size of > >a filesystem is very important for performance. > > Sure, it's one thing to choose parameters based on the filesystem, and > quite another for them to be defined in terms of the filesystem, such > that... > > >then you cannot safely move > >the database from one filesystem to another! Well, looking at the bdb2 code in question I see that hash->hdr.bsize is, lo and behold, in a header written to the databse on initialization and read back on open. So technically the code is doing the Right Thing... ...but I suspect there's an unstated max page size that is smaller than 128KB, and, being unstated, it's not checked for. I.e., a variant of the old 640KB problem (who'd want block sizes larger than ??). Nico -- From raeburn at MIT.EDU Fri Jan 23 13:07:56 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Fri, 23 Jan 2009 13:07:56 -0500 Subject: [kerberos-discuss] MIT krb db2 hash test failures on Solaris In-Reply-To: <20090123173139.GM1044@Sun.COM> References: <200901230251.n0N2paYb029456@grapenut.srv.cs.cmu.edu> <20090123034428.GJ1044@Sun.COM> <13D0B66D03AE87A3773BB16B@atlantis.pc.cs.cmu.edu> <20090123173139.GM1044@Sun.COM> Message-ID: <0B92D53C-D8B3-4E02-8226-224D91DA4B97@MIT.EDU> Good idea, Nico. There was a range check missing in the file-based hash init code, though the non-file hash case and the btree code both have it. I think I've got it fixed in the MIT repository trunk now. Will, please grab that change and try the tests again under ZFS. We use the btree format by default for database creation, so unless someone's going out of their way to create hash format databases under ZFS, the impact is probably only to cause the tests to fail.... Ken From Nicolas.Williams at sun.com Fri Jan 23 13:11:53 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 23 Jan 2009 12:11:53 -0600 Subject: [kerberos-discuss] MIT krb db2 hash test failures on Solaris In-Reply-To: <0B92D53C-D8B3-4E02-8226-224D91DA4B97@MIT.EDU> References: <200901230251.n0N2paYb029456@grapenut.srv.cs.cmu.edu> <20090123034428.GJ1044@Sun.COM> <13D0B66D03AE87A3773BB16B@atlantis.pc.cs.cmu.edu> <20090123173139.GM1044@Sun.COM> <0B92D53C-D8B3-4E02-8226-224D91DA4B97@MIT.EDU> Message-ID: <20090123181153.GQ1044@Sun.COM> Will independently reached the same conclusion from code inspection. There is a max page size already defined (64KB); it's just not enforced in hash_init(). On Fri, Jan 23, 2009 at 01:07:56PM -0500, Ken Raeburn wrote: > We use the btree format by default for database creation, so unless > someone's going out of their way to create hash format databases under > ZFS, the impact is probably only to cause the tests to fail.... Do we know that the btree code doesn't have a similar problem? I guess if it works with the default ZFS recordsize... Nico -- From William.Fiveash at Sun.COM Fri Jan 23 14:15:31 2009 From: William.Fiveash at Sun.COM (Will Fiveash) Date: Fri, 23 Jan 2009 13:15:31 -0600 Subject: [kerberos-discuss] MIT krb db2 hash test failures on Solaris In-Reply-To: <0B92D53C-D8B3-4E02-8226-224D91DA4B97@MIT.EDU> References: <200901230251.n0N2paYb029456@grapenut.srv.cs.cmu.edu> <20090123034428.GJ1044@Sun.COM> <13D0B66D03AE87A3773BB16B@atlantis.pc.cs.cmu.edu> <20090123173139.GM1044@Sun.COM> <0B92D53C-D8B3-4E02-8226-224D91DA4B97@MIT.EDU> Message-ID: <20090123191531.GA1468@sun.com> On Fri, Jan 23, 2009 at 01:07:56PM -0500, Ken Raeburn wrote: > Good idea, Nico. There was a range check missing in the file-based hash > init code, though the non-file hash case and the btree code both have it. > > I think I've got it fixed in the MIT repository trunk now. Will, please > grab that change and try the tests again under ZFS. The fix works and all the db2 tests that were failing are now passing on the ZFS filesystem with a recordsize of 128K (yay). -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ From William.Fiveash at Sun.COM Fri Jan 23 14:30:16 2009 From: William.Fiveash at Sun.COM (Will Fiveash) Date: Fri, 23 Jan 2009 13:30:16 -0600 Subject: [kerberos-discuss] MIT krb db2 hash test failures on Solaris In-Reply-To: <20090123181153.GQ1044@Sun.COM> References: <200901230251.n0N2paYb029456@grapenut.srv.cs.cmu.edu> <20090123034428.GJ1044@Sun.COM> <13D0B66D03AE87A3773BB16B@atlantis.pc.cs.cmu.edu> <20090123173139.GM1044@Sun.COM> <0B92D53C-D8B3-4E02-8226-224D91DA4B97@MIT.EDU> <20090123181153.GQ1044@Sun.COM> Message-ID: <20090123193016.GG112@sun.com> On Fri, Jan 23, 2009 at 12:11:53PM -0600, Nicolas Williams wrote: > Will independently reached the same conclusion from code inspection. > > There is a max page size already defined (64KB); it's just not enforced > in hash_init(). > > On Fri, Jan 23, 2009 at 01:07:56PM -0500, Ken Raeburn wrote: > > We use the btree format by default for database creation, so unless > > someone's going out of their way to create hash format databases under > > ZFS, the impact is probably only to cause the tests to fail.... > > Do we know that the btree code doesn't have a similar problem? I guess > if it works with the default ZFS recordsize... Ken pointed out that the btree code does have range checking and I verified that it passes all the tests. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ From ls.niks at gmail.com Mon Jan 26 09:48:51 2009 From: ls.niks at gmail.com (Nikhil Mishra) Date: Mon, 26 Jan 2009 20:18:51 +0530 Subject: debug version of MIT kerberos for unix Message-ID: <35dad1db0901260648r7d1a107fh59cd9f87383edca4@mail.gmail.com> Hi All , I am trying to produce a debug version of MIT kerberos for my linux machine . This is what I did : make clean && make distclean && ./util/reconf && ./configure CFLAGS="-g3 -O0" CXXFLAGS="-g3 -O0" && make It still gives me or No symbol "*" in current context . Ihave poked MIT repository , README's and installation guide quite a bit but to no rescue . Please let me know If I have missed out on something . Thanks & Regards Nikhil From ghudson at MIT.EDU Mon Jan 26 12:29:47 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Mon, 26 Jan 2009 12:29:47 -0500 Subject: debug version of MIT kerberos for unix In-Reply-To: <35dad1db0901260648r7d1a107fh59cd9f87383edca4@mail.gmail.com> References: <35dad1db0901260648r7d1a107fh59cd9f87383edca4@mail.gmail.com> Message-ID: <1232990987.6528.36.camel@ray> On Mon, 2009-01-26 at 20:18 +0530, Nikhil Mishra wrote: > make clean && make distclean && ./util/reconf && ./configure CFLAGS="-g3 > -O0" CXXFLAGS="-g3 -O0" && make > > > > It still gives me or No symbol "*" in current context Check that: 1. The compile commands have -g3 -O0 and no other -O options, and 2. The program you are running is using the libraries you compiled and not some other (perhaps previously installed) version. "ldd" is a useful tool for checking the latter. Note that on Linux, rpath values within the binaries and libraries override LD_LIBRARY_PATH values. From ls.niks at gmail.com Mon Jan 26 17:00:09 2009 From: ls.niks at gmail.com (Nikhil Mishra) Date: Tue, 27 Jan 2009 03:30:09 +0530 Subject: MS - Extensions kdc cores while making S4U2self request Message-ID: <35dad1db0901261400j149feb53t7f0cf3df0fa186e3@mail.gmail.com> Hi All , I am trying to test MS - extensions (S4U) on kdc . I am sending an S4U2self packet using the specifications laid by MS . PADATA : type 129 ENC-PART - encrypt(krb5_pa_for_user) - type name realm checksum auth_package="Kerberos" while taking a checksum , The specification says following : cksum is computed by calling the KERB_CHECKSUM_HMAC_MD5 hash with the following three parameters : session key of TGT of the service making S4U2self request value - 17 S4UByteArray - type - in littleendian name realm auth_package This is my checksum call with specified parameters : krb5_c_make_checksum(context, -138 , &(in_cred->keyblock), 17, S4UByteArray, &(for_user->cksum))) kdc cores out while processing this request.Find the debug log below : (gdb) s asn1_decode_pa_for_user (buf=0xbfb765c4, val=0x88712c8) at asn1_k_decode.c:1210 1210 { begin_structure(); (gdb) n 1211 get_field(val->user,0,asn1_decode_principal_name); (gdb) s asn1_decode_principal_name (buf=0xbfb7657c, val=0x88712c8) at asn1_k_decode.c:434 434 { begin_structure(); (gdb) n 435 get_field((*val)->type,0,asn1_decode_int32); (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x00eee345 in asn1_decode_int32 (buf=0xbfb764b4, val=0x18) at asn1_k_decode.c:389 389 integer_convert(asn1_decode_int32,krb5_int32) (gdb) bt #0 0x00eee345 in asn1_decode_int32 (buf=0xbfb764b4, val=0x18) at asn1_k_decode.c:389 #1 0x00eee7c9 in asn1_decode_principal_name (buf=0xbfb7657c, val=0x88712c8) at asn1_k_decode.c:435 #2 0x00efbab6 in asn1_decode_pa_for_user (buf=0xbfb765c4, val=0x88712c8) at asn1_k_decode.c:1211 #3 0x00f0b320 in decode_krb5_pa_for_user (code=0xbfb76614, rep=0xbfb767a0) at krb5_decode.c:973 #4 0x080521ce in kdc_process_s4u2self_req (context=0x88655e0, request=0x8871978, client_princ=0x8871e20, server=0xbfb76968, subkey=0x8871050, kdc_time=1233006406, for_user=0xbfb767a0, princ=0xbfb767f0, nprincs=0xbfb767a8, status=0xbfb76834) at kdc_util.c:1924 #5 0x0804cdfa in process_tgs_req (pkt=0xbfb77b24, from=0xbfb77c40, response=0xbfb77b20) at do_tgs_req.c:252 #6 0x0804b160 in dispatch (pkt=0xbfb77b24, from=0xbfb77c40, response=0xbfb77b20) at dispatch.c:89 #7 0x0805a16f in process_packet (conn=0x8871830, prog=0xbfb79b5b "krb5kdc", selflags=1) at network.c:1239 #8 0x0805ae7d in service_conn (conn=0x8871830, prog=0xbfb79b5b "krb5kdc", selflags=1) at network.c:1568 #9 0x0805b19a in listen_and_process (prog=0xbfb79b5b "krb5kdc") at network.c:1657 #10 0x080580a2 in main (argc=2, argv=0xbfb77da4) at main.c:725 (gdb) Any help is appreciated . Thanks --Nikhil-- P.S : Although the mail is addressed to all , I am more than sure hatman should be able to figure out better since he implemented this feature. From lukeh at padl.com Mon Jan 26 17:48:21 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 27 Jan 2009 09:48:21 +1100 Subject: MS - Extensions kdc cores while making S4U2self request In-Reply-To: <35dad1db0901261400j149feb53t7f0cf3df0fa186e3@mail.gmail.com> References: <35dad1db0901261400j149feb53t7f0cf3df0fa186e3@mail.gmail.com> Message-ID: My bad, does this help: Index: asn1_k_decode.c =================================================================== --- asn1_k_decode.c (revision 21793) +++ asn1_k_decode.c (working copy) @@ -1208,6 +1208,7 @@ { setup(); { begin_structure(); + alloc_field(val->user, krb5_principal_data); get_field(val->user,0,asn1_decode_principal_name); get_field(val->user,1,asn1_decode_realm); get_field(val->cksum,2,asn1_decode_checksum); --luke From ls.niks at gmail.com Mon Jan 26 18:13:13 2009 From: ls.niks at gmail.com (Nikhil Mishra) Date: Tue, 27 Jan 2009 04:43:13 +0530 Subject: MS - Extensions kdc cores while making S4U2self request In-Reply-To: References: <35dad1db0901261400j149feb53t7f0cf3df0fa186e3@mail.gmail.com> Message-ID: <35dad1db0901261513r2626ad15ld71cfd570e6c31f5@mail.gmail.com> Thanks Luke it helped . Being a newbie , it took a lot of time though for me to figure this out on my own . Anyways , Now my S4U2self requests return me following error : KDC policy rejects request while getting credentials I guess I need to define some policy on kdc to be able to get S4U2self tickets . Thanks anyways . --Nikhil-- On Tue, Jan 27, 2009 at 4:18 AM, Luke Howard wrote: > My bad, does this help: > Index: asn1_k_decode.c > =================================================================== > --- asn1_k_decode.c (revision 21793) > +++ asn1_k_decode.c (working copy) > @@ -1208,6 +1208,7 @@ > { > setup(); > { begin_structure(); > + alloc_field(val->user, krb5_principal_data); > get_field(val->user,0,asn1_decode_principal_name); > get_field(val->user,1,asn1_decode_realm); > get_field(val->cksum,2,asn1_decode_checksum); > > > --luke > From ls.niks at gmail.com Mon Jan 26 18:24:49 2009 From: ls.niks at gmail.com (Nikhil Mishra) Date: Tue, 27 Jan 2009 04:54:49 +0530 Subject: MS - Extensions kdc cores while making S4U2self request In-Reply-To: <35dad1db0901261513r2626ad15ld71cfd570e6c31f5@mail.gmail.com> References: <35dad1db0901261400j149feb53t7f0cf3df0fa186e3@mail.gmail.com> <35dad1db0901261513r2626ad15ld71cfd570e6c31f5@mail.gmail.com> Message-ID: <35dad1db0901261524r122383ecra2f7e6fc8c896f8@mail.gmail.com> I am not able to locate any documentation for defining policies on MIT kdc for constraine delegation . Are there any guidelines/documentation on how to define policies related to constrained delegation ? Thanks --Nikhil-- On Tue, Jan 27, 2009 at 4:43 AM, Nikhil Mishra wrote: > Thanks Luke it helped . > > Being a newbie , it took a lot of time though for me to figure this out on > my own . > Anyways , Now my S4U2self requests return me following error : > > KDC policy rejects request while getting credentials > > > I guess I need to define some policy on kdc to be able to get S4U2self > tickets . > > Thanks anyways . > > --Nikhil-- > > > On Tue, Jan 27, 2009 at 4:18 AM, Luke Howard wrote: > >> My bad, does this help: >> Index: asn1_k_decode.c >> =================================================================== >> --- asn1_k_decode.c (revision 21793) >> +++ asn1_k_decode.c (working copy) >> @@ -1208,6 +1208,7 @@ >> { >> setup(); >> { begin_structure(); >> + alloc_field(val->user, krb5_principal_data); >> get_field(val->user,0,asn1_decode_principal_name); >> get_field(val->user,1,asn1_decode_realm); >> get_field(val->cksum,2,asn1_decode_checksum); >> >> >> --luke >> > > From hartmans at MIT.EDU Mon Jan 26 19:21:34 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 26 Jan 2009 19:21:34 -0500 Subject: MS - Extensions kdc cores while making S4U2self request In-Reply-To: <35dad1db0901261524r122383ecra2f7e6fc8c896f8@mail.gmail.com> (Nikhil Mishra's message of "Tue, 27 Jan 2009 04:54:49 +0530") References: <35dad1db0901261400j149feb53t7f0cf3df0fa186e3@mail.gmail.com> <35dad1db0901261513r2626ad15ld71cfd570e6c31f5@mail.gmail.com> <35dad1db0901261524r122383ecra2f7e6fc8c896f8@mail.gmail.com> Message-ID: >>>>> "Nikhil" == Nikhil Mishra writes: Nikhil> I am not able to locate any documentation for defining Nikhil> policies on MIT kdc for constraine delegation . Nikhil> Are there any guidelines/documentation on how to define Nikhil> policies related to constrained delegation ? There are no good guidelines other than the source. Take a look at kdc_util.c and kdc_authdata.c From lukeh at padl.com Tue Jan 27 01:41:10 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 27 Jan 2009 17:41:10 +1100 Subject: MS - Extensions kdc cores while making S4U2self request In-Reply-To: <35dad1db0901261513r2626ad15ld71cfd570e6c31f5@mail.gmail.com> References: <35dad1db0901261400j149feb53t7f0cf3df0fa186e3@mail.gmail.com> <35dad1db0901261513r2626ad15ld71cfd570e6c31f5@mail.gmail.com> Message-ID: <2ED0EF08-DF05-410E-8CF0-B878E0CEDD22@padl.com> Nikhil, Thanks for finding the bug. Try stepping through kdc_process_s4u2self_req() in the KDC. --luke On 27/01/2009, at 10:13 AM, Nikhil Mishra wrote: > Thanks Luke it helped . > > Being a newbie , it took a lot of time though for me to figure this > out on my own . > Anyways , Now my S4U2self requests return me following error : > > KDC policy rejects request while getting credentials > > > > I guess I need to define some policy on kdc to be able to get > S4U2self tickets . > > Thanks anyways . > > --Nikhil-- > > On Tue, Jan 27, 2009 at 4:18 AM, Luke Howard wrote: > My bad, does this help: > > Index: asn1_k_decode.c > =================================================================== > --- asn1_k_decode.c (revision 21793) > +++ asn1_k_decode.c (working copy) > @@ -1208,6 +1208,7 @@ > { > setup(); > { begin_structure(); > + alloc_field(val->user, krb5_principal_data); > get_field(val->user,0,asn1_decode_principal_name); > get_field(val->user,1,asn1_decode_realm); > get_field(val->cksum,2,asn1_decode_checksum); > > > --luke > -- www.padl.com | www.fghr.net From ghudson at MIT.EDU Tue Jan 27 14:31:03 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Tue, 27 Jan 2009 14:31:03 -0500 (EST) Subject: Coding standards and output parameters Message-ID: <200901271931.n0RJV3sB014296@outgoing.mit.edu> First and foremost, there's been some work on the coding standards in our wiki recently, which people may want to check out: http://k5wiki.kerberos.org/wiki/Coding_style Most of it is based on the in-tree coding standards, but some of it is new. We realize that much of our code base doesn't conform to many of these standards, and I hope to clean a lot of that up between 1.7 and 1.8. More specifically, I recently added an item about output parameter handling: http://k5wiki.kerberos.org/wiki/Coding_style/Practices#Output_parameter_handling This is based partly on experiences with Coverity, and partly on a general feeling I've received from the community that output parameter values should be well-defined even in error cases. Here's your chance to discuss that requirement. In general, new requirements should probably be discussed here before they are written up in the wiki, but I did it backwards in this case. For the curious, the string handling stuff we discussed back in October resulted in this writeup: http://k5wiki.kerberos.org/wiki/Coding_style/Practices#String_Handling From hartmans at MIT.EDU Tue Jan 27 15:25:33 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 27 Jan 2009 15:25:33 -0500 Subject: Coding standards and output parameters In-Reply-To: <200901271931.n0RJV3sB014296@outgoing.mit.edu> (ghudson@MIT.EDU's message of "Tue, 27 Jan 2009 14:31:03 -0500 (EST)") References: <200901271931.n0RJV3sB014296@outgoing.mit.edu> Message-ID: I think the requirement looks fine. It doesn't cover the case where you explicitly want some output to be available on error--for example an API token that needs to be sent over the network on error return might want to be output even if the function does not return success. Such cases should be clearly documented and until we have a good place for API docs, that's really hard to do. From ghudson at MIT.EDU Tue Jan 27 15:37:17 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Tue, 27 Jan 2009 15:37:17 -0500 Subject: Coding standards and output parameters In-Reply-To: References: <200901271931.n0RJV3sB014296@outgoing.mit.edu> Message-ID: <1233088637.6528.47.camel@ray> On Tue, 2009-01-27 at 15:25 -0500, Sam Hartman wrote: > I think the requirement looks fine. It doesn't cover the case where > you explicitly want some output to be available on error--for example > an API token that needs to be sent over the network on error return > might want to be output even if the function does not return success. I adjusted the wording slightly to avoid the appearance of prohibiting such functions. (I didn't specifically bring them up, though; I don't want the standards to be too complicated.) > Such cases should be clearly documented and until we have a good place > for API docs, that's really hard to do. Yes, I'm hoping we can agree on a practice for API documentation (and documentation of internal helper functions, for that matter) in the not-too-distant future, and add that to the wiki documentation. That's a separate conversation, though. From ghudson at MIT.EDU Wed Jan 28 13:53:14 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Wed, 28 Jan 2009 13:53:14 -0500 (EST) Subject: Master key migration and the stash command Message-ID: <200901281853.n0SIrEbx016384@outgoing.mit.edu> Currently, "kdb5_util stash" does the following: 1. Open the database (or fail out) 2. (If there is an existing stash file, read in the master key and forget about it; this is odd but unimportant) 3. Prompt for the master key 4. Verify the entered key against the database (or fail out) 5. Write out the stash file There are two issues here. First, you can't stash the password before creating the database, which complicates the setup of slave DBs. Second, part of the master key migration project plan requires a "sync the stash" operation to update the stash file with all master keys. (http://k5wiki.kerberos.org/wiki/Projects/Master_Key_Migration) I was thinking of creating a "grand unified stash" command, which handles all of the use cases: * If there's a database but no valid stash file, prompt for the master password, use it to retrieve all master keys, and write out a stash file containing all master keys. * If there's a database and a valid stash file, use the stashed master key to retrieve all DB master keys, and write out a stash file containing all master keys. * If there's no database and no stash file, prompt for the master password and stash it without verifying it. Does this plan seem reasonable, or would people rather see separate kdb_util operations for "prompt and stash" and "update existing stash"? From rra at stanford.edu Wed Jan 28 14:10:50 2009 From: rra at stanford.edu (Russ Allbery) Date: Wed, 28 Jan 2009 11:10:50 -0800 Subject: Master key migration and the stash command In-Reply-To: <200901281853.n0SIrEbx016384@outgoing.mit.edu> (ghudson@mit.edu's message of "Wed\, 28 Jan 2009 13\:53\:14 -0500 \(EST\)") References: <200901281853.n0SIrEbx016384@outgoing.mit.edu> Message-ID: <87ocxr5jr9.fsf@windlord.stanford.edu> ghudson at MIT.EDU writes: > Currently, "kdb5_util stash" does the following: > > 1. Open the database (or fail out) > 2. (If there is an existing stash file, read in the master key and > forget about it; this is odd but unimportant) > 3. Prompt for the master key > 4. Verify the entered key against the database (or fail out) > 5. Write out the stash file > > There are two issues here. First, you can't stash the password before > creating the database, which complicates the setup of slave DBs. > Second, part of the master key migration project plan requires a "sync > the stash" operation to update the stash file with all master keys. > (http://k5wiki.kerberos.org/wiki/Projects/Master_Key_Migration) RT #6345 is related and would probably be fixed by the same measures. -- Russ Allbery (rra at stanford.edu) From William.Fiveash at Sun.COM Wed Jan 28 16:50:36 2009 From: William.Fiveash at Sun.COM (Will Fiveash) Date: Wed, 28 Jan 2009 15:50:36 -0600 Subject: Master key migration and the stash command In-Reply-To: <200901281853.n0SIrEbx016384@outgoing.mit.edu> References: <200901281853.n0SIrEbx016384@outgoing.mit.edu> Message-ID: <20090128215036.GA26642@sun.com> On Wed, Jan 28, 2009 at 01:53:14PM -0500, Greg Hudson wrote: > Currently, "kdb5_util stash" does the following: > > 1. Open the database (or fail out) > 2. (If there is an existing stash file, read in the master key and > forget about it; this is odd but unimportant) > 3. Prompt for the master key > 4. Verify the entered key against the database (or fail out) > 5. Write out the stash file > > There are two issues here. First, you can't stash the password before > creating the database, which complicates the setup of slave DBs. > Second, part of the master key migration project plan requires a "sync > the stash" operation to update the stash file with all master keys. > (http://k5wiki.kerberos.org/wiki/Projects/Master_Key_Migration) > > I was thinking of creating a "grand unified stash" command, which > handles all of the use cases: > > * If there's a database but no valid stash file, prompt for the > master password, use it to retrieve all master keys, and write out > a stash file containing all master keys. > > * If there's a database and a valid stash file, use the stashed > master key to retrieve all DB master keys, and write out a stash > file containing all master keys. > > * If there's no database and no stash file, prompt for the master > password and stash it without verifying it. > > Does this plan seem reasonable, or would people rather see separate > kdb_util operations for "prompt and stash" and "update existing > stash"? A couple issues: 1. Will it completely overwrite the existing stash, thus destroying any keys in the stash not found in the master princ? I'm okay with the answer being yes as the master princ better have all mkeys in use. 2. The kdb5_util create code may need to be modified to read the stash when it creates the KDB entries. BTW, when I look at the current code in krb5_def_store_mkey() I think that it is a shortcoming that the code does not preserve the existing stash keys in the new keytab (my bad). Sounds like your mods above will take care of this in a reasonable way (see item 1). -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ From tlyu at MIT.EDU Wed Jan 28 21:16:18 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Wed, 28 Jan 2009 21:16:18 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 Message-ID: Please review the project http://k5wiki.kerberos.org/wiki/Projects/Disable_DES The review period ends on February 13, 2009. This project aims to disable single-DES cryptosystems by default. The "allow_weak_crypto" libdefaults setting (which is compatible with Heimdal) will override this disabling. Note that a more general means of configuring enctypes, allowing for explicit inclusions and exclusions, is out of scope for this project for time reasons but is clearly a better way to accomplish this functionality. An initial implementation is already committed to the trunk. -- Tom Yu Development Team Leader MIT Kerberos Consortium From hartmans at MIT.EDU Thu Jan 29 10:17:48 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 29 Jan 2009 10:17:48 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: (Tom Yu's message of "Wed, 28 Jan 2009 21:16:18 -0500") References: Message-ID: Tom, I have a couple of concerns here. First, I don't understand what the use case is or functional requirements are. I mean we all know that we'd like to stop using DES. However I'd like to understand the drivers for this to understand what the right functionality is? The main questions I have that would be answered by functional requirements surround what the security/interoperability tradeoff is. For example, much of the value of disabling DES could be accomplished by disabling DES at the KDC. If the KDC does not issue tickets keyed with DES or using DES as a session key, then for the most part clients and servers will not use DES. ((Clients may still try to use DES for string2key). Also, the current project write up does not describe how the krb5_c_weak_enctype will be used. If we're planning on moving to something like permitted_enctypes = default - des then shouldn't that be krb5int_c_weak_enctype instead? I suspect I'll have additional questions once these are answered. From hartmans at MIT.EDU Thu Jan 29 10:22:33 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 29 Jan 2009 10:22:33 -0500 Subject: Master key migration and the stash command In-Reply-To: <200901281853.n0SIrEbx016384@outgoing.mit.edu> (ghudson@MIT.EDU's message of "Wed, 28 Jan 2009 13:53:14 -0500 (EST)") References: <200901281853.n0SIrEbx016384@outgoing.mit.edu> Message-ID: Your plan seems reasonable. I'd ask that 1) If the stash command does not prompt for a password, it explain why. I.E. print a message like "An existing stash file worked to open the database; updating the stash file wih all master keys." 2) If the stash command is run, there is an existing stash file, and the stash file cannot decrypt the master key, then the user be prompted for a password. 3) It would be greate to see kdb5_util create take an option to use an existing stash file . I don't think this need to be part of the same work, but it would be nice if it was at least opened as an enhancement request if people agree it is useful. --Sam From raeburn at MIT.EDU Thu Jan 29 12:21:13 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 29 Jan 2009 12:21:13 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: References: Message-ID: <4DC5CDDD-6769-4618-AF0F-6431029061F6@mit.edu> On Jan 28, 2009, at 21:16, Tom Yu wrote: > Please review the project > http://k5wiki.kerberos.org/wiki/Projects/Disable_DES I don't think "in the future, in a separate project, [we will make X set of changes]" should be a part of this project proposal. Maybe you can mention in general terms what you anticipate will be done, but if you write what *will* be done, either you're proposing those changes for review now (and implementation later) and should provide a commensurate level of detail, or you're asserting that they'll be done, without review. In this case, I don't think we should be getting into details of "permitted_enctypes" config option processing now. You even say it's a separate project; if you want to review the details now, write it up as a separate project. The project policy page lists a bunch of things that should be in a complete project proposal. Several of them are missing here, and only some of those appear not to be applicable. There's no discussion of the impact on existing deployments when updating clients, servers, or KDCs, or what will or won't work if you don't set allow_weak_crypto=yes. It will need to be well documented, both in our regular documentation (man pages, install and admin guides) and prominently in the release notes. It might even be worthwhile to change certain programs to check for DES keys (or, generally, keys of unsupported encryption types, but that would lead to vaguer messages) and warn if they're found. "You're using a DES key and DES is disabled unless you set allow_weak_crypto=yes in your config files" would be more useful than "no matching key found" or whatever. Ken From hartmans at MIT.EDU Thu Jan 29 12:43:08 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 29 Jan 2009 12:43:08 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: <4DC5CDDD-6769-4618-AF0F-6431029061F6@mit.edu> (Ken Raeburn's message of "Thu, 29 Jan 2009 12:21:13 -0500") References: <4DC5CDDD-6769-4618-AF0F-6431029061F6@mit.edu> Message-ID: >>>>> "Ken" == Ken Raeburn writes: Ken> On Jan 28, 2009, at 21:16, Tom Yu wrote: >> Please review the project >> http://k5wiki.kerberos.org/wiki/Projects/Disable_DES Ken> I don't think "in the future, in a separate project, [we will Ken> make X set of changes]" should be a part of this project Ken> proposal. Maybe you can mention in general terms what you Ken> anticipate will be done, but if you write what *will* be Ken> done, either you're proposing those changes for review now Ken> (and implementation later) and should provide a commensurate Ken> level of detail, or you're asserting that they'll be done, Ken> without review. In this case, I don't think we should be Ken> getting into details of "permitted_enctypes" config option Ken> processing now. You even say it's a separate project; if you Ken> want to review the details now, write it up as a separate Ken> project. I'd be happy with rewording, but I do actually want to have a bit of a discussion and review now about what wwe want eventual interfaces to be here. Ken> There's no discussion of the impact on existing deployments Ken> when updating clients, servers, or KDCs, or what will or Ken> won't work if you don't set allow_weak_crypto=yes. It will Ken> need to be well documented, both in our regular documentation Ken> (man pages, install and admin guides) and prominently in the Ken> release notes. Right. I think the impact needs to be discussed enough for us to review the project and the project plan needs to include effort for documentation. i think shipping the code change without the documentation changes would be confusing in this instance. From Nicolas.Williams at sun.com Thu Jan 29 12:53:38 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 29 Jan 2009 11:53:38 -0600 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: References: Message-ID: <20090129175338.GN1044@Sun.COM> On Wed, Jan 28, 2009 at 09:16:18PM -0500, Tom Yu wrote: > This project aims to disable single-DES cryptosystems by default. The > "allow_weak_crypto" libdefaults setting (which is compatible with > Heimdal) will override this disabling. Note that a more general means > of configuring enctypes, allowing for explicit inclusions and > exclusions, is out of scope for this project for time reasons but is > clearly a better way to accomplish this functionality. > > An initial implementation is already committed to the trunk. Sam comments that this should be mostly driven by the KDC, and I agree. I'd certainly have no problem with defaulting kadmind to not allow use of 1DES enctypes for new key/password changes, but having clients/ servers stop using 1DES enctypes because of a software upgrade seems much more problematic, even though also desirable. We've recently learned, in the context of SSHv2 and its broken CBC mode ciphers, just how painful simply disabling weak ciphers can be. That said, because an attacker could spoof PA-ETYPE-INFO any client that allows weak long-term keys can be caused to send PA-ENC-TIMESTAMP encrypted with weak keys, and that's bad. Sam hinted at this. So... I'm of two minds on this. Q: Which deployment is more common: clients with [hostbased] principals for themselves, or clients without any machine credentials? A decision to locally exclude 1DES enctypes can be made at realm-join time. But in the case of unkeyed clients there's no obvious time at which a krb5.conf could get written that reflects a user's realm's preferences. I do think that syntax for including/excluding ciphers in krb5.conf would be very useful though. And it doesn't strike me as too complex a feature. Nico -- From raeburn at MIT.EDU Thu Jan 29 13:18:09 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 29 Jan 2009 13:18:09 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: References: <4DC5CDDD-6769-4618-AF0F-6431029061F6@mit.edu> Message-ID: On Jan 29, 2009, at 12:43, Sam Hartman wrote: > I'd be happy with rewording, but I do actually want to have a bit of > a discussion and review now about what wwe want eventual interfaces > to be here. That's fine, but I don't think we have to decide it for 1.7. > Right. I think the impact needs to be discussed enough for us to > review the project and the project plan needs to include effort for > documentation. i think shipping the code change without the > documentation changes would be confusing in this instance. To say the least. I think that even applies to an alpha release; most of the other stuff we're doing should be harmless if you don't yet know how to turn it on, but this will break some existing deployments if you try using it without knowing what you need to change. Ken From simon at sxw.org.uk Thu Jan 29 13:38:52 2009 From: simon at sxw.org.uk (Simon Wilkinson) Date: Thu, 29 Jan 2009 18:38:52 +0000 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: References: Message-ID: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> On 29 Jan 2009, at 02:16, Tom Yu wrote: > Please review the project > http://k5wiki.kerberos.org/wiki/Projects/Disable_DES > > The review period ends on February 13, 2009. > > This project aims to disable single-DES cryptosystems by default. The > "allow_weak_crypto" libdefaults setting (which is compatible with > Heimdal) will override this disabling. Note that a more general means > of configuring enctypes, allowing for explicit inclusions and > exclusions, is out of scope for this project for time reasons but is > clearly a better way to accomplish this functionality. I'd like to see some consideration of making this switch more granular. Many of us are in a situation where we'd love to get rid of single DES, but we have some protocols (AFS in particular, but I'm sure there are places with other locally developed protocols which have similar problems) which rely upon single DES being available. Would it be possible to consider providing a configurable white list, where DES can be defined as acceptable for certain service principals? This would provide an easy mechanism for sites to disable single DES in general, but still have it for a certain limited set of uses. Cheers, Simon. From tlyu at MIT.EDU Thu Jan 29 13:42:01 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Thu, 29 Jan 2009 13:42:01 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: (Tom Yu's message of "Wed, 28 Jan 2009 21:16:18 -0500") References: Message-ID: I have moved the description of the "future work" of adding enctype inclusion/exclusion syntax. It is now at http://k5wiki.kerberos.org/wiki/Projects/Enctype_config_enhancements From ghudson at MIT.EDU Thu Jan 29 14:20:53 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Thu, 29 Jan 2009 14:20:53 -0500 Subject: Master key migration and the stash command In-Reply-To: <20090128215036.GA26642@sun.com> References: <200901281853.n0SIrEbx016384@outgoing.mit.edu> <20090128215036.GA26642@sun.com> Message-ID: <1233256853.6528.67.camel@ray> Due to time constraints, I'm going to have to punt the use case of creating a stash file without an existing database. It's not rocket science, but it requires adjusting the machinery of kdb5_util (right now, if there's no database, "kdb5_util stash" fails out before kdb5_stash() is even invoked) and we're branching in 22 hours. Sorry to get anyone's hopes up. Side issues I noticed during the implementation process: * kdb5_util should call quit() during the normal exit path in order to zap master key data. * "kdb5_util add_mkey" with no stash file produces an assertion failure. (It also doesn't prompt for an existing master key, which I think it needs in order to operate.) Also, see below about the behavior of add_mkey -s. * "kdb_util create" supposedly defaults to not creating a stash file. However, this default does not always work. kdb5_create() creates the stash file unconditionally, then removes it with unlink() if do_stash is false. However, if you did not supply a stash filename on the command line, it winds up calling unlink(NULL) which fails silently. This bug precedes the mkey_migrate branch. On Wed, 2009-01-28 at 15:50 -0600, Will Fiveash wrote: > 1. Will it completely overwrite the existing stash, thus destroying any > keys in the stash not found in the master princ? I'm okay with the > answer being yes as the master princ better have all mkeys in use. Yes. I don't think there's ever a need to manipulate the stash file beyond "store all current master keys". If there is such a need, there's always ktutil. > BTW, when I look at the current code in krb5_def_store_mkey() I think > that it is a shortcoming that the code does not preserve the existing > stash keys in the new keytab (my bad). Sounds like your mods above will > take care of this in a reasonable way (see item 1). Yes; however, "kdb5_util add_mkey -s" will need to be adjusted. Right now it overwrites the stash with the new key. From a practical perspective that's okay in most scenarios, but for cleanliness of design it should do the same thing as "kdb_util add_mkey; kdb5_util stash". Sam wrote: > 1) If the stash command does not prompt for a password, it explain > why. I.E. print a message like "An existing stash file worked to > open the database; updating the stash file wih all master keys." Done. > 2) If the stash command is run, there is an existing stash file, and > the stash file cannot decrypt the master key, then the user be > prompted for a password. That fell out of the implementation naturally. From hartmans at MIT.EDU Thu Jan 29 14:37:33 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 29 Jan 2009 14:37:33 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/FAST concluding 2009-02-13 Message-ID: FAST is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks. This project proposes to include minimal implementation of FAST in MIT Kerberos. This project is being sent out for review to get review of the proposed scope and to determine what if any additional artifacts would be required as part of a successful FAST implementation. Approval of this project does not actually mean that FAST will be implemented; the intent is to get approval and discussion of the scope and basic design of FAST for MIT Kerberos. --Sam From tlyu at MIT.EDU Thu Jan 29 21:26:13 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Thu, 29 Jan 2009 21:26:13 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> (Simon Wilkinson's message of "Thu, 29 Jan 2009 18:38:52 +0000") References: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> Message-ID: Simon Wilkinson writes: > I'd like to see some consideration of making this switch more > granular. Many of us are in a situation where we'd love to get rid of > single DES, but we have some protocols (AFS in particular, but I'm > sure there are places with other locally developed protocols which > have similar problems) which rely upon single DES being available. Several people have made remarks along these lines. There is also risk associated with introducing too many new knobs, and I am trying to find a balance. It seems that one reasonable starting point is to cause kadmind to stop generating long-term single-DES keys. This could cause problems for users who change their passwords after such a configuration is set up but who still use client software that does not support enctypes other than single DES. Perhaps modifying kadmind to distinguish user principals from service principals would be a good idea. Another idea, which I think Zhanna came up with recently, is to alter the algorithm for selection of session keys. Currently, the KDC takes the intersection of the enctype list provided by the client in the request and the enctypes supported by the service, in the order presented in the request. If both the client and the service support enctypes other than single DES, those enctypes should have priority over single-DES enctypes regardless of what order they actually appear in the request or KDB entry. One way to accomplish this is to reorder the enctype lists to place the single-DES enctypes last. For service principals, this can be done on a one-time basis with a specialized program. For enctypes listed in client requests, this needs to be done for each incoming request. > Would it be possible to consider providing a configurable white list, > where DES can be defined as acceptable for certain service principals? > This would provide an easy mechanism for sites to disable single DES > in general, but still have it for a certain limited set of uses. We already have this capability, to some degree. The list of keys in the KDB entry for a service principal (approximately) indicate the acceptable session key enctypes for that principal. Suggestions for interfaces for making this more manageable are welcome. From lukeh at padl.com Thu Jan 29 21:33:51 2009 From: lukeh at padl.com (Luke Howard) Date: Fri, 30 Jan 2009 13:33:51 +1100 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: References: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> Message-ID: >> Would it be possible to consider providing a configurable white list, >> where DES can be defined as acceptable for certain service >> principals? >> This would provide an easy mechanism for sites to disable single DES >> in general, but still have it for a certain limited set of uses. > > We already have this capability, to some degree. The list of keys in > the KDB entry for a service principal (approximately) indicate the > acceptable session key enctypes for that principal. Suggestions for > interfaces for making this more manageable are welcome. In Windows 2008, there is an attribute of each principal which is a bitmask specifying which encryption types are allowed for a service principal. Support for something like this can be hidden behind the backend's implementation of dbe_search_enctype(). -- Luke From raeburn at MIT.EDU Fri Jan 30 00:46:51 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Fri, 30 Jan 2009 00:46:51 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: References: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> Message-ID: <6FC780F8-D105-4018-9B5E-CB41C3ED91C0@mit.edu> On Jan 29, 2009, at 21:26, Tom Yu wrote: > Currently, the KDC takes > the intersection of the enctype list provided by the client in the > request and the enctypes supported by the service, in the order > presented in the request. If both the client and the service support > enctypes other than single DES, those enctypes should have priority > over single-DES enctypes regardless of what order they actually appear > in the request or KDB entry. One way to accomplish this is to reorder > the enctype lists to place the single-DES enctypes last. For service > principals, this can be done on a one-time basis with a specialized > program. For enctypes listed in client requests, this needs to be > done for each incoming request. When do you expect these lists to not have DES listed last? >> Would it be possible to consider providing a configurable white list, >> where DES can be defined as acceptable for certain service >> principals? >> This would provide an easy mechanism for sites to disable single DES >> in general, but still have it for a certain limited set of uses. > > We already have this capability, to some degree. The list of keys in > the KDB entry for a service principal (approximately) indicate the > acceptable session key enctypes for that principal. Suggestions for > interfaces for making this more manageable are welcome. However, it does mean any service that indicates it accepts DES session keys must also have a DES service key that could be attacked (by asking for tickets with the service principal as the client, and claiming only to support DES). That's one reason I've argued before that we should decouple these enctype lists, and reevaluate just what the actual needs are for various use cases. Ken From Nicolas.Williams at sun.com Fri Jan 30 01:04:06 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 30 Jan 2009 00:04:06 -0600 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> References: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> Message-ID: <20090130060405.GT1044@Sun.COM> On Thu, Jan 29, 2009 at 06:38:52PM +0000, Simon Wilkinson wrote: > I'd like to see some consideration of making this switch more > granular. Many of us are in a situation where we'd love to get rid of > single DES, but we have some protocols (AFS in particular, but I'm > sure there are places with other locally developed protocols which > have similar problems) which rely upon single DES being available. > > Would it be possible to consider providing a configurable white list, > where DES can be defined as acceptable for certain service principals? > This would provide an easy mechanism for sites to disable single DES > in general, but still have it for a certain limited set of uses. This is for service ticket encryption keys or service ticket session keys, right? If so I suggest that this be controlled through metadata attached to the service principals in the KDB. Use of supported_enctypes can be made to keep 1DES out in the case of password / key changes. Whether clients can be made to send PA-ENC-TIMESTAMP using 1DES long-term keys [derived from passwords], however, is a purely client-side issue, and the only way to involve realm administration here is at realm-join time (and host key change time). My interpretation is that this project is aimed at this particular issue. Nico -- From jaltman at secure-endpoints.com Fri Jan 30 10:17:51 2009 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Fri, 30 Jan 2009 10:17:51 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: <20090130060405.GT1044@Sun.COM> References: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> <20090130060405.GT1044@Sun.COM> Message-ID: <49831A1F.2090502@secure-endpoints.com> Nicolas Williams wrote: > On Thu, Jan 29, 2009 at 06:38:52PM +0000, Simon Wilkinson wrote: >> I'd like to see some consideration of making this switch more >> granular. Many of us are in a situation where we'd love to get rid of >> single DES, but we have some protocols (AFS in particular, but I'm >> sure there are places with other locally developed protocols which >> have similar problems) which rely upon single DES being available. >> >> Would it be possible to consider providing a configurable white list, >> where DES can be defined as acceptable for certain service principals? >> This would provide an easy mechanism for sites to disable single DES >> in general, but still have it for a certain limited set of uses. > > This is for service ticket encryption keys or service ticket session > keys, right? If so I suggest that this be controlled through metadata > attached to the service principals in the KDB. For the rxkad security class used by AFS both the service principal long term key and the session keys must be 1DES. For telnet deployments that do not support CAST or 3DES ENCRYPT options, the session key must be 1DES although the long term key can be anything. I forget if there is a restriction on the session key enctype for the rcmds. >From a realm management perspective it is not going to be possible to simply turn off 1DES. Any product that does is going to cause serious enough headaches for administrators that the product will not be deployed. There are simply too many client and service applications deployed in the existing infrastructure that require 1DES. What is required is a set to tools that permit enctype policies to be created and assigned to principals coupled with tools that can be used to examine the KDC logs to determine which client principals are requesting which enctypes. That information combined with the policies can be used to migrate the realm in phases. In addition, improvements in support for key rollover must be provided. If we are going to force a massive rollover of keys it should be combined with support that permits key rollover to be performed on a regular basis. Jeffrey Altman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3355 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090130/5bded7e2/smime.bin From Nicolas.Williams at sun.com Fri Jan 30 11:57:08 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 30 Jan 2009 10:57:08 -0600 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: <49831A1F.2090502@secure-endpoints.com> References: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> <20090130060405.GT1044@Sun.COM> <49831A1F.2090502@secure-endpoints.com> Message-ID: <20090130165708.GA1044@Sun.COM> On Fri, Jan 30, 2009 at 10:17:51AM -0500, Jeffrey Altman wrote: > For the rxkad security class used by AFS both the service principal long > term key and the session keys must be 1DES. > > For telnet deployments that do not support CAST or 3DES ENCRYPT options, > the session key must be 1DES although the long term key can be anything. These uses of 1DES can be controlled in the KDB. If the KDC would issue a Ticket encrypted in a 1DES key or with a 1DES session key, then the client should be happy to use it. Yes, the client could object, but that's not as practical as leaving it to realm policy; as long as the client doesn't ask for 1DES session keys except when an application (like TELNET) requires it, then we should be happy. > I forget if there is a restriction on the session key enctype for the rcmds. IIRC there is none. > From a realm management perspective it is not going to be possible to > simply turn off 1DES. Any product that does is going to cause serious > enough headaches for administrators that the product will not be > deployed. There are simply too many client and service applications > deployed in the existing infrastructure that require 1DES. What is > required is a set to tools that permit enctype policies to be created > and assigned to principals coupled with tools that can be used to > examine the KDC logs to determine which client principals are requesting > which enctypes. That information combined with the policies can be used > to migrate the realm in phases. I agree, but the truly hard part is dealing with AS-REQ, to prevent a client from using a weak enctype during pre-auth. The rest can be realm-mediated policy. > In addition, improvements in support for key rollover must be provided. > If we are going to force a massive rollover of keys it should be > combined with support that permits key rollover to be performed on a > regular basis. Such as with a daemon or with cronjobs? But this sounds to me like a problem for vendors and integrators, not one for MIT, though MIT can certainly help. Nico -- From Nicolas.Williams at sun.com Fri Jan 30 12:08:45 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 30 Jan 2009 11:08:45 -0600 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: References: Message-ID: <20090130170845.GC1044@Sun.COM> I think several sets of interfaces are needed here. - A krb5.conf knob to manage what long-term key enctypes are allowed for pre-authentication. This seems to be what the project is proposing. The default for this option should be configurable at build time. Vendors/distros should be able to set this default to match their rules for incompatible changes and their customers needs. - A kadmin/kadmin.local interface to manage what ticket encryption and ticket session key enctypes are allowed for any principal acting as a service principal. - A kadmin/kadmin.local interface to manage what long-term key enctypes are allowed for pre-authentication. - A kadmin interface for retrieving realm-policy preferences for existing and new enctype knobs in krb5.conf, so that tools like Solaris' kclient(1M) can be used to update krb5.conf at realm-join and re-key time. I think it's fine to have one project for each of these sets of interfaces. It'd be fine to have one project for all of them. Nico -- From hartmans at MIT.EDU Fri Jan 30 12:54:02 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 30 Jan 2009 12:54:02 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: (Tom Yu's message of "Thu, 29 Jan 2009 21:26:13 -0500") References: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> Message-ID: Tom, still waiting to hear a response to my questions. The more I read on this thread, the more I believe that the question of what you're trying to accomplish and why is critical and unanswered. --Sam From kenh at cmf.nrl.navy.mil Fri Jan 30 13:03:26 2009 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Fri, 30 Jan 2009 13:03:26 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: <49831A1F.2090502@secure-endpoints.com> Message-ID: <200901301803.n0UI3Q6C017420@hedwig.cmf.nrl.navy.mil> >From a realm management perspective it is not going to be possible to >simply turn off 1DES. I respectfully disagree. We were required to turn off 1DES a long time ago, and any exceptions we had to document. We have only two documented 1DES applications: AFS, and some crappy local Java application that only works with 1DES (I know, I know ... newer Java implementations supposedly support more enctypes, but there is some reason that these applications cannot use a newer Java. I don't really pretend to know what's going on there, but the whole thing makes me want to kick the implementer of Java-GSS in the balls repeatedly, along with whomever thought Java was a good idea for this application in the first place). However ... we are actually the exception. A number of DoD realms that I work with do not run AFS, and as a result they have zero 1DES keys. And they get regular audits from people who peer over their KDC databases LOOKING for 1DES keys, so it's not like they're going to be able to sneak 1DES keys in there. So I think a blanket statement saying it's not possible for ALL realms to turn off 1DES is simply untrue. Now certainly there are plenty of realms that still have single-DES applications. But aside from AFS, I think those applications are a pretty small list. The ones that come to mind are Kerberos telnet, that double-secret Kerberos authenticated Oracle, Java (dammit dammit DAMMIT WHAT THE HELL?!?!?!?), Kerberos-authenticated NFS (note: more ball-kicking in order here). I'm sure there are others, but still ... I think the large majority of apps can work fine without single-DES. I can imagine that a number of realms can work without any single-DES at all; if you allow AFS as the single exception, I bet the number goes way up. --Ken From jaltman at secure-endpoints.com Fri Jan 30 13:40:38 2009 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Fri, 30 Jan 2009 13:40:38 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: <200901301803.n0UI3Q6C017420@hedwig.cmf.nrl.navy.mil> References: <200901301803.n0UI3Q6C017420@hedwig.cmf.nrl.navy.mil> Message-ID: <498349A6.9060308@secure-endpoints.com> Ken Hornstein wrote: > We were required to turn off 1DES a long time ago, and any exceptions > we had to document. and how long did it take you to get to that point? > We have only two documented 1DES applications: > AFS, and some crappy local Java application that only works with 1DES only one Java application? you are lucky. > (I know, I know ... newer Java implementations supposedly support more > enctypes, but there is some reason that these applications cannot use a > newer Java. I don't really pretend to know what's going on there, but > the whole thing makes me want to kick the implementer of Java-GSS in > the balls repeatedly, along with whomever thought Java was a good idea > for this application in the first place). The applications are tied to class libraries and the class libraries are bundled to Java versions. To make matters worse, there has not been good backward compatibility between the versions. Especially within the user interface components. As a result a Java application once tested against a certain version of Java must be treated as if it only works on that version of Java. C#/.NET frameworks have an equivalent problem in the Microsoft world. > However ... we are actually the exception. A number of DoD realms that > I work with do not run AFS, and as a result they have zero 1DES keys. > And they get regular audits from people who peer over their KDC databases > LOOKING for 1DES keys, so it's not like they're going to be able to sneak > 1DES keys in there. I will point out that your site has been running with the 3DES Telnet patch now for years. This is not true for the MIT Kerberos unsupported distribution. > So I think a blanket statement saying it's not possible for ALL realms to > turn off 1DES is simply untrue. I didn't say that "no realm" could turn off 1DES. I said that "all realms" could not. There are certainly realms that have no legacy applications that could turn off 1DES. There is absolutely benefit to avoiding the use of 1DES keys in new realms unless someone does something special to enable 1DES for a specific principal. > Now certainly there are plenty of realms that still have single-DES > applications. But aside from AFS, I think those applications are > a pretty small list. The ones that come to mind are Kerberos telnet, > that double-secret Kerberos authenticated Oracle, Java (dammit dammit DAMMIT > WHAT THE HELL?!?!?!?), Kerberos-authenticated NFS (note: more ball-kicking > in order here). I'm sure there are others, but still ... I think the large > majority of apps can work fine without single-DES. I can imagine that > a number of realms can work without any single-DES at all; if you allow > AFS as the single exception, I bet the number goes way up. The vast majority of applications still using 1DES are things which are internally designed, statically linked to old Kerberos libraries or dependent on old Java GSS, and for which it may even be true that source code is no longer available. Given the current state of the economy and the cut backs in staff levels, it is even more likely at the current time that re-writing these applications will not be able to take place. I'm not arguing that it cannot be or should not be done. 1DES must be removed. I'm only arguing that it must be done in a manner that permits organizations to phase in the transitions. You can't simply remove the ability for end users to obtain 1DES service tickets. Many orgs simply do not have a list that says here are all of the clients and all of the services and what enctypes are required or compatible. Instead, it is a lot safer to define a policy and apply it to a subset of the principals that are believed to be safe to restrict a little at a time. Jeffrey Altman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3355 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090130/0f21993d/smime.bin From sbuckley at MIT.EDU Fri Jan 30 13:43:38 2009 From: sbuckley at MIT.EDU (Stephen C. Buckley) Date: Fri, 30 Jan 2009 13:43:38 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: References: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> Message-ID: <59B9FE07-0D55-4C52-A912-11692B527CAB@mit.edu> Sam, we want to discourage the use of DES by turning it off by default and allowing people to turn it back on if they choose to accept the risks of doing so. Sent from my mobile device. On Jan 30, 2009, at 12:54 PM, Sam Hartman wrote: > Tom, still waiting to hear a response to my questions. The more I > read on this thread, the more I believe that the question of what > you're trying to accomplish and why is critical and unanswered. > > --Sam > > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev From tlyu at MIT.EDU Fri Jan 30 13:44:50 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Fri, 30 Jan 2009 13:44:50 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: (Sam Hartman's message of "Thu, 29 Jan 2009 10:17:48 -0500") References: Message-ID: Sam Hartman writes: > Tom, I have a couple of concerns here. > > First, I don't understand what the use case is or functional > requirements are. > > I mean we all know that we'd like to stop using DES. However I'd like > to understand the drivers for this to understand what the right > functionality is? Motivation: make preparations for completely removing single-DES support in the krb5-1.8 release. Note that Heimdal implements complete disabling of single-DES using "allow_weak_crypto" (which defaults to false). We can debate (and indeed seem to be doing so quite actively) whether this strategy is deployable. > The main questions I have that would be answered by functional > requirements surround what the security/interoperability tradeoff is. > > For example, much of the value of disabling DES could be accomplished > by disabling DES at the KDC. If the KDC does not issue tickets keyed > with DES or using DES as a session key, then for the most part clients > and servers will not use DES. ((Clients may still try to use DES for > string2key). As I mentioned elsewhere, disabling DES at the KDC is probably a reasonable interim step. > Also, the current project write up does not describe how the > krb5_c_weak_enctype will be used. If we're planning on moving to > something like permitted_enctypes = default - des then shouldn't that > be krb5int_c_weak_enctype instead? It could be krb5int_c_weak_enctype, and it is currently not exported. We have appear to have precedent for having internal crypto functions with a krb5_c_ prefix rather than a krb5int_c_ prefix. From kenh at cmf.nrl.navy.mil Fri Jan 30 14:07:16 2009 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Fri, 30 Jan 2009 14:07:16 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: <498349A6.9060308@secure-endpoints.com> Message-ID: <200901301907.n0UJ7Gxq018579@hedwig.cmf.nrl.navy.mil> >> We were required to turn off 1DES a long time ago, and any exceptions >> we had to document. > >and how long did it take you to get to that point? I think ... from start of "remove 1DES" to "1DES is removed" was approximately one year. But that was a while ago, and we had severe management pressure for that. >I will point out that your site has been running with the 3DES Telnet >patch now for years. This is not true for the MIT Kerberos unsupported >distribution. Well, yeah ... but how many people like us are crazy enough to use Kerberos telnet? :-) >I'm not arguing that it cannot be or should not be done. 1DES must be >removed. I'm only arguing that it must be done in a manner that permits >organizations to phase in the transitions. You can't simply remove the >ability for end users to obtain 1DES service tickets. Many orgs simply >do not have a list that says here are all of the clients and all of the >services and what enctypes are required or compatible. Instead, it is a >lot safer to define a policy and apply it to a subset of the principals >that are believed to be safe to restrict a little at a time. If you run MIT Kerberos, it's actually not hard to at least get a handle on the problem. The KDC logs include which enctypes applications indicate that they support in their requests and the enctypes of the tickets and session keys that are issued. Want to know how many of your clients only support single-DES? I do (sadly, the number is not zero, again due to a crappy Java application). Last time I checked, Heimdal would require modifications to log this information (but I'm sure the modifications would be straightforward). At least getting a handle on the size of the problem would build a useful foundation for how we should proceed. --Ken From tlyu at MIT.EDU Fri Jan 30 14:20:54 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Fri, 30 Jan 2009 14:20:54 -0500 Subject: near-term strategy for "disable DES" effort Message-ID: Near term (krb5-1.7-alpha1 timeline) strategy for the "disable DES" effort will include the following: * Remove single-DES enctypes from the "supported_enctypes" list for libkadm5. This will prevent kadmind from creating new single-DES long-term keys unless explicitly configured otherwise. This may cause problems for users running old client software, and I encourage you to propose strategies for mitigating this issue. * Implement the "allow_weak_crypto" libdefault setting. I was leaning in favor of "false" but recent discussion of the transition issues is calling that into question. Unless I hear strong objections, I will assert that defaulting to "false" is acceptable for the alpha release and am willing to reconsider prior to final release. We expect to make the release branch and the krb5-1.7-alpha1 release later today. I will continue to update the project proposal and gather opinions on future progress of this effort. -- Tom Yu Development Team Leader MIT Kerberos Consortium From hartmans at MIT.EDU Fri Jan 30 15:03:59 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 30 Jan 2009 15:03:59 -0500 Subject: near-term strategy for "disable DES" effort In-Reply-To: (Tom Yu's message of "Fri, 30 Jan 2009 14:20:54 -0500") References: Message-ID: >>>>> "Tom" == Tom Yu writes: Tom> * Implement the "allow_weak_crypto" libdefault setting. I Tom> was leaning in favor of "false" but recent discussion of the Tom> transition issues is calling that into question. Unless I Tom> hear strong objections, I will assert that defaulting to Tom> "false" is acceptable for the alpha release and am willing to Tom> reconsider prior to final release. I strongly object to this unless you meet Ken's documentation constraints. At a minimum, I think that * user guide * admin guide * README * kadmin man page need to be updated. And I agree with Ken this is true for the alpha. If you do this, I think it is reasonable to default to false. Otherwise, I do not. --Sam From Nicolas.Williams at sun.com Fri Jan 30 15:02:49 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 30 Jan 2009 14:02:49 -0600 Subject: near-term strategy for "disable DES" effort In-Reply-To: References: Message-ID: <20090130200248.GM1044@Sun.COM> On Fri, Jan 30, 2009 at 02:20:54PM -0500, Tom Yu wrote: > Near term (krb5-1.7-alpha1 timeline) strategy for the "disable DES" > effort will include the following: > > * Remove single-DES enctypes from the "supported_enctypes" list for > libkadm5. This will prevent kadmind from creating new single-DES > long-term keys unless explicitly configured otherwise. This may > cause problems for users running old client software, and I > encourage you to propose strategies for mitigating this issue. I agree with this. But you may want to be aware of some changes made in this area in Solaris. To better support older releases that supported only 1DES enctypes Solaris' kadmind does the following: - If the client called kadm5_randkey_principal() then assume it wants 1DES only. Old clients don't use the kadm5_*_3() functions - Otherwise use supported_enctypes. And Solaris' kadmin/kadmin.local do the following: - randkey w/o the -e option acts as though -e with the list of all permitted_enctypes was provided. > * Implement the "allow_weak_crypto" libdefault setting. I was leaning > in favor of "false" but recent discussion of the transition issues > is calling that into question. Unless I hear strong objections, I > will assert that defaulting to "false" is acceptable for the alpha > release and am willing to reconsider prior to final release. I would like to see clarification of what contexts allow_weak_crypto is intended to apply to. Is it every context that default_tkt/tgs_enctypes and permitted_enctypes applies to? I think that would be too constraining for realms that want to get away from 1DES for password- derived long-term keys first. I would almost rather you defer this project until consensus is reached. > We expect to make the release branch and the krb5-1.7-alpha1 release > later today. I thought the review deadline was February 13, 2009. Is that still the case? Nico -- From Nicolas.Williams at sun.com Fri Jan 30 15:44:42 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 30 Jan 2009 14:44:42 -0600 Subject: near-term strategy for "disable DES" effort In-Reply-To: References: Message-ID: <20090130204441.GR1044@Sun.COM> On Fri, Jan 30, 2009 at 03:03:59PM -0500, Sam Hartman wrote: > >>>>> "Tom" == Tom Yu writes: > > Tom> * Implement the "allow_weak_crypto" libdefault setting. I > Tom> was leaning in favor of "false" but recent discussion of the > Tom> transition issues is calling that into question. Unless I > Tom> hear strong objections, I will assert that defaulting to > Tom> "false" is acceptable for the alpha release and am willing to > Tom> reconsider prior to final release. > > I strongly object to this unless you meet Ken's documentation > constraints. I also object unless the default is a build-time option. We would like to eventually get to where we do code drops from MIT, but we might need to make changes that can be seen as incompatible at potentially different times than MIT. Nico -- From hartmans at MIT.EDU Fri Jan 30 16:14:58 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 30 Jan 2009 16:14:58 -0500 Subject: build time options In-Reply-To: <20090130204441.GR1044@Sun.COM> (Nicolas Williams's message of "Fri, 30 Jan 2009 14:44:42 -0600") References: <20090130204441.GR1044@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Fri, Jan 30, 2009 at 03:03:59PM -0500, Sam Hartman Nicolas> wrote: >> >>>>> "Tom" == Tom Yu writes: >> Tom> * Implement the "allow_weak_crypto" libdefault setting. I Tom> was leaning in favor of "false" but recent discussion of the Tom> transition issues is calling that into question. Unless I Tom> hear strong objections, I will assert that defaulting to Tom> "false" is acceptable for the alpha release and am willing to Tom> reconsider prior to final release. >> I strongly object to this unless you meet Ken's documentation >> constraints. Nicolas> I also object unless the default is a build-time option. Nicolas> We would like to eventually get to where we do code drops Nicolas> from MIT, but we might need to make changes that can be Nicolas> seen as incompatible at potentially different times than Nicolas> MIT. I agree that MIT's recent tendency to introduce vendor-specific code with a bunch of build-time defines would be compatible with this. I'd like to start a discussion of that practice. I understand the desire to minimize patches. However I think it would be a good idea to get some guidelines for when we accept build-time options and for when we tell people to go maintain a patch. --Sam From Nicolas.Williams at sun.com Fri Jan 30 16:26:21 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 30 Jan 2009 15:26:21 -0600 Subject: build time options In-Reply-To: References: <20090130204441.GR1044@Sun.COM> Message-ID: <20090130212621.GV1044@Sun.COM> On Fri, Jan 30, 2009 at 04:14:58PM -0500, Sam Hartman wrote: > Nicolas> I also object unless the default is a build-time option. > Nicolas> We would like to eventually get to where we do code drops > Nicolas> from MIT, but we might need to make changes that can be > Nicolas> seen as incompatible at potentially different times than > Nicolas> MIT. > > I agree that MIT's recent tendency to introduce vendor-specific code > with a bunch of build-time defines would be compatible with this. > > I'd like to start a discussion of that practice. I understand the > desire to minimize patches. However I think it would be a good idea > to get some guidelines for when we accept build-time options and for > when we tell people to go maintain a patch. I agree. The need for this stems from the fact that each vendor/distributor has different release schedules from MIT and different rules for when incompatible changes can be made. Sometimes we can simply make the change if it's minor enough. Other times we must resort to patching/ forking. We should all aim to limit patching/forking due to incompatible changes. A good rule is that any change which is or may be either an incompatible change to what should be a stable interface or to a semantic that rises to the level of an interface (i.e., users/apps expect a given behavior and depend on it) should trigger a discussion of whether the change should be controlled by a build option, and how long that option should last. Some changes will be very difficult to make build-selectable. If this can't be avoided then vendors/distros might have to live with the change, or we might all conclude that the new feature should be designed differently, etcetera. Nico -- From jhutz at cmu.edu Fri Jan 30 18:23:39 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Fri, 30 Jan 2009 18:23:39 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: <200901301519.n0UFJAvW028894@toasties.srv.cs.cmu.edu> References: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> <20090130060405.GT1044@Sun.COM> <200901301519.n0UFJAvW028894@toasties.srv.cs.cmu.edu> Message-ID: <5669C58E6DA594B4C6621C81@minbar.fac.cs.cmu.edu> --On Friday, January 30, 2009 10:17:51 AM -0500 Jeffrey Altman wrote: > From a realm management perspective it is not going to be possible to > simply turn off 1DES. Any product that does is going to cause serious > enough headaches for administrators that the product will not be > deployed. There are simply too many client and service applications > deployed in the existing infrastructure that require 1DES. What is > required is a set to tools that permit enctype policies to be created > and assigned to principals coupled with tools that can be used to > examine the KDC logs to determine which client principals are requesting > which enctypes. That information combined with the policies can be used > to migrate the realm in phases. Exactly so. As an operator, one of the largest issues blocking my elimination of both single-DES and krb4 from our environment is the lack of tools that allow me to characterize request, not only by enctype and client principal, but also by other properties such as protocol, service principal, requested enctypes, client address/hostname, and so on. Such tools would go a long way toward making our lives easier. > In addition, improvements in support for key rollover must be provided. > If we are going to force a massive rollover of keys it should be > combined with support that permits key rollover to be performed on a > regular basis. That means, among other things, the ability to generate and store new service keys without taking them into use, the ability to begin issuing service tickets with a new key while still handling AS requests using the old client kvno (or vice versa), and a key management protocol and clients that support these operations. -- Jef From rra at stanford.edu Fri Jan 30 18:32:19 2009 From: rra at stanford.edu (Russ Allbery) Date: Fri, 30 Jan 2009 15:32:19 -0800 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: <5669C58E6DA594B4C6621C81@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Fri\, 30 Jan 2009 18\:23\:39 -0500") References: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> <20090130060405.GT1044@Sun.COM> <200901301519.n0UFJAvW028894@toasties.srv.cs.cmu.edu> <5669C58E6DA594B4C6621C81@minbar.fac.cs.cmu.edu> Message-ID: <87iqnwcqv0.fsf@windlord.stanford.edu> Jeffrey Hutzelman writes: > That means, among other things, the ability to generate and store new > service keys without taking them into use, the ability to begin issuing > service tickets with a new key while still handling AS requests using > the old client kvno (or vice versa), and a key management protocol and > clients that support these operations. I cannot emphasize enough how much I agree with this paragraph. All transition plans are rife with race conditions and deployment problems today without those capabilities. -- Russ Allbery (rra at stanford.edu) From Nicolas.Williams at sun.com Fri Jan 30 19:15:53 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 30 Jan 2009 18:15:53 -0600 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: <87iqnwcqv0.fsf@windlord.stanford.edu> References: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> <20090130060405.GT1044@Sun.COM> <200901301519.n0UFJAvW028894@toasties.srv.cs.cmu.edu> <5669C58E6DA594B4C6621C81@minbar.fac.cs.cmu.edu> <87iqnwcqv0.fsf@windlord.stanford.edu> Message-ID: <20090131001552.GP1044@Sun.COM> On Fri, Jan 30, 2009 at 03:32:19PM -0800, Russ Allbery wrote: > Jeffrey Hutzelman writes: > > > That means, among other things, the ability to generate and store new > > service keys without taking them into use, the ability to begin issuing > > service tickets with a new key while still handling AS requests using > > the old client kvno (or vice versa), and a key management protocol and > > clients that support these operations. > > I cannot emphasize enough how much I agree with this paragraph. All > transition plans are rife with race conditions and deployment problems > today without those capabilities. Will Fiveash just committed the infrastructure needed for this to the trunk as part of the master key migration project. Kudos Will! Nico -- From rra at stanford.edu Fri Jan 30 19:37:38 2009 From: rra at stanford.edu (Russ Allbery) Date: Fri, 30 Jan 2009 16:37:38 -0800 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: <20090131001552.GP1044@Sun.COM> (Nicolas Williams's message of "Fri\, 30 Jan 2009 18\:15\:53 -0600") References: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> <20090130060405.GT1044@Sun.COM> <200901301519.n0UFJAvW028894@toasties.srv.cs.cmu.edu> <5669C58E6DA594B4C6621C81@minbar.fac.cs.cmu.edu> <87iqnwcqv0.fsf@windlord.stanford.edu> <20090131001552.GP1044@Sun.COM> Message-ID: <87pri4b99p.fsf@windlord.stanford.edu> Nicolas Williams writes: > Will Fiveash just committed the infrastructure needed for this to the > trunk as part of the master key migration project. Kudos Will! That's great news! -- Russ Allbery (rra at stanford.edu) From Nicolas.Williams at sun.com Fri Jan 30 19:37:31 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 30 Jan 2009 18:37:31 -0600 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009 In-Reply-To: <20090131001552.GP1044@Sun.COM> References: <55D72F63-0FCD-4068-9896-79982850DEEF@sxw.org.uk> <20090130060405.GT1044@Sun.COM> <200901301519.n0UFJAvW028894@toasties.srv.cs.cmu.edu> <5669C58E6DA594B4C6621C81@minbar.fac.cs.cmu.edu> <87iqnwcqv0.fsf@windlord.stanford.edu> <20090131001552.GP1044@Sun.COM> Message-ID: <20090131003731.GS1044@Sun.COM> On Fri, Jan 30, 2009 at 06:15:53PM -0600, Nicolas Williams wrote: > On Fri, Jan 30, 2009 at 03:32:19PM -0800, Russ Allbery wrote: > > Jeffrey Hutzelman writes: > > > > > That means, among other things, the ability to generate and store new > > > service keys without taking them into use, the ability to begin issuing > > > service tickets with a new key while still handling AS requests using > > > the old client kvno (or vice versa), and a key management protocol and > > > clients that support these operations. > > > > I cannot emphasize enough how much I agree with this paragraph. All > > transition plans are rife with race conditions and deployment problems > > today without those capabilities. > > Will Fiveash just committed the infrastructure needed for this to the > trunk as part of the master key migration project. Kudos Will! BTW, all that's missing, IIUC, is kadmin changes to add options to the chpass/ktadd/modprinc commands to manage this for any princ. Nico -- From ghudson at MIT.EDU Fri Jan 30 21:22:27 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Fri, 30 Jan 2009 21:22:27 -0500 (EST) Subject: One cause of krb5 test suite slowness on some systems Message-ID: <200901310222.n0V2MR3v015348@outgoing.mit.edu> Since I've started working on Kerberos I've been burdened with the test suite taking around an hour to run, with the bulk of that time being in the dejagnu tests. I'm led to believe some others are also suffering under these conditions. Today I sat down and figured out a major source of slowness. Looking at tests/dejagnu/dbg.log, I found a lot of: write() failed to write anything - will sleep(1) and retry... It turns out this is due to a bug in expect and/or tcl. When tcl flushes a channel, it can (and I guess usually does) generate a zero-length write to the channel. When expect's channel code gets such a request, it dutifully tries to write zero bytes to the channel, sees that it didn't write any bytes, and freaks out, causing a one-second delay. This happens quite a few times during the course of a test suite run. The bug has been fixed in expect's sourceforge project since 2005, but not in any formal release. The tcl side of the bug (if you consider generating zero-length channel writes a bug) may also have been fixed for all I know. I can't find any evidence of a fix in the current sources, but tcl's channel code is pretty complicated. With that locally patched in my system's expect command, the tests/dejagnu part of the test suite dropped from 27 minutes to 12 minutes, and the overall test suite runs in about 20 minutes. That still probably reflects a lot of unnecessary delays (the "user" and "sys" times total to about 20 seconds) but it's progress. From tlyu at MIT.EDU Fri Jan 30 21:31:53 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Fri, 30 Jan 2009 21:31:53 -0500 Subject: near-term strategy for "disable DES" effort In-Reply-To: (Sam Hartman's message of "Fri, 30 Jan 2009 15:03:59 -0500") References: Message-ID: Sam Hartman writes: >>>>>> "Tom" == Tom Yu writes: > > Tom> * Implement the "allow_weak_crypto" libdefault setting. I > Tom> was leaning in favor of "false" but recent discussion of the > Tom> transition issues is calling that into question. Unless I > Tom> hear strong objections, I will assert that defaulting to > Tom> "false" is acceptable for the alpha release and am willing to > Tom> reconsider prior to final release. > > I strongly object to this unless you meet Ken's documentation > constraints. > > At a minimum, I think that > * user guide > * admin guide > * README > * kadmin man page > > need to be updated. And I agree with Ken this is true for the alpha. > > If you do this, I think it is reasonable to default to false. > Otherwise, I do not. For now I will default to "allow_weak_crypto=true", and we can reevaluate prior to the final release. I have also updated the project proposal page to include more detail. From ghudson at MIT.EDU Fri Jan 30 23:01:25 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Fri, 30 Jan 2009 23:01:25 -0500 Subject: One cause of krb5 test suite slowness on some systems In-Reply-To: <200901310222.n0V2MR3v015348@outgoing.mit.edu> References: <200901310222.n0V2MR3v015348@outgoing.mit.edu> Message-ID: <1233374485.6528.89.camel@ray> On Fri, 2009-01-30 at 21:22 -0500, ghudson at MIT.EDU wrote: > With that locally patched in my system's expect command, the > tests/dejagnu part of the test suite dropped from 27 minutes to 12 > minutes, and the overall test suite runs in about 20 minutes. That > still probably reflects a lot of unnecessary delays (the "user" and > "sys" times total to about 20 seconds) but it's progress. Upon further investigation, I think the remaining twelve minutes clocked by tests/dejagnu is almost accounted for from three sources: 1. We start daemons like kadmind and then run "tail -f" on a log file to see when they have started. On most systems, "tail -f" polls its input once per second, so that's a one-second delay per system. You can work around this problem on Linux by running "tail -f -s 0.01" instead to force faster polling. This workaround reduced my runtime from 12m to 10m on my system, although that's pretty unscientific due to the next item. 2. /dev/random exhaustion can result in unpredictable delays during the test suite. Hacking lib/crypto/prng.c to always use /dev/random reduced my runtime from 10m to 6m. 3. When starting some daemons, we don't even have the ability to tail -f a log file to look for a started message, so we have a hardcoded "sleep 2". These can add up pretty fast--for instance, we start krshd six times in each pass over rsh.exp, so in the 11 passes of the test suite, that sleep alone consumes 132 seconds. I haven't worked out a comprehensive total, but I'm pretty confident that almost all of the remaining six minutes is accounted for here. None of these issues is trivially fixed in a clean, portable fashion, but we have some ideas, and I believe Ken is working on some improvements to #3 using t_inetd. From raeburn at MIT.EDU Fri Jan 30 23:50:49 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Fri, 30 Jan 2009 23:50:49 -0500 Subject: One cause of krb5 test suite slowness on some systems In-Reply-To: <1233374485.6528.89.camel@ray> References: <200901310222.n0V2MR3v015348@outgoing.mit.edu> <1233374485.6528.89.camel@ray> Message-ID: On Jan 30, 2009, at 23:01, Greg Hudson wrote: > 1. We start daemons like kadmind and then run "tail -f" on a log > file to > see when they have started. On most systems, "tail -f" polls its > input > once per second, so that's a one-second delay per system. You can > work > around this problem on Linux by running "tail -f -s 0.01" instead to > force faster polling. This workaround reduced my runtime from 12m to > 10m on my system, although that's pretty unscientific due to the next > item. More portably, for the daemons looking at the [logging] stanza, we could tell them to additionally log to stderr, and have expect watch for output directly, and do away with the polling. > None of these issues is trivially fixed in a clean, portable fashion, > but we have some ideas, and I believe Ken is working on some > improvements to #3 using t_inetd. Fixed just now, for some of our tests. The ones that run as root still need tweaking. With this in place, we can probably also get rid of the code in various daemon programs for listening for a connection on a given port number, and assume they'll always be run under something inetd-like. Ken From tlyu at MIT.EDU Sat Jan 31 23:27:53 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Sat, 31 Jan 2009 23:27:53 -0500 Subject: krb5-1.7-alpha1 is available Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 MIT krb5-1.7-alpha1 is now available for download from http://web.mit.edu/kerberos/dist/ The main MIT Kerberos web page is http://web.mit.edu/kerberos/ Please send comments to the krbdev list. Major changes in 1.7 - -------------------- * Remove support for version 4 of the Kerberos protocol (krb4). * New libdefaults configuration variable "allow_weak_crypto". NOTE: Currently defaults to "false", but may default to "true" in a future release. Setting this variable to "false" will have the effect of removing weak enctypes (currently defined to be all single-DES enctypes) from permitted_enctypes, default_tkt_enctypes, and default_tgs_enctypes. * Client library now follows client principal referrals, for compatibility with Windows. * KDC can issue realm referrals for service principals based on domain names. * Encryption algorithm negotiation (RFC 4537). * In the replay cache, use a hash over the complete ciphertext to avoid false-positive replay indications. * Microsoft GSS_WrapEX, implemented using the gss_iov API, which is similar to the equivalent SSPI functionality. * DCE RPC, including three-leg GSS context setup and unencapsulated GSS tokens. * NTLM recognition support in GSS-API, to facilitate dropping in an NTLM implementation. * KDC support for principal aliases, if the back end supports them. * Microsoft set/change password (RFC 3244) protocol in kadmind. * Master key rollover support. For a more complete list of changes, please consult http://krbdev.mit.edu/rt/NoAuth/krb5-1.7/fixed-1.7.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (SunOS) iEYEARECAAYFAkmFJM0ACgkQSO8fWy4vZo4TrgCg8lOZDXcTpZC3WuQjdpRbkDhu kUUAoK+McC2Qg5bNXe6jN0920DSJ0ztz =Vjp3 -----END PGP SIGNATURE-----