From hartmans at MIT.EDU Mon Dec 1 09:46:46 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 1 Dec 2008 09:46:46 -0500 (EST) Subject: Project Write Up for set password (RFC 4234) Message-ID: <20081201144646.A1F934268@carter-zimmerman.suchdamage.org> Hi. One of the things I'll be working on is a write up of a project to add set/change password support to MIT Kerberos. How much detail do people need to see in that writeup? I actually think a paragraph explaining why we want to do it and the implementation approach is sufficient. The only reason I think a project writeup is needed is that we're going to be changing public functionality. However if there are folks out there who believe that more detail is required, I'd really appreciate what they want me to include. From hartmans at MIT.EDU Mon Dec 1 10:09:13 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 01 Dec 2008 10:09:13 -0500 Subject: Review of Projects/GSSAPI DCE concluding December 14, 2008 Message-ID: I'm calling for a two week review of http://k5wiki.kerberos.org/wiki/Projects/GSSAPI_DCE The GSS-API DCE project proposes to add functionality found in SSPI to MIT Kerberos; this functionality includes support for AEAD and support sufficient to implement DCE RPC on top of MIT Kerberos. This project depends on and is a companion to Projects/AEAD encryption API. Ken Raeburn has already indicated that he'd like to see a different name than gss_wrap_aead for that API. From lha at kth.se Mon Dec 1 00:43:07 2008 From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Sun, 30 Nov 2008 21:43:07 -0800 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: References: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se> Message-ID: <042FA76F-7F97-4644-B958-CC898D142C82@kth.se> Sam, Luke, all, > I believe it now includes enough of the GSS side API for comments. Some more comments, iov_count should not be size_t, it should be unsigned int. size_t is to describe memory sizes, iov_count is not that. I think the iov should be before iov_count in the argument, just like in writev()/readv(). What do conf_state do to gss_wrap_iov_length() ? How does the consumer know the conf_req_flag/qop_req arguments when doing gss_unwrap_iov() ? How does the consumer know the size of the header when in DCE mode, its always header + trailer ? Love From lha at kth.se Mon Dec 1 12:28:15 2008 From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Mon, 01 Dec 2008 09:28:15 -0800 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: References: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se> Message-ID: Sam, Luke, thanks for waiting the whole long weekend for comments. I don't like making flags and type whole 32bit fields but can live with it. I don't like having a flag for sign only, even though that more like how SSPI like does it, its a type and not a flag. I don't like that flags are not specified for what types they are valid for. I don't like that there are no examples. The second api, that I assume is called gss_*_aead, is not at all specified. Even though its mentioned. Or is the simpler interface STREAM ? gss_wrap_iov_length() is under specified. Re DCE, How does the caller now that know that the data is correctly padded and how do they get the padding size of before performing any operation given a gss_ctx_id_t ? I'll sure there should be more questions showing up when this is tried out more. But lets start with these. Love 25 nov 2008 kl. 22:00 skrev Sam Hartman: > Love, take a look at the Projects/GSSAPI > DCE > page > . > > I believe it now includes enough of the GSS side API for comments. From Nicolas.Williams at sun.com Mon Dec 1 13:07:52 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 1 Dec 2008 12:07:52 -0600 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: References: Message-ID: <20081201180751.GA21394@Sun.COM> For the decrypt side I think you need the option for: 1. One or more buffers of type KRB5_CRYPTO_TYPE_STREAM Instead of exactly one KRB5_CRYPTO_TYPE_STREAM chunk. The reason is that the peer may be sending data split into multiple chunks. Think of applications like RDDP, where the sender has used the IOV AEAD API and laid out the encrypted results and MICs of complex data structures such that each piece will end up in the right place on the receiving side. 2. Zero or more buffers of type KRB5_CRYPTO_TYPE_SIGN_ONLY 3. One or more buffers of type KRB5_CRYPTO_TYPE_DATA to hold the output Instead of exactly one KRB5_CRYPTO_TYPE_DATA chunk. The sizes of the input and output chunks should be matched for best results. Nico -- From lha at kth.se Mon Dec 1 13:29:41 2008 From: lha at kth.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Mon, 1 Dec 2008 10:29:41 -0800 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: <20081201180751.GA21394@Sun.COM> References: <20081201180751.GA21394@Sun.COM> Message-ID: <7098BDC2-C920-471F-A285-FD11BA338740@kth.se> Hello, I've not revived AEAD Encryption API, will try to do that later this week > For the decrypt side I think you need the option for: > > 1. One or more buffers of type KRB5_CRYPTO_TYPE_STREAM > > Instead of exactly one KRB5_CRYPTO_TYPE_STREAM chunk. > > The reason is that the peer may be sending data split into multiple > chunks. Think of applications like RDDP, where the sender has used > the IOV AEAD API and laid out the encrypted results and MICs of > complex data structures such that each piece will end up in the > right > place on the receiving side. What would be reason to use TYPE_STREAM instead of the old api's ? > 2. Zero or more buffers of type KRB5_CRYPTO_TYPE_SIGN_ONLY > 3. One or more buffers of type KRB5_CRYPTO_TYPE_DATA to hold the > output > > Instead of exactly one KRB5_CRYPTO_TYPE_DATA chunk. > > The sizes of the input and output chunks should be matched for best > results. I think there should be zero or more of both for of them. It seems strange to need to include a zero length DATA when I want to send an empty message with only a header. Love From hartmans at MIT.EDU Mon Dec 1 14:40:19 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 01 Dec 2008 14:40:19 -0500 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: <20081201180751.GA21394@Sun.COM> (Nicolas Williams's message of "Mon, 1 Dec 2008 12:07:52 -0600") References: <20081201180751.GA21394@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> For the decrypt side I think you need the option for: Nicolas> 1. One or more buffers of type KRB5_CRYPTO_TYPE_STREAM Nicolas> Instead of exactly one KRB5_CRYPTO_TYPE_STREAM chunk. Nicolas> The reason is that the peer may be sending data split Nicolas> into multiple chunks. Think of applications like RDDP, Nicolas> where the sender has used the IOV AEAD API and laid out Nicolas> the encrypted results and MICs of complex data structures Nicolas> such that each piece will end up in the right place on Nicolas> the receiving side. I don't think stream buffers would be useful in the rddp case: rddp has fairly strong information about the data layout. The only reason we include the stream buffer type is so that there is a relatively easy API to use if you have AEAD but you do not know the message structure. Otherwise you'd just use the old APIs. It makes the stream code significantly easier if it only has to deal with one stream buffer. So my belief is that this is not worth the code complexity. Based on a couple of wrong turns we made with handling padding, I think I have good handle on exactly how much complexity is introduced by supporting more buffers than is required. From hartmans at MIT.EDU Mon Dec 1 14:49:18 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 01 Dec 2008 14:49:18 -0500 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: <042FA76F-7F97-4644-B958-CC898D142C82@kth.se> (Love =?iso-8859-1?Q?H=F6rnquist=09=C5strand's?= message of "Sun, 30 Nov 2008 21:43:07 -0800") References: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se> <042FA76F-7F97-4644-B958-CC898D142C82@kth.se> Message-ID: >>>>> "Love" == Love H?rnquist ?strand writes: Love> Sam, Luke, all, >> I believe it now includes enough of the GSS side API for >> comments. Love> Some more comments, Love> iov_count should not be size_t, it should be unsigned Love> int. size_t is to describe memory sizes, iov_count is not Love> that. I think this is a style question. On my C library at least, qsort and calloc take size_t for their counts, while writev takes int. I don't have a strong preference, but in the interest of making changes only when there is a reason to do so, I'd say we should make this change only if we get others calling for it. Love> I think the iov should be before iov_count in the argument, Love> just like in writev()/readv(). Luke? This makes sense to me. Love> What do conf_state do to gss_wrap_iov_length() ? Love> How does the consumer know the conf_req_flag/qop_req Love> arguments when doing gss_unwrap_iov() ? These are not arguments to the call to gss_unwrap_iov. I assume what you're saying here is how does the unwrapper know what to pass in to gss_wrap_length_iov? Luke, do you anticipate that the receiver of a message would need to call wrap_length? I'd generally assume they would either use a stream buffer or would already know the decomposition. Love> How does the consumer know the size of the header when in Love> DCE mode, its always header + trailer ? No, I'd expect that in DCE mode no trailer would be used. It's my understanding that gss_wrap_iov_length will give you the header size. Love> Love From Nicolas.Williams at sun.com Mon Dec 1 14:43:24 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 1 Dec 2008 13:43:24 -0600 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: References: <20081201180751.GA21394@Sun.COM> Message-ID: <20081201194324.GN22026@Sun.COM> On Mon, Dec 01, 2008 at 02:40:19PM -0500, Sam Hartman wrote: > I don't think stream buffers would be useful in the rddp case: rddp > has fairly strong information about the data layout. Think of NFSv4-like COMPOUND above RDDP. A COMPOUND could have two bulk data operations interspersed with other operations. > It makes the stream code significantly easier if it only has to deal > with one stream buffer. So my belief is that this is not worth the > code complexity. Based on a couple of wrong turns we made with > handling padding, I think I have good handle on exactly how much > complexity is introduced by supporting more buffers than is required. I understand that, but please don't paint yourselves into a corner on this. Nico -- From hartmans at MIT.EDU Mon Dec 1 14:57:26 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 01 Dec 2008 14:57:26 -0500 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: (Love =?iso-8859-1?Q?H=F6rnquist=09=C5strand's?= message of "Mon, 01 Dec 2008 09:28:15 -0800") References: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se> Message-ID: >>>>> "Love" == Love H?rnquist ?strand writes: Love> Sam, Luke, thanks for waiting the whole long weekend for Love> comments. I don't like making flags and type whole 32bit Love> fields but can live with it. Is your concern that these are too big? Love> I don't like having a flag for sign only, even though that Love> more like how SSPI like does it, its a type and not a flag. I agree. Luke did this for compatibility with some work going on in the Samba community. My preference would be to do it right and make this be a type. Love> I don't like that flags are not specified for what types Love> they are valid for. That's a good point. I've noted it as an issue to resolve before we go forward. I think the answer is that sign_only only goes with data. allocate and allocated go with all but data. Love> I don't like that there are no examples. Want to write some?:-) Currently I think we only have resources scheduled for the implementation and the necessary modifications to be able to test this. I don't think I have time in my schedule/budget for examples, and I suspect that Luke will be fairly busy as well. I do completely agree that examples would be incredibly good here, and if we could get some community member to work on them that would be valuable. Love> The second api, that I assume is called gss_*_aead, is not Love> at all specified. Even though its mentioned. Or is the Love> simpler interface STREAM ? No, see gss_wrap_aead and gss_unwrap_aead. Love> gss_wrap_iov_length() is under specified. In what way? Love> Re DCE, How does the caller now that know that the data is Love> correctly padded and how do they get the padding size of Love> before performing any operation given a gss_ctx_id_t ? Luke? Love> I'll sure there should be more questions showing up when Love> this is tried out more. But lets start with these. O, yes, I'm sure we'll get questions when we implement using code:-) From hartmans at MIT.EDU Mon Dec 1 15:01:53 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 01 Dec 2008 15:01:53 -0500 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: <20081201194324.GN22026@Sun.COM> (Nicolas Williams's message of "Mon, 1 Dec 2008 13:43:24 -0600") References: <20081201180751.GA21394@Sun.COM> <20081201194324.GN22026@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Mon, Dec 01, 2008 at 02:40:19PM -0500, Sam Hartman Nicolas> wrote: >> I don't think stream buffers would be useful in the rddp case: >> rddp has fairly strong information about the data layout. Nicolas> Think of NFSv4-like COMPOUND above RDDP. A COMPOUND Nicolas> could have two bulk data operations interspersed with Nicolas> other operations. I'm still missing it. Why do you think this compound will not be able to identify the crypto header and trailer? >> It makes the stream code significantly easier if it only has to >> deal with one stream buffer. So my belief is that this is not >> worth the code complexity. Based on a couple of wrong turns we >> made with handling padding, I think I have good handle on >> exactly how much complexity is introduced by supporting more >> buffers than is required. Nicolas> I understand that, but please don't paint yourselves into Nicolas> a corner on this. I think expanding the API in the future would be easy from an interface standpoint. I think that the current behavior is to return an error if you pass in multiple stream buffers, so you can tell which API you have. From Nicolas.Williams at sun.com Mon Dec 1 15:05:40 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 1 Dec 2008 14:05:40 -0600 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: References: <20081201180751.GA21394@Sun.COM> <20081201194324.GN22026@Sun.COM> Message-ID: <20081201200539.GO22026@Sun.COM> On Mon, Dec 01, 2008 at 03:01:53PM -0500, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > Nicolas> Think of NFSv4-like COMPOUND above RDDP. A COMPOUND > Nicolas> could have two bulk data operations interspersed with > Nicolas> other operations. > > I'm still missing it. > Why do you think this compound will not be able to identify the crypto header and trailer? That's not the problem. The problem is that in that example there are two large chunks of data that will be directly placed into different destinations. Think of a pattern like: crypto header, app header, app data, app header, app data, ..., crypto trailer, MIC. > Nicolas> I understand that, but please don't paint yourselves into > Nicolas> a corner on this. > > I think expanding the API in the future would be easy from an > interface standpoint. I think that the current behavior is to return > an error if you pass in multiple stream buffers, so you can tell which > API you have. Make sure the same applies to the GSS-API extensions. Nico -- From Nicolas.Williams at sun.com Mon Dec 1 15:41:26 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 1 Dec 2008 14:41:26 -0600 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: <20081201200539.GO22026@Sun.COM> References: <20081201180751.GA21394@Sun.COM> <20081201194324.GN22026@Sun.COM> <20081201200539.GO22026@Sun.COM> Message-ID: <20081201204125.GQ22026@Sun.COM> On Mon, Dec 01, 2008 at 02:05:40PM -0600, Nicolas Williams wrote: > > Nicolas> I understand that, but please don't paint yourselves into > > Nicolas> a corner on this. > > > > I think expanding the API in the future would be easy from an > > interface standpoint. I think that the current behavior is to return > > an error if you pass in multiple stream buffers, so you can tell which > > API you have. > > Make sure the same applies to the GSS-API extensions. One thing that seems potentially important would be to communicate to the application what alignment is preferred. Splitting encryption or decryption of a block of data across two chunks is likely to cause performance problems (think of crypto HW). Nico -- From hartmans at MIT.EDU Mon Dec 1 16:01:02 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 01 Dec 2008 16:01:02 -0500 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: <20081201200539.GO22026@Sun.COM> (Nicolas Williams's message of "Mon, 1 Dec 2008 14:05:40 -0600") References: <20081201180751.GA21394@Sun.COM> <20081201194324.GN22026@Sun.COM> <20081201200539.GO22026@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Mon, Dec 01, 2008 at 03:01:53PM -0500, Sam Hartman Nicolas> wrote: >> >>>>> "Nicolas" == Nicolas Williams >> writes: Nicolas> Think of NFSv4-like COMPOUND above RDDP. A COMPOUND Nicolas> could have two bulk data operations interspersed with Nicolas> other operations. >> I'm still missing it. Why do you think this compound will not >> be able to identify the crypto header and trailer? Nicolas> That's not the problem. The problem is that in that Nicolas> example there are two large chunks of data that will be Nicolas> directly placed into different destinations. If you know where the header and trailer are, then don't use the stream cryptotype. Nicolas> Think of a pattern like: crypto header, app header, app Nicolas> data, app header, app data, ..., crypto trailer, MIC. I would not use stream for this pattern. Nicolas> I understand that, but please don't paint yourselves into Nicolas> a corner on this. >> I think expanding the API in the future would be easy from an >> interface standpoint. I think that the current behavior is to >> return an error if you pass in multiple stream buffers, so you >> can tell which API you have. Nicolas> Make sure the same applies to the GSS-API extensions. I have not reviewed that code yet, but I think the same is true of the iov GSS extension. From jhutz at cmu.edu Mon Dec 1 16:12:53 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Mon, 01 Dec 2008 16:12:53 -0500 Subject: Review of Projects/GSSAPI DCE concluding December 14, 2008 In-Reply-To: <200812011511.mB1FBnkZ023124@toasties.srv.cs.cmu.edu> References: <200812011511.mB1FBnkZ023124@toasties.srv.cs.cmu.edu> Message-ID: <58E6F81363211DF64A332F17@minbar.fac.cs.cmu.edu> --On Monday, December 01, 2008 10:09:13 AM -0500 Sam Hartman wrote: > I'm calling for a two week review of > http://k5wiki.kerberos.org/wiki/Projects/GSSAPI_DCE > > The GSS-API DCE project proposes to add functionality found in SSPI to > MIT Kerberos; this functionality includes support for AEAD and > support sufficient to implement DCE RPC on top of MIT Kerberos. > This project depends on and is a companion to Projects/AEAD > encryption API. > > > > Ken Raeburn has already indicated that he'd like to see a different name > than gss_wrap_aead for that API. I have to ask why you're proposing adding proprietary extensions to the GSS-API involving structures and functions with gss_* names. It seems like this is a suitable subject for standardization, and while you may not be interested in going down that route, using gss_* names without doing so seems like an exceptionally poor choice. -- Jeff From jhutz at cmu.edu Mon Dec 1 16:18:34 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Mon, 01 Dec 2008 16:18:34 -0500 Subject: Project Write Up for set password (RFC 4234) In-Reply-To: <200812011447.mB1ElveX013980@grapenut.srv.cs.cmu.edu> References: <200812011447.mB1ElveX013980@grapenut.srv.cs.cmu.edu> Message-ID: <10ADBB7D1E7AF1DFA3B3B8D7@minbar.fac.cs.cmu.edu> --On Monday, December 01, 2008 09:46:46 AM -0500 Sam Hartman wrote: > > > Hi. One of the things I'll be working on is a write up of a project > to add set/change password support to MIT Kerberos. > > How much detail do people need to see in that writeup? I actually > think a paragraph explaining why we want to do it and the > implementation approach is sufficient. The only reason I think a > project writeup is needed is that we're going to be changing public > functionality. Uh, RFC4234 is ABNF. Perhaps you meant RFC3244? I think if the answer to "why" is anything other than "to be compatible with existing Windows", then it should at least touch on why you're not implementing draft-ietf-krb-wg-kerberos-set-passwd-08.txt instead. You say you're changing public functionality; are you planning on phasing out the current kpasswd service? From hartmans at MIT.EDU Mon Dec 1 16:22:21 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 01 Dec 2008 16:22:21 -0500 Subject: Project Write Up for set password (RFC 4234) In-Reply-To: <10ADBB7D1E7AF1DFA3B3B8D7@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Mon, 01 Dec 2008 16:18:34 -0500") References: <200812011447.mB1ElveX013980@grapenut.srv.cs.cmu.edu> <10ADBB7D1E7AF1DFA3B3B8D7@minbar.fac.cs.cmu.edu> Message-ID: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> You say you're changing public functionality; are you Jeffrey> planning on phasing out the current kpasswd service? no. From Nicolas.Williams at sun.com Mon Dec 1 16:18:53 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 1 Dec 2008 15:18:53 -0600 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: References: <20081201180751.GA21394@Sun.COM> <20081201194324.GN22026@Sun.COM> <20081201200539.GO22026@Sun.COM> Message-ID: <20081201211852.GS22026@Sun.COM> On Mon, Dec 01, 2008 at 04:01:02PM -0500, Sam Hartman wrote: > Nicolas> That's not the problem. The problem is that in that > Nicolas> example there are two large chunks of data that will be > Nicolas> directly placed into different destinations. > If you know where the header and trailer are, then don't use the > stream cryptotype. I'm not sure I follow. > Nicolas> Think of a pattern like: crypto header, app header, app > Nicolas> data, app header, app data, ..., crypto trailer, MIC. > I would not use stream for this pattern. What would you do? > Nicolas> I understand that, but please don't paint yourselves into > Nicolas> a corner on this. > >> I think expanding the API in the future would be easy from an > >> interface standpoint. I think that the current behavior is to > >> return an error if you pass in multiple stream buffers, so you > >> can tell which API you have. > > Nicolas> Make sure the same applies to the GSS-API extensions. > > I have not reviewed that code yet, but I think the same is true of the > iov GSS extension. Makes sense. I'll look at that too. From Nicolas.Williams at sun.com Mon Dec 1 16:23:25 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 1 Dec 2008 15:23:25 -0600 Subject: Review of Projects/GSSAPI DCE concluding December 14, 2008 In-Reply-To: <58E6F81363211DF64A332F17@minbar.fac.cs.cmu.edu> References: <200812011511.mB1FBnkZ023124@toasties.srv.cs.cmu.edu> <58E6F81363211DF64A332F17@minbar.fac.cs.cmu.edu> Message-ID: <20081201212325.GU22026@Sun.COM> On Mon, Dec 01, 2008 at 04:12:53PM -0500, Jeffrey Hutzelman wrote: > I have to ask why you're proposing adding proprietary extensions to the > GSS-API involving structures and functions with gss_* names. It seems like > this is a suitable subject for standardization, and while you may not be > interested in going down that route, using gss_* names without doing so > seems like an exceptionally poor choice. Well, we really should just wrap up the IANA registry of GSS-API namespaces and then Luke and Sam could register these extensions. Ah, yes, I own that doc. From Nicolas.Williams at sun.com Mon Dec 1 16:26:33 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 1 Dec 2008 15:26:33 -0600 Subject: Project Write Up for set password (RFC 4234) In-Reply-To: <10ADBB7D1E7AF1DFA3B3B8D7@minbar.fac.cs.cmu.edu> References: <200812011447.mB1ElveX013980@grapenut.srv.cs.cmu.edu> <10ADBB7D1E7AF1DFA3B3B8D7@minbar.fac.cs.cmu.edu> Message-ID: <20081201212633.GV22026@Sun.COM> On Mon, Dec 01, 2008 at 04:18:34PM -0500, Jeffrey Hutzelman wrote: > --On Monday, December 01, 2008 09:46:46 AM -0500 Sam Hartman > wrote: > > Hi. One of the things I'll be working on is a write up of a project > > to add set/change password support to MIT Kerberos. > > > > How much detail do people need to see in that writeup? I actually > > think a paragraph explaining why we want to do it and the > > implementation approach is sufficient. The only reason I think a > > project writeup is needed is that we're going to be changing public > > functionality. > > Uh, RFC4234 is ABNF. Perhaps you meant RFC3244? > > I think if the answer to "why" is anything other than "to be compatible > with existing Windows", then it should at least touch on why you're not > implementing draft-ietf-krb-wg-kerberos-set-passwd-08.txt instead. I think the answer to "why" must be the former. I doubt Sam has any interest in draft-ietf-krb-wg-kerberos-set-passwd, though the Consortium well might (should, even). Also, Solaris has an implementation of RFC3244. If MIT could use it then perhaps a code donation might be feasible. Nico -- From lukeh at padl.com Mon Dec 1 16:43:10 2008 From: lukeh at padl.com (Luke Howard) Date: Tue, 2 Dec 2008 08:43:10 +1100 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: References: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se> <042FA76F-7F97-4644-B958-CC898D142C82@kth.se> Message-ID: > These are not arguments to the call to gss_unwrap_iov. I assume what > you're saying here is how does the unwrapper know what to pass in to > gss_wrap_length_iov? Luke, do you anticipate that the receiver of a > message would need to call wrap_length? I'd generally assume they > would either use a stream buffer or would already know the > decomposition. Agreed. > Love> How does the consumer know the size of the header when in > Love> DCE mode, its always header + trailer ? > No, I'd expect that in DCE mode no trailer would be used. > It's my understanding that gss_wrap_iov_length will give you the > header size. Correct. -- Luke From lukeh at padl.com Mon Dec 1 16:44:54 2008 From: lukeh at padl.com (Luke Howard) Date: Tue, 2 Dec 2008 08:44:54 +1100 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: References: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se> Message-ID: <4A3AAB79-43F0-4148-9B44-3C3E71B13314@padl.com> > Luke did this for compatibility with some work going on in the Samba > community. > My preference would be to do it right and make this be a type. Correct, I used the API proposed by Stefan (copied). Stefan, perhaps you could explain why you made flags and type separate fields in the IOV structure? > Love> Re DCE, How does the caller now that know that the data is > Love> correctly padded and how do they get the padding size of > Love> before performing any operation given a gss_ctx_id_t ? > Luke? My understanding is that DCE always pads to 16 bytes and does not support cryptosystems that require greater padding. -- Luke From lukeh at padl.com Mon Dec 1 16:49:50 2008 From: lukeh at padl.com (Luke Howard) Date: Tue, 2 Dec 2008 08:49:50 +1100 Subject: Project Write Up for set password (RFC 4234) In-Reply-To: <20081201212633.GV22026@Sun.COM> References: <200812011447.mB1ElveX013980@grapenut.srv.cs.cmu.edu> <10ADBB7D1E7AF1DFA3B3B8D7@minbar.fac.cs.cmu.edu> <20081201212633.GV22026@Sun.COM> Message-ID: > Also, Solaris has an implementation of RFC3244. If MIT could use it > then perhaps a code donation might be feasible. The mskrb-integ branch contains a working implementation of RFC3244 (both TCP and set password support). -- Luke From Nicolas.Williams at sun.com Mon Dec 1 16:21:58 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 1 Dec 2008 15:21:58 -0600 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: <7098BDC2-C920-471F-A285-FD11BA338740@kth.se> References: <20081201180751.GA21394@Sun.COM> <7098BDC2-C920-471F-A285-FD11BA338740@kth.se> Message-ID: <20081201212158.GT22026@Sun.COM> On Mon, Dec 01, 2008 at 10:29:41AM -0800, Love H?rnquist ?strand wrote: > >For the decrypt side I think you need the option for: > > > >[...] > > What would be reason to use TYPE_STREAM instead of the old api's ? In a reply to Sam I described an NFSv4-like protocol with COMPOUND-like messages and RDDP-like (different parts of the message will be deivered by the NIC into different locations in memory on receive, and may come from different locations in memory on send). > >2. Zero or more buffers of type KRB5_CRYPTO_TYPE_SIGN_ONLY > >3. One or more buffers of type KRB5_CRYPTO_TYPE_DATA to hold the > >output > > > > Instead of exactly one KRB5_CRYPTO_TYPE_DATA chunk. > > > > The sizes of the input and output chunks should be matched for best > > results. > > I think there should be zero or more of both for of them. It seems > strange to need to include a zero length DATA when I want to send an > empty message with only a header. Good point! Nico -- From hartmans at MIT.EDU Mon Dec 1 16:56:17 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 01 Dec 2008 16:56:17 -0500 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: <20081201211852.GS22026@Sun.COM> (Nicolas Williams's message of "Mon, 1 Dec 2008 15:18:53 -0600") References: <20081201180751.GA21394@Sun.COM> <20081201194324.GN22026@Sun.COM> <20081201200539.GO22026@Sun.COM> <20081201211852.GS22026@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Mon, Dec 01, 2008 at 04:01:02PM -0500, Sam Hartman Nicolas> wrote: That's not the problem. The problem is that in Nicolas> that example there are two large chunks of data that will Nicolas> be directly placed into different destinations. >> If you know where the header and trailer are, then don't use >> the stream cryptotype. Nicolas> I'm not sure I follow. Use the first calling pattern for decrypt: pass in a header buffer, multiple data buffers and a trailer buffer. Stream is only for when you don't want to decompose the structure; look at decrypt_stream in aead.con the mskrb-integ-crypto-iov branch in opengrok. From hartmans at MIT.EDU Mon Dec 1 16:57:40 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 01 Dec 2008 16:57:40 -0500 Subject: Review of Projects/GSSAPI DCE concluding December 14, 2008 In-Reply-To: <20081201212325.GU22026@Sun.COM> (Nicolas Williams's message of "Mon, 1 Dec 2008 15:23:25 -0600") References: <200812011511.mB1FBnkZ023124@toasties.srv.cs.cmu.edu> <58E6F81363211DF64A332F17@minbar.fac.cs.cmu.edu> <20081201212325.GU22026@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Mon, Dec 01, 2008 at 04:12:53PM -0500, Jeffrey Nicolas> Hutzelman wrote: >> I have to ask why you're proposing adding proprietary >> extensions to the GSS-API involving structures and functions >> with gss_* names. It seems like this is a suitable subject for >> standardization, and while you may not be interested in going >> down that route, using gss_* names without doing so seems like >> an exceptionally poor choice. Nicolas> Well, we really should just wrap up the IANA registry of Nicolas> GSS-API namespaces and then Luke and Sam could register Nicolas> these extensions. Making sure that we are aligned with GSS-API iana is budgeted for and in scope. I definitely should have noted this as an open issue in the project. From Nicolas.Williams at sun.com Mon Dec 1 16:58:41 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 1 Dec 2008 15:58:41 -0600 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: References: <20081201180751.GA21394@Sun.COM> <20081201194324.GN22026@Sun.COM> <20081201200539.GO22026@Sun.COM> <20081201211852.GS22026@Sun.COM> Message-ID: <20081201215841.GB22026@Sun.COM> On Mon, Dec 01, 2008 at 04:56:17PM -0500, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Mon, Dec 01, 2008 at 04:01:02PM -0500, Sam Hartman > Nicolas> wrote: That's not the problem. The problem is that in > Nicolas> that example there are two large chunks of data that will > Nicolas> be directly placed into different destinations. > >> If you know where the header and trailer are, then don't use > >> the stream cryptotype. > > Nicolas> I'm not sure I follow. > > Use the first calling pattern for decrypt: pass in a header buffer, > multiple data buffers and a trailer buffer. Stream is only for when > you don't want to decompose the structure; look at decrypt_stream in aead.con > the mskrb-integ-crypto-iov branch in opengrok. Oh! OK, I see what I misunderstood. Thanks. From hartmans at MIT.EDU Mon Dec 1 17:08:11 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 01 Dec 2008 17:08:11 -0500 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: <4A3AAB79-43F0-4148-9B44-3C3E71B13314@padl.com> (Luke Howard's message of "Tue, 2 Dec 2008 08:44:54 +1100") References: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se> <4A3AAB79-43F0-4148-9B44-3C3E71B13314@padl.com> Message-ID: >>>>> "Luke" == Luke Howard writes: >> Luke did this for compatibility with some work going on in the >> Samba community. My preference would be to do it right and >> make this be a type. Luke> Correct, I used the API proposed by Stefan (copied). Stefan, Luke> perhaps you could explain why you made flags and type Luke> separate fields in the IOV structure? Hmm. I think Love was asking more about why sign_only was was a flag not a separate type from data. However if we did make sign_only be a type, then perhaps we could fold alloc and allocated as higher order bits in the type and avoid the flags field. --Sam From Nicolas.Williams at sun.com Mon Dec 1 16:58:02 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 1 Dec 2008 15:58:02 -0600 Subject: Project Write Up for set password (RFC 4234) In-Reply-To: References: <200812011447.mB1ElveX013980@grapenut.srv.cs.cmu.edu> <10ADBB7D1E7AF1DFA3B3B8D7@minbar.fac.cs.cmu.edu> <20081201212633.GV22026@Sun.COM> Message-ID: <20081201215802.GA22026@Sun.COM> On Tue, Dec 02, 2008 at 08:49:50AM +1100, Luke Howard wrote: > >Also, Solaris has an implementation of RFC3244. If MIT could use it > >then perhaps a code donation might be feasible. > > The mskrb-integ branch contains a working implementation of RFC3244 > (both TCP and set password support). OK. Do look at krb5.conf(4) on Solaris: http://docs.sun.com/app/docs/doc/816-5174/krb5.conf-4?a=view You might want to be compatible with how we configure use of RFC3244. Nico -- From Nicolas.Williams at sun.com Mon Dec 1 17:13:16 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 1 Dec 2008 16:13:16 -0600 Subject: Project Write Up for set password (RFC 4234) In-Reply-To: References: <200812011447.mB1ElveX013980@grapenut.srv.cs.cmu.edu> <10ADBB7D1E7AF1DFA3B3B8D7@minbar.fac.cs.cmu.edu> <20081201212633.GV22026@Sun.COM> Message-ID: <20081201221316.GD22026@Sun.COM> On Tue, Dec 02, 2008 at 08:49:50AM +1100, Luke Howard wrote: > >Also, Solaris has an implementation of RFC3244. If MIT could use it > >then perhaps a code donation might be feasible. > > > The mskrb-integ branch contains a working implementation of RFC3244 > (both TCP and set password support). Oh, perhaps this is server-side we're talking about. I don't know if we have a server-side implementation. I'll shut up about this now :) From lukeh at padl.com Mon Dec 1 17:32:57 2008 From: lukeh at padl.com (Luke Howard) Date: Tue, 2 Dec 2008 09:32:57 +1100 Subject: Project Write Up for set password (RFC 4234) In-Reply-To: <20081201215802.GA22026@Sun.COM> References: <200812011447.mB1ElveX013980@grapenut.srv.cs.cmu.edu> <10ADBB7D1E7AF1DFA3B3B8D7@minbar.fac.cs.cmu.edu> <20081201212633.GV22026@Sun.COM> <20081201215802.GA22026@Sun.COM> Message-ID: <23FB6BED-AB43-4BA7-B29C-608FF4BB3072@padl.com> On 02/12/2008, at 8:58 AM, Nicolas Williams wrote: > On Tue, Dec 02, 2008 at 08:49:50AM +1100, Luke Howard wrote: >>> Also, Solaris has an implementation of RFC3244. If MIT could use it >>> then perhaps a code donation might be feasible. >> >> The mskrb-integ branch contains a working implementation of RFC3244 >> (both TCP and set password support). > > OK. Do look at krb5.conf(4) on Solaris: > > http://docs.sun.com/app/docs/doc/816-5174/krb5.conf-4?a=view > > You might want to be compatible with how we configure use of RFC3244. I'm not sure this is relevant. If you use the kpasswd program, the kpasswd protocol is used. If you use ksetpwd, RFC 3244 is used. My work was principally concerned with server-side support (in kadmind). The bulk of that work was in multiplexing TCP and RPC listeners, rather than the set password protocol itself. -- Luke From lukeh at padl.com Mon Dec 1 17:46:56 2008 From: lukeh at padl.com (Luke Howard) Date: Tue, 2 Dec 2008 09:46:56 +1100 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: References: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se> <4A3AAB79-43F0-4148-9B44-3C3E71B13314@padl.com> Message-ID: <67478052-9243-431D-93E1-5FD0597101BD@padl.com> Why not just make them 16 bits wide? Sent from my iPhone On 02/12/2008, at 9:08 AM, Sam Hartman wrote: >>>>>> "Luke" == Luke Howard writes: > >>> Luke did this for compatibility with some work going on in the >>> Samba community. My preference would be to do it right and >>> make this be a type. > > Luke> Correct, I used the API proposed by Stefan (copied). Stefan, > Luke> perhaps you could explain why you made flags and type > Luke> separate fields in the IOV structure? > > > Hmm. I think Love was asking more about why sign_only was was a flag > not a separate type from data. However if we did make sign_only be a > type, then perhaps we could fold alloc and allocated as higher order > bits in the type and avoid the flags field. > > > --Sam > > From guenther at gmail.com Mon Dec 1 21:17:18 2008 From: guenther at gmail.com (Philip Guenther) Date: Mon, 1 Dec 2008 18:17:18 -0800 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: References: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se> <042FA76F-7F97-4644-B958-CC898D142C82@kth.se> Message-ID: On Mon, Dec 1, 2008 at 11:49 AM, Sam Hartman wrote: >>>>>> "Love" == Love H?rnquist ?strand writes: ... > Love> iov_count should not be size_t, it should be unsigned > Love> int. size_t is to describe memory sizes, iov_count is not > Love> that. > > I think this is a style question. On my C library at least, qsort and > calloc take size_t for their counts, while writev takes int. I don't > have a strong preference, but in the interest of making changes only > when there is a reason to do so, I'd say we should make this change > only if we get others calling for it. I'm with Love on this one. XPG and the SUS have specified for better than a decade that the iov count for writev(), readv(), and the struct msghdr used with sendmsg() and recvmsg() is to be of type 'int'. To create a new interface that was so obviously modeled on those but differ on that point, I would expect some sort of justification for the difference. Philip Guenther From hartmans at MIT.EDU Tue Dec 2 03:42:05 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 02 Dec 2008 03:42:05 -0500 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: (Philip Guenther's message of "Mon, 1 Dec 2008 18:17:18 -0800") References: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se> <042FA76F-7F97-4644-B958-CC898D142C82@kth.se> Message-ID: Luke has made changes to reorder the arguments and to use int; these changes are waiting to be committed on me completing some merges. --Sam From lha at kth.se Tue Dec 2 12:46:20 2008 From: lha at kth.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Tue, 2 Dec 2008 09:46:20 -0800 Subject: Review of Kerberos AEAP API Message-ID: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> Hello here is my comments from the initial pass over the document. Limiting to only on DATA buffer is overly restrictive. On decryption, the HEADER/TRAILER data should be define to be read only as well as the ivec content, ie it should be possible to setup an recv'er ivec array and keep reusing it over and over again w/o re-init the data. There should be an option to have a readonly DATA buffer, but I can live w/o that for now. Love From lha at kth.se Tue Dec 2 12:58:28 2008 From: lha at kth.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Tue, 2 Dec 2008 09:58:28 -0800 Subject: Review of Kerberos AEAP API In-Reply-To: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> References: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> Message-ID: 2 dec 2008 kl. 09.46 skrev Love H?rnquist ?strand: > Hello here is my comments from the initial pass over the document. > > Limiting to only on DATA buffer is overly restrictive. > > On decryption, the HEADER/TRAILER data should be define to be read > only as well as the ivec content, ie it should be possible to setup an > recv'er ivec array and keep reusing it over and over again w/o re-init > the data. > > There should be an option to have a readonly DATA buffer, but I can > live w/o that for now. All sizes, even pointers to sizes should be of type size_t (resp size_t *). Love From lha at kth.se Tue Dec 2 13:35:27 2008 From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Tue, 02 Dec 2008 10:35:27 -0800 Subject: Review of Kerberos AEAP API In-Reply-To: <20081202180611.GM22970@Sun.COM> References: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> <20081202180611.GM22970@Sun.COM> Message-ID: <83EB9B34-C32B-460D-A2C2-2FC060F97165@kth.se> 2 dec 2008 kl. 19:06 skrev Nicolas Williams: > On Tue, Dec 02, 2008 at 09:46:20AM -0800, Love H?rnquist ?strand > wrote: >> Hello here is my comments from the initial pass over the document. >> >> Limiting to only on DATA buffer is overly restrictive. > > I made the same comment. I strongly recommend that more than one DATA > buffer be allowed on encryption and decryption. At the very least the > API needs to allow for support for more than DATA buffer to be added > in > the future (but I think it effectively does). > >> On decryption, the HEADER/TRAILER data should be define to be read >> only as well as the ivec content, ie it should be possible to setup >> an > > I don't understand that. Setup header, data (padding right), trailer in a ivec, fill with data, call decrypt, fill with new data, decrypt again. The decryption should not touch header/trail data, nor the content of header/trailer so that there is only one setup needed. >> recv'er ivec array and keep reusing it over and over again w/o re- >> init >> the data. >> >> There should be an option to have a readonly DATA buffer, but I can >> live w/o that for now. > > So an option to not always do in-place crypto? It could be useful on > encryption for filesystems (where the source is a page in the fs page > cache that must not be modified, say). Or (more likly) RO network buffers. Love From Nicolas.Williams at sun.com Tue Dec 2 13:06:12 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 2 Dec 2008 12:06:12 -0600 Subject: Review of Kerberos AEAP API In-Reply-To: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> References: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> Message-ID: <20081202180611.GM22970@Sun.COM> On Tue, Dec 02, 2008 at 09:46:20AM -0800, Love H?rnquist ?strand wrote: > Hello here is my comments from the initial pass over the document. > > Limiting to only on DATA buffer is overly restrictive. I made the same comment. I strongly recommend that more than one DATA buffer be allowed on encryption and decryption. At the very least the API needs to allow for support for more than DATA buffer to be added in the future (but I think it effectively does). > On decryption, the HEADER/TRAILER data should be define to be read > only as well as the ivec content, ie it should be possible to setup an I don't understand that. > recv'er ivec array and keep reusing it over and over again w/o re-init > the data. > > There should be an option to have a readonly DATA buffer, but I can > live w/o that for now. So an option to not always do in-place crypto? It could be useful on encryption for filesystems (where the source is a page in the fs page cache that must not be modified, say). Nico -- From lukeh at padl.com Tue Dec 2 18:27:56 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 3 Dec 2008 10:27:56 +1100 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: References: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se> <042FA76F-7F97-4644-B958-CC898D142C82@kth.se> Message-ID: <2F2CFCC1-9088-4B6A-9C8E-D75C96481023@padl.com> > I'm with Love on this one. XPG and the SUS have specified for better > than a decade that the iov count for writev(), readv(), and the struct > msghdr used with sendmsg() and recvmsg() is to be of type 'int'. To > create a new interface that was so obviously modeled on those but > differ on that point, I would expect some sort of justification for > the difference. OK, I have reordered the iov and iov_count parameters (so the count comes after the iov), and changed the count to an int rather than size_t. -- Luke From hartmans at painless-security.com Wed Dec 3 05:11:39 2008 From: hartmans at painless-security.com (Sam Hartman) Date: Wed, 03 Dec 2008 05:11:39 -0500 Subject: Behavior change of krb5_rd_req: what error to return Message-ID: Folks, as part of http://k5wiki.kerberos.org/wiki/Projects/Unicode_and_case_folding we're looking at changing the behavior of krb5_rd_req to better support server principal aliases. The idea is that we're ignoring the principal in the ticket and doing one of two things. If a service principal is supplied to krb5_rd_req, we use that to find keytab entries. Otherwise, we loop. Comments on this approach are appreciated now; that project has not reached review stage, but it would be useful to know about problems now. As far as I can tell, the approach works quite well and is going to make service aliases much easier to deal with. The obvious implementation of this ends up changing the errors that are returned in case you can't find the right principal. You get KRB5KRB_AP_BAD_INTEGRITY instead of KRB5KRB_AP_WRONG_PRINC. We've noticed that code in our tree depends on getting WRONG_PRINC--for example libgssrpc uses this to loop through potential service principals. It seems likely people outside our tree may do this. The best solution I have so far is to map KRB5KRB_AP_BAD_INTEGRITY to KRB5KRB_AP_WRONG_PRINC in krb5_rd_req. I think we may also want to update the error message to indicate something like "Wrong principal or key in request." We could actually do a bit better than that. we could see if the principal in the ticket happens to match any of the principals we've tried and return BAD_INTEGRITY in that case. Doing so will keep the behavior very close to what we expect today. However as people start using aliases on the KDC you will get into more and more situations where we cannot actually tell whether the principal is correct so we'll have to guess WRONG_PRINC instead of BAD_INTEGRITY. I think that assuming WRONG_PRINC instead of BAD_INTEGRITY is the correct way to go. I've run into far more situations where I ended up presenting the wrong service ticket (DNS confusion, etc) than where the KDC and service were out of sync about what key to use, but had the same kvno. Comments? --Sam From ghudson at MIT.EDU Wed Dec 3 11:16:32 2008 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 03 Dec 2008 11:16:32 -0500 Subject: Behavior change of krb5_rd_req: what error to return In-Reply-To: References: Message-ID: <1228320992.20381.4.camel@ray> On Wed, 2008-12-03 at 05:11 -0500, Sam Hartman wrote: > The best solution I have so far is to map KRB5KRB_AP_BAD_INTEGRITY to > KRB5KRB_AP_WRONG_PRINC in krb5_rd_req. That's not exactly how I'd think about it; I'd say KRB5KRB_AP_BAD_INTEGRITY is a caught exception which just indicates that the loop should continue, and KRB5KRB_AP_WRONG_PRINC indicates that the loop finished without finding a match. > We could actually do a bit better than that. we could see if the > principal in the ticket happens to match any of the principals we've > tried and return BAD_INTEGRITY in that case. Doing so will keep the > behavior very close to what we expect today. However as people start using aliases on the KDC you will get into more and more situations where we cannot actually tell whether the principal is correct so we'll have to guess WRONG_PRINC instead of BAD_INTEGRITY. Agreed, if we accept the assumption that servers do not know how to compare client-provided principal names against keytab principals in the general case. From hartmans at painless-security.com Wed Dec 3 11:27:39 2008 From: hartmans at painless-security.com (Sam Hartman) Date: Wed, 03 Dec 2008 11:27:39 -0500 Subject: Behavior change of krb5_rd_req: what error to return In-Reply-To: <1228320992.20381.4.camel@ray> (Greg Hudson's message of "Wed, 03 Dec 2008 11:16:32 -0500") References: <1228320992.20381.4.camel@ray> Message-ID: >>>>> "Greg" == Greg Hudson writes: Greg> On Wed, 2008-12-03 at 05:11 -0500, Sam Hartman wrote: >> The best solution I have so far is to map >> KRB5KRB_AP_BAD_INTEGRITY to KRB5KRB_AP_WRONG_PRINC in >> krb5_rd_req. Greg> That's not exactly how I'd think about it; I'd say Greg> KRB5KRB_AP_BAD_INTEGRITY is a caught exception which just Greg> indicates that the loop should continue, and Greg> KRB5KRB_AP_WRONG_PRINC indicates that the loop finished Greg> without finding a match. This is roughly what I was thinking in my head. The problem though is that WRONG_PRINC today can only be caused by the principal in the ticket failing to match a principal in the keytab. If we return WRONG_PRINC as the error when we fail to find a match, then we create new conditions that cause WRONG_PRINC to be returned, namely that the ticket principal matches but the key used to encrypt the ticket is not the one in the keytab. In the trunk code a caller can distinguish these to conditions: one returns WRONG_PRINC and one returns BAD_INTEGRITY. With the proposed change a caller can no longer distinguish these conditions. Personally I think that's acceptable. >> We could actually do a bit better than that. we could see if >> the principal in the ticket happens to match any of the >> principals we've tried and return BAD_INTEGRITY in that case. >> Doing so will keep the behavior very close to what we expect >> today. However as people start using aliases on the KDC you >> will get into more and more situations where we cannot actually >> tell whether the principal is correct so we'll have to guess >> WRONG_PRINC instead of BAD_INTEGRITY. Greg> Agreed, if we accept the assumption that servers do not know Greg> how to compare client-provided principal names against Greg> keytab principals in the general case. I think this is a good assumption: we have been looking for mechanisms to reliably make this work in the case of KDC aliases for years and not come up with ideas that seem likely to be implemented in a good fraction of environments. So, I think dropping the assumption that servers can make this comparison is desirable. We might be able to handle the case insensitive and Unicode issues, but dealing with DNS and other forms of aliases will be quite challenging. From Nicolas.Williams at sun.com Wed Dec 3 12:03:31 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 3 Dec 2008 11:03:31 -0600 Subject: Behavior change of krb5_rd_req: what error to return In-Reply-To: References: Message-ID: <20081203170330.GE22970@Sun.COM> On Wed, Dec 03, 2008 at 05:11:39AM -0500, Sam Hartman wrote: > We've noticed that code in our tree depends on getting > WRONG_PRINC--for example libgssrpc uses this to loop through potential > service principals. It seems likely people outside our tree may do > this. And krb5_gss_accept_sec_context() maps that to GSS_S_NO_CRED, which might cause a caller of gss_accept_sec_context() to try a different credential. So returning WRONG_PRINC in this case could lead to unnecessary looping, but I think that's OK. > I think we may also want to update the error message to indicate > something like "Wrong principal or key in request." "Wrong principal or key in request, or no keytab entry." > We could actually do a bit better than that. we could see if the > principal in the ticket happens to match any of the principals we've > tried and return BAD_INTEGRITY in that case. Doing so will keep the > behavior very close to what we expect today. However as people start > using aliases on the KDC you will get into more and more situations > where we cannot actually tell whether the principal is correct so > we'll have to guess WRONG_PRINC instead of BAD_INTEGRITY. I suppose you could do the BAD_INTEGRITY->WRONG_PRINC mapping only if no entries matched by kvno&enctype, but that's not likely to help much either. So, yes, I think you're correct to want to map BAD_INTEGRITY to WRONG_PRINC. > I think that assuming WRONG_PRINC instead of BAD_INTEGRITY is the > correct way to go. I've run into far more situations where I ended up > presenting the wrong service ticket (DNS confusion, etc) than where > the KDC and service were out of sync about what key to use, but had > the same kvno. Well, I've run into the latter more often (think of a confused sysadmin who in a fit of frustration does a delprinc and addprinc without cleaning out the old keytab entries; kadmin makes that failure mode very likely, unfortunately). > Comments? More in a bit. Nico -- From Nicolas.Williams at sun.com Wed Dec 3 12:44:36 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 3 Dec 2008 11:44:36 -0600 Subject: Behavior change of krb5_rd_req: what error to return In-Reply-To: <20081203171243.GF22970@Sun.COM> References: <1228320992.20381.4.camel@ray> <20081203171243.GF22970@Sun.COM> Message-ID: <20081203174436.GC22105@Sun.COM> On Wed, Dec 03, 2008 at 11:12:43AM -0600, Nicolas Williams wrote: > Note that having aliases which share the same longterm key as another > principal means that an attacker can undetectably change the sname in > the unauthenticated plain-text part of the Ticket. (The sname is not > repeated inside the Ticket nor in the Authenticator.) I'm not sure that > such an attack is terribly interesting, UNLESS the service is going to > make authorization decisions according to the name by which it was > called. Oh, of course, if we're talking about case and normalization differences then never mind. Nico -- From ghudson at MIT.EDU Wed Dec 3 13:39:22 2008 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Wed, 3 Dec 2008 13:39:22 -0500 (EST) Subject: Commit notifications and diffs Message-ID: <200812031839.mB3IdMmn002006@outgoing.mit.edu> This discussion is only relevant to people who are on cvs-krb5 at mit.edu (which, despite the name, is the list where SVN commit notifications are sent). Yesterday we changed the commit handler to include Fisheye links which you can click to see colorized diffs of the changes. We also discussed sending commit diffs inline in the messages, so that it takes fewer steps to read them, so that they can be read while offline, and so that they can be easily responded to with inline comments. Is there anyone on cvs-krb5 who would object to receiving inline diffs, with the understanding that they might be large in the case of merges or big code additions and removals? If so, we can create a second list which gets diffs. But there's no need for that complexity if no one minds getting diffs. From lha at kth.se Wed Dec 3 14:31:47 2008 From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Wed, 03 Dec 2008 11:31:47 -0800 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: References: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se> Message-ID: 25 nov 2008 kl. 22:00 skrev Sam Hartman: > Love, take a look at the Projects/GSSAPI > DCE > page > . > > I believe it now includes enough of the GSS side API for comments. The gss/dce project doesn't mention that it will test explicitly. Love From metze at samba.org Wed Dec 3 14:36:06 2008 From: metze at samba.org (Stefan (metze) Metzmacher) Date: Wed, 03 Dec 2008 20:36:06 +0100 Subject: Review of AEAD Encryption API Project; concluding December 5, 2008 In-Reply-To: <4A3AAB79-43F0-4148-9B44-3C3E71B13314@padl.com> References: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se> <4A3AAB79-43F0-4148-9B44-3C3E71B13314@padl.com> Message-ID: <4936DFA6.2020109@samba.org> Luke Howard schrieb: >> Luke did this for compatibility with some work going on in the Samba >> community. >> My preference would be to do it right and make this be a type. > > Correct, I used the API proposed by Stefan (copied). Stefan, perhaps you > could explain why you made flags and type separate fields in the IOV > structure? just to make things more clear for myself. >> Love> Re DCE, How does the caller now that know that the data is >> Love> correctly padded and how do they get the padding size of >> Love> before performing any operation given a gss_ctx_id_t ? >> Luke? > > > My understanding is that DCE always pads to 16 bytes and does not > support cryptosystems that require greater padding. > > -- Luke -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081203/2496a044/signature.bin From Nicolas.Williams at sun.com Wed Dec 3 12:12:43 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 3 Dec 2008 11:12:43 -0600 Subject: Behavior change of krb5_rd_req: what error to return In-Reply-To: References: <1228320992.20381.4.camel@ray> Message-ID: <20081203171243.GF22970@Sun.COM> On Wed, Dec 03, 2008 at 11:27:39AM -0500, Sam Hartman wrote: > Greg> Agreed, if we accept the assumption that servers do not know > Greg> how to compare client-provided principal names against > Greg> keytab principals in the general case. > > I think this is a good assumption: we have been looking for mechanisms > to reliably make this work in the case of KDC aliases for years and > not come up with ideas that seem likely to be implemented in a good > fraction of environments. So, I think dropping the assumption that > servers can make this comparison is desirable. We might be able to > handle the case insensitive and Unicode issues, but dealing with DNS > and other forms of aliases will be quite challenging. If you could implement set-passwd or extend kadmin so that you could get the list of aliases from the KDC -- on the assumption that there's a finite list of aliases -- then you could have a service to keep the keytab up to date. But I gather that that's not likely to happen. Which leaves you with the heuristic that if a key works, then the given sname must be an alias of the keytab entry's sname. Note that having aliases which share the same longterm key as another principal means that an attacker can undetectably change the sname in the unauthenticated plain-text part of the Ticket. (The sname is not repeated inside the Ticket nor in the Authenticator.) I'm not sure that such an attack is terribly interesting, UNLESS the service is going to make authorization decisions according to the name by which it was called. I would prefer that the keys for aliases be different from their canonical principal names, such as by salting their "passwords." That would require keeping around the canonical principal's "password" used to derive its keys. That could be done using special keytab entries, of course, though it would mean some changes to kadmin, ktutil and klist. I'm pretty sure that Active Directory salts the entity' password to generate the keys for its servicePrincipalName aliases. I think you'll want to do the same. Nico -- From hartmans at painless-security.com Thu Dec 4 07:37:43 2008 From: hartmans at painless-security.com (Sam Hartman) Date: Thu, 04 Dec 2008 07:37:43 -0500 Subject: Behavior change of krb5_rd_req: what error to return In-Reply-To: <20081203174436.GC22105@Sun.COM> (Nicolas Williams's message of "Wed, 3 Dec 2008 11:44:36 -0600") References: <1228320992.20381.4.camel@ray> <20081203171243.GF22970@Sun.COM> <20081203174436.GC22105@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, Dec 03, 2008 at 11:12:43AM -0600, Nicolas Nicolas> Williams wrote: >> Note that having aliases which share the same longterm key as >> another principal means that an attacker can undetectably >> change the sname in the unauthenticated plain-text part of the >> Ticket. (The sname is not repeated inside the Ticket nor in >> the Authenticator.) I'm not sure that such an attack is >> terribly interesting, UNLESS the service is going to make >> authorization decisions according to the name by which it was >> called. Nicolas> Oh, of course, if we're talking about case and Nicolas> normalization differences then never mind. Well, it's bigger than that. Since the sname is not protected, having any two services that share the same long-term key means they are indistinguishable. If they are aliases, this seems entirely reasonable: it's the point of them being aliases--names for each other. It seems like a very bad idea to have two principals that share the same key and are not aliases. From jaltman at secure-endpoints.com Thu Dec 4 08:29:32 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Thu, 04 Dec 2008 08:29:32 -0500 Subject: Behavior change of krb5_rd_req: what error to return In-Reply-To: References: <1228320992.20381.4.camel@ray> <20081203171243.GF22970@Sun.COM> <20081203174436.GC22105@Sun.COM> Message-ID: <4937DB3C.5030702@secure-endpoints.com> Sam Hartman wrote: > It seems like a very bad idea to have two principals that share the same key and are not aliases. Not that there is anything that would prevent that from randomly occurring. I can just imagine the fun that someone might have trying to debug a side effect of two keys randomly being the same. 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/20081204/db3bb66b/smime.bin From john at iastate.edu Thu Dec 4 08:46:42 2008 From: john at iastate.edu (John Hascall) Date: Thu, 04 Dec 2008 07:46:42 CST Subject: Behavior change of krb5_rd_req: what error to return In-Reply-To: Your message of Thu, 04 Dec 2008 07:37:43 -0500. Message-ID: <16382.1228398402@malison.ait.iastate.edu> > It seems like a very bad idea to have two principals that > share the same key and are not aliases. This raises the question of the Birthday Paradox -- do we believe that the sizes of all key types (DES at 56 would be the smallest?) available in Kerberos are large enough that any expected installation of it would not have enough keys that two randomly generated ones are "likely" to colide? And does this also apply to user principals? Because I know darn well that many of our users choose the exact same passwords (because the no-salt keys are identical). I think we had one that was shared by something like 156 people at one point! John From hartmans at MIT.EDU Thu Dec 4 08:52:49 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 04 Dec 2008 08:52:49 -0500 Subject: Review of Kerberos AEAP API In-Reply-To: (Love =?iso-8859-1?Q?H=F6rnquist=09=C5strand's?= message of "Tue, 2 Dec 2008 09:58:28 -0800") References: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> Message-ID: >>>>> "Love" == Love H?rnquist ?strand writes: Love> 2 dec 2008 kl. 09.46 skrev Love H?rnquist ?strand: >> Hello here is my comments from the initial pass over the >> document. >> >> Limiting to only on DATA buffer is overly restrictive. >> >> On decryption, the HEADER/TRAILER data should be define to be >> read only as well as the ivec content, ie it should be possible >> to setup an recv'er ivec array and keep reusing it over and >> over again w/o re-init the data. >> >> There should be an option to have a readonly DATA buffer, but I >> can live w/o that for now. Love, Luke started out with this approach. Unfortunately, as you are probably aware, the length field in krb5_data is not size_t. He found that you always ended up having to use a temporary, and the API was not useful because you almost always were filling in a krb5_data. This is particularly problematic because it makes it easy to write code on a 32-bit system that will not work on a 64-bit system. So, the API is more useful for MIT Kerberos if the return from krb5_c_crypto_length uses the same size as the length field in krb5_data. When you add Heimdal to the mix, it gets kind of ugly. It's my understanding that Heimdal does use size_t in krb5_data. We could say that for both APIs, the length coming out of krb5_c_crypt_length will be correct size to be used in krb5_data. I think that's reasonably clean. --Sam From hartmans at MIT.EDU Thu Dec 4 09:01:00 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 04 Dec 2008 09:01:00 -0500 Subject: Review of Kerberos AEAP API In-Reply-To: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> (Love =?iso-8859-1?Q?H=F6rnquist=09=C5strand's?= message of "Tue, 2 Dec 2008 09:46:20 -0800") References: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> Message-ID: >>>>> "Love" == Love H?rnquist ?strand writes: Love> Hello here is my comments from the initial pass over the Love> document. Limiting to only on DATA buffer is overly Love> restrictive. The implementation doesn't have this restriction so I'll remove it from the API. Thanks. Love> On decryption, the HEADER/TRAILER data should be define to Love> be read only as well as the ivec content, ie it should be Love> possible to setup an recv'er ivec array and keep reusing it Love> over and over again w/o re-init the data. The implementation meets this restriction; I'm adding to the API. Note that the contents of pad buffers may be modified on decrypt: you may end up decrypting the padding. I don't think this creates a problem for your use. From hartmans at MIT.EDU Thu Dec 4 09:13:46 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 04 Dec 2008 09:13:46 -0500 Subject: Behavior change of krb5_rd_req: what error to return In-Reply-To: <16382.1228398402@malison.ait.iastate.edu> (John Hascall's message of "Thu, 04 Dec 2008 07:46:42 CST") References: <16382.1228398402@malison.ait.iastate.edu> Message-ID: >>>>> "John" == John Hascall writes: >> It seems like a very bad idea to have two principals that share >> the same key and are not aliases. John> This raises the question of the Birthday Paradox -- do we John> believe that the sizes of all key types (DES at 56 would be John> the smallest?) available in Kerberos are large enough that John> any expected installation of it would not have enough keys John> that two randomly generated ones are "likely" to colide? Yes. However the security problem is inherent and already exists independent of this proposed change. Kerbero's security depends on only the expected parties knowing the secret:-) There are a variety of somewhat different attacks one could mount if two users had the same key. For example, a user could impersonate any service including the KDC itself to another user who had the same secret key. --Sam From jaltman at secure-endpoints.com Thu Dec 4 09:20:24 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Thu, 04 Dec 2008 09:20:24 -0500 Subject: Review of Kerberos AEAP API In-Reply-To: References: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> Message-ID: <4937E728.4090804@secure-endpoints.com> Sam Hartman wrote: > Love, Luke started out with this approach. Unfortunately, as you are > probably aware, the length field in krb5_data is not size_t. He found > that you always ended up having to use a temporary, and the API was > not useful because you almost always were filling in a krb5_data. > > This is particularly problematic because it makes it easy to write > code on a 32-bit system that will not work on a 64-bit system. > > So, the API is more useful for MIT Kerberos if the return from krb5_c_crypto_length uses the same size as the length field in krb5_data. > > When you add Heimdal to the mix, it gets kind of ugly. It's my > understanding that Heimdal does use size_t in krb5_data. > > We could say that for both APIs, the length coming out of > krb5_c_crypt_length will be correct size to be used in krb5_data. > I think that's reasonably clean. > > --Sam Sam: It is indeed unfortunate that krb5_data does not use size_t and is not 64-bit ready. However, like with the 64-bit time_t vs 32-bit krb5_timestamp, at some point the MIT Kerberos API is going to have to be fixed. I believe it is appropriate to design the API for what we would want it to be when things are fixed instead of tying it to what the existing internal implementation is. Does that mean that the API will have to check for an report ETOOBIG conditions? Sure. Until the internal krb5_data structure is capable of cleanly supporting 64-bit values in mixed 64-bit/32-bit environments. (e.g., Windows) This is just my opinion. Take it with a grain of salt. 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/20081204/54097e58/smime.bin From hartmans at MIT.EDU Thu Dec 4 11:32:14 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 04 Dec 2008 11:32:14 -0500 Subject: Review of Kerberos AEAP API In-Reply-To: <4937E728.4090804@secure-endpoints.com> (Jeffrey Altman's message of "Thu, 04 Dec 2008 09:20:24 -0500") References: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> <4937E728.4090804@secure-endpoints.com> Message-ID: >>>>> "Jeffrey" == Jeffrey Altman writes: Jeffrey> Sam Hartman wrote: >> Love, Luke started out with this approach. Unfortunately, as >> you are probably aware, the length field in krb5_data is not >> size_t. He found that you always ended up having to use a >> temporary, and the API was not useful because you almost always >> were filling in a krb5_data. >> >> This is particularly problematic because it makes it easy to >> write code on a 32-bit system that will not work on a 64-bit >> system. >> >> So, the API is more useful for MIT Kerberos if the return from >> krb5_c_crypto_length uses the same size as the length field in >> krb5_data. >> >> When you add Heimdal to the mix, it gets kind of ugly. It's my >> understanding that Heimdal does use size_t in krb5_data. >> >> We could say that for both APIs, the length coming out of >> krb5_c_crypt_length will be correct size to be used in >> krb5_data. I think that's reasonably clean. >> >> --Sam Jeffrey> Sam: Jeffrey> It is indeed unfortunate that krb5_data does not use Jeffrey> size_t and is not 64-bit ready. However, like with the Jeffrey> 64-bit time_t vs 32-bit krb5_timestamp, at some point the Jeffrey> MIT Kerberos API is going to have to be fixed. I actually disagree with this. I agree that MIT Kerberos will eventually need to change its timestamp size (or stop being used). However I don't know that you'll ever need to have RFC 3961 messages longer than 2G. I understand you could do so; I just don't think it will ever become a practical problem worth fixing. I do agree that if the major version of the ABI changes, we should use size_t in krb5_data. I just don't know that it will ever be worth fixing. Jeffrey> I believe it is appropriate to design the API for what we Jeffrey> would want it to be when things are fixed instead of Jeffrey> tying it to what the existing internal implementation is. I am more interested in designing an API that is usable by its consumers than I am in one this is what we eventually want ore one that is convenient for today's implementation. To clarify, the problems Luke and I ran into were with using the API and the target being a krb5_data, not with implementing the API. The big problem is not with ETOOBIG. The big problem is that if you have a 64-bit size_t and you use krb5_data.length for the output length,then you overwrite 32 bits past the length. You won't detect it on a 32-bit platform, but it will break badly on a 64-bit platform. From Nicolas.Williams at sun.com Thu Dec 4 13:47:48 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 4 Dec 2008 12:47:48 -0600 Subject: Review of Kerberos AEAP API In-Reply-To: References: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> <4937E728.4090804@secure-endpoints.com> Message-ID: <20081204184747.GN22970@Sun.COM> On Thu, Dec 04, 2008 at 11:32:14AM -0500, Sam Hartman wrote: > The big problem is not with ETOOBIG. The big problem is that if you > have a 64-bit size_t and you use krb5_data.length for the output > length,then you overwrite 32 bits past the length. You won't detect > it on a 32-bit platform, but it will break badly on a 64-bit platform. The C compiler won't do that on simple assignments. You'd have to be using memcpy() for something like that to happen. The real problem would be length truncation, which is where EOVERFLOW comes in. Nico -- From raeburn at MIT.EDU Thu Dec 4 15:10:23 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 4 Dec 2008 15:10:23 -0500 Subject: Review of Kerberos AEAP API In-Reply-To: <20081204184747.GN22970@Sun.COM> References: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> <4937E728.4090804@secure-endpoints.com> <20081204184747.GN22970@Sun.COM> Message-ID: On Dec 4, 2008, at 13:47, Nicolas Williams wrote: > On Thu, Dec 04, 2008 at 11:32:14AM -0500, Sam Hartman wrote: >> The big problem is not with ETOOBIG. The big problem is that if you >> have a 64-bit size_t and you use krb5_data.length for the output >> length,then you overwrite 32 bits past the length. You won't detect >> it on a 32-bit platform, but it will break badly on a 64-bit >> platform. > > The C compiler won't do that on simple assignments. You'd have to be > using memcpy() for something like that to happen. Or passing the address of krb5_data.length as the place where the result should be stored, and ignoring compiler warnings (which, sadly, is pretty common, at least until we get some more cleanup done). There are some convoluted ways to force most compilers (I suspect) to error out on mismatched types, but we probably don't want to get into that. Ken From hotz at jpl.nasa.gov Thu Dec 4 16:06:09 2008 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Thu, 04 Dec 2008 13:06:09 -0800 Subject: External Detection of rcache Type Support Message-ID: <49384641.1070103@jpl.nasa.gov> The Apache mod_auth_kerb module uses krb5_rc_resolve_full() to determine if it can set "KRB5RCACHETYPE=none". The trouble is, this is an internal API, even though the environment variable itself is external. How *should* we be doing this? Is there a reasonable configure test, or a public API? -- 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 Nicolas.Williams at sun.com Thu Dec 4 16:13:08 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 4 Dec 2008 15:13:08 -0600 Subject: Review of Kerberos AEAP API In-Reply-To: References: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> <4937E728.4090804@secure-endpoints.com> <20081204184747.GN22970@Sun.COM> Message-ID: <20081204211308.GC22970@Sun.COM> On Thu, Dec 04, 2008 at 03:10:23PM -0500, Ken Raeburn wrote: > On Dec 4, 2008, at 13:47, Nicolas Williams wrote: > >On Thu, Dec 04, 2008 at 11:32:14AM -0500, Sam Hartman wrote: > >>The big problem is not with ETOOBIG. The big problem is that if you > >>have a 64-bit size_t and you use krb5_data.length for the output > >>length,then you overwrite 32 bits past the length. You won't detect > >>it on a 32-bit platform, but it will break badly on a 64-bit > >>platform. > > > >The C compiler won't do that on simple assignments. You'd have to be > >using memcpy() for something like that to happen. > > Or passing the address of krb5_data.length as the place where the > result should be stored, and ignoring compiler warnings (which, sadly, > is pretty common, at least until we get some more cleanup done). You mean that improper casts are common in MIT krb5 code or application code that uses MIT krb5? *sigh* Nico -- From hartmans at MIT.EDU Thu Dec 4 16:38:11 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 04 Dec 2008 16:38:11 -0500 Subject: Review of Kerberos AEAP API In-Reply-To: <20081204211308.GC22970@Sun.COM> (Nicolas Williams's message of "Thu, 4 Dec 2008 15:13:08 -0600") References: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> <4937E728.4090804@secure-endpoints.com> <20081204184747.GN22970@Sun.COM> <20081204211308.GC22970@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> You mean that improper casts are common in MIT krb5 code Nicolas> or application code that uses MIT krb5? *sigh* No, we mean that we believe that if this API has a size_t output parameter, people will tend to use it improperly. From raeburn at MIT.EDU Thu Dec 4 18:24:43 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 4 Dec 2008 18:24:43 -0500 Subject: Review of Kerberos AEAP API In-Reply-To: <20081204211308.GC22970@Sun.COM> References: <017A9B1C-EAD9-4AAA-B91B-520779A1D1AA@kth.se> <4937E728.4090804@secure-endpoints.com> <20081204184747.GN22970@Sun.COM> <20081204211308.GC22970@Sun.COM> Message-ID: <95E01D07-F9A9-4254-8C15-881871A7FAA1@MIT.EDU> On Dec 4, 2008, at 16:13, Nicolas Williams wrote: >> Or passing the address of krb5_data.length as the place where the >> result should be stored, and ignoring compiler warnings (which, >> sadly, >> is pretty common, at least until we get some more cleanup done). > > You mean that improper casts are common in MIT krb5 code or > application > code that uses MIT krb5? *sigh* What casts? I said *ignoring* compiler warnings, not using bogus hacks to silence them. Compiling with "gcc -Werror" would be nice someday, but it's going to take some work. Ken From hartmans at MIT.EDU Fri Dec 5 09:46:37 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 05 Dec 2008 09:46:37 -0500 Subject: Resolving API issues on the GSSAPI DCE API Message-ID: So, I think I've seen support for the following changes: * Making sign_only a type not a flag * Documenting what types the flags can be used with. My assumption is that alloc and allocated can be used with any type besides data, stream or sign_only. Do these changes plus the reordering we've already committed address the outstanding comments? From hartmans at MIT.EDU Fri Dec 5 10:45:40 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 05 Dec 2008 10:45:40 -0500 Subject: Review of http://k5wiki.kerberos.org/wiki/Projects/RFC_3244 by December 19, 2008 Message-ID: This message starts a two week review of a project to add RFC 3244 server support to MIT Kerberos The RFC 3244 project adds support for the Microsoft set password protocol server to MIT Kerberos. In addition, it adds support for both that protocol and the traditional kpasswd protocol over TCP. This protocol is added for better compatibility with Microsoft Windows. No new public APIs are exposed; MIT Kerberos already contains an API for the client side of this protocol. The only non-obvious change introduced by the implementation is kadmin/server/network.c modeled on src/kdc/network.c (current|log). The existing kadmin server does not support TCP; it needs an event loop similar to the KDC in order to support TCP. From metze at samba.org Mon Dec 8 02:19:23 2008 From: metze at samba.org (Stefan (metze) Metzmacher) Date: Mon, 08 Dec 2008 08:19:23 +0100 Subject: Resolving API issues on the GSSAPI DCE API In-Reply-To: References: Message-ID: <493CCA7B.6020604@samba.org> Sam Hartman schrieb: > > So, I think I've seen support for the following changes: > > * Making sign_only a type not a flag > * Documenting what types the flags can be used with. > > My assumption is that alloc and allocated can be used with any type > besides data, stream or sign_only. why not with data? metze -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081208/8be65d4a/signature.bin From lukeh at padl.com Mon Dec 8 04:43:54 2008 From: lukeh at padl.com (Luke Howard) Date: Mon, 8 Dec 2008 20:43:54 +1100 Subject: Resolving API issues on the GSSAPI DCE API In-Reply-To: <493CCA7B.6020604@samba.org> References: <493CCA7B.6020604@samba.org> Message-ID: <6C5C3508-4234-4C68-938D-8143D9F8CE72@padl.com> Yes, the current implementation allows it to be used with OUT DATA with IN STREAM. (If unspecified, then OUT DATA points into decrypted- in-place STREAM.) -- Luke On 08/12/2008, at 6:19 PM, Stefan (metze) Metzmacher wrote: > Sam Hartman schrieb: >> >> So, I think I've seen support for the following changes: >> >> * Making sign_only a type not a flag >> * Documenting what types the flags can be used with. >> >> My assumption is that alloc and allocated can be used with any type >> besides data, stream or sign_only. > > why not with data? > > metze > -- www.padl.com | www.fghr.net From metze at samba.org Mon Dec 8 06:57:08 2008 From: metze at samba.org (Stefan (metze) Metzmacher) Date: Mon, 08 Dec 2008 12:57:08 +0100 Subject: Resolving API issues on the GSSAPI DCE API In-Reply-To: <6C5C3508-4234-4C68-938D-8143D9F8CE72@padl.com> References: <493CCA7B.6020604@samba.org> <6C5C3508-4234-4C68-938D-8143D9F8CE72@padl.com> Message-ID: <493D0B94.9090801@samba.org> Luke Howard schrieb: > Yes, the current implementation allows it to be used with OUT DATA with > IN STREAM. (If unspecified, then OUT DATA points into decrypted-in-place > STREAM.) That's ok, but I think the caller should be able to specify the ALLOCATE flag for the DATA buffer too. metze -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081208/e231c1d3/signature.bin From hartmans at MIT.EDU Mon Dec 8 10:15:27 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 08 Dec 2008 10:15:27 -0500 Subject: Resolving API issues on the GSSAPI DCE API In-Reply-To: <6C5C3508-4234-4C68-938D-8143D9F8CE72@padl.com> (Luke Howard's message of "Mon, 8 Dec 2008 20:43:54 +1100") References: <493CCA7B.6020604@samba.org> <6C5C3508-4234-4C68-938D-8143D9F8CE72@padl.com> Message-ID: >>>>> "Luke" == Luke Howard writes: Luke> Yes, the current implementation allows it to be used with Luke> OUT DATA with IN STREAM. (If unspecified, then OUT DATA Luke> points into decrypted- in-place STREAM.) I think it makes sense in the case of stream. I don't think it makes a lot of sense in the case of data without stream. From anuraggwl at yahoo.com Mon Dec 8 07:51:44 2008 From: anuraggwl at yahoo.com (Anuraggwl) Date: Mon, 8 Dec 2008 04:51:44 -0800 (PST) Subject: Windows 2003 Service Tickets and Multiple SPN Message-ID: <20894740.post@talk.nabble.com> I am seeing some issues with Windows 2003 KDC. I create user account in windows 2003 KDC for example user = websvr. I also selet DES Encryption option in user account properties. Now i call setspn command for this user account 1) setspn -A HTTP/www.web.com websvr ( SPN1) 2) setspn -A HTTP/proxy.web.com websvr ( SPN2) I have registered two SPN with websvr account so that user can access my web application from proxy as well as direct server. Now i want to generate keytab file containing principal and their keys. ktpass - princ HTTP/www.web.com@ -out websvr.keytab -pass * -mapuser websvr -ptype KRB5_NT_PRINCIPAL -crypto DES-CBC-MD5 +dumpsalt This command export the key/principal to given file and reset the principal password in KDC. +dumpSalt option shows which salting KDC ktpass is usjng to for encryption key. It shows that servicePrincipal + realm (HTTPWWWWEBCOMis used to get encryption key. Now again i run the ktpass for second spn. ktpass - princ HTTP/proxy.web.com -in websvr.keytab -out websvr.keytab -pass * --ptype KRB5_NT_PRINCIPAL -crypto DES-CBC-MD5 +dumpsalt This time i dont call ktpass with mapuser so that i does not update user key in KDC. i am calling ktpass with in option so that it merge the keytab file with both spns. Now my client application request service token for service HTTP/proxy.web.com and KDC gives the service token encrypted using key generated by first ktpass command. On Java Server side code, if i use GSSName as HTTP/www.web.com while accepting the context then everything works fine. Please note that i have requested the ticket for "HTTP/proxy.web.com" and server code is validating user "HTTP/www.web.com" account. On Java Server side code, if i use GSSName as HTTP/proxy.web.com while accepting the context then it fails with error "Integrity Validation Failed" . Please note that i have requested the ticket for "HTTP/proxy.web.com" and server code is validating user "HTTP/proxy.web.com" account. It seems that when KDC response to TGS request, it always use the current master key ( SPN1 + password ) to encrypt the ticket. However, keytab file contains the key which is generated using ( SPN2+ password ) so because of this mismatch, ticket encrption fails. Please let me know how Windows 2003 encrypt the service ticket when there are multiple SPN's ? is there a way to generate keytab file containing single encryption key for all SPN's ? -- View this message in context: http://www.nabble.com/Windows-2003-Service-Tickets-and-Multiple-SPN-tp20894740p20894740.html Sent from the Kerberos - Dev mailing list archive at Nabble.com. From deengert at anl.gov Mon Dec 8 16:28:50 2008 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 08 Dec 2008 15:28:50 -0600 Subject: Windows 2003 Service Tickets and Multiple SPN In-Reply-To: <20894740.post@talk.nabble.com> References: <20894740.post@talk.nabble.com> Message-ID: <493D9192.5010108@anl.gov> [This is really a krberos at mit.edu question not a krbdev at mit.edu question.] Anuraggwl wrote: > I am seeing some issues with Windows 2003 KDC. > > I create user account in windows 2003 KDC for example user = websvr. I also > selet DES Encryption option in user account properties. Why not use two accounts in W2k3 websrv-www and websrv-proxy , so each principal has its own key? (Or use rc4 which does not have a salt.) But see below too on how to do it. > > Now i call setspn command for this user account > > 1) setspn -A HTTP/www.web.com websvr ( SPN1) > > 2) setspn -A HTTP/proxy.web.com websvr ( SPN2) > > I have registered two SPN with websvr account so that user can access my web > application from proxy as well as direct server. > > Now i want to generate keytab file containing principal and their keys. > > ktpass - princ HTTP/www.web.com@ -out websvr.keytab -pass * -mapuser websvr > -ptype KRB5_NT_PRINCIPAL -crypto DES-CBC-MD5 +dumpsalt > > This command export the key/principal to given file and reset the principal > password in KDC. +dumpSalt option shows which salting KDC ktpass is usjng to > for encryption key. It shows that servicePrincipal + realm (HTTPWWWWEBCOMis > used to get encryption key. > > Now again i run the ktpass for second spn. > > ktpass - princ HTTP/proxy.web.com -in websvr.keytab -out websvr.keytab -pass > * --ptype KRB5_NT_PRINCIPAL -crypto DES-CBC-MD5 +dumpsalt > > This time i dont call ktpass with mapuser so that i does not update user key > in KDC. i am calling ktpass with in option so that it merge the keytab file > with both spns. > > Now my client application request service token for service > HTTP/proxy.web.com and KDC gives the service token encrypted using key > generated by first ktpass command. > > On Java Server side code, if i use GSSName as HTTP/www.web.com while > accepting the context then everything works fine. Please note that i have > requested the ticket for "HTTP/proxy.web.com" and server code is validating > user "HTTP/www.web.com" account. > > On Java Server side code, if i use GSSName as HTTP/proxy.web.com while > accepting the context then it fails with error "Integrity Validation Failed" > . Please note that i have requested the ticket for "HTTP/proxy.web.com" and > server code is validating user "HTTP/proxy.web.com" account. > > It seems that when KDC response to TGS request, it always use the current > master key ( SPN1 + password ) to encrypt the ticket. However, keytab file > contains the key which is generated using ( SPN2+ password ) so because of > this mismatch, ticket encrption fails. > > Please let me know how Windows 2003 encrypt the service ticket when there > are multiple SPN's ? > > is there a way to generate keytab file containing single encryption key for > all SPN's ? If you must use DES, and share the account, do the ktpass for the first SPN, remembering the salt and kvno then use use the kerberos ktutil with addent -password -p (SPN2) -k (kvno) -e des-cbc-md5:v4 Then for the password enter the password concatenated with the salt that the dumpsalt would have used. This will create the second entry in the keytab, and a klist -e -k -t -K keytab should show the principals have the same key. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From howard at cohtech.com Tue Dec 9 10:04:05 2008 From: howard at cohtech.com (Howard Wilkinson) Date: Tue, 09 Dec 2008 15:04:05 +0000 Subject: Data initialization problem in krb-1.6.3 Message-ID: <493E88E5.7060001@cohtech.com> I have been chasing a problem reported by valgrind when using GSSAPI to connect to an LDAP server. I have managed to pin this down to uninitialized data inside the Kerberos code. I attach a patch which fixes this in what is probably a too conservative fashion as I have chased this through a number of different scenarios. The final fix was in the memory allocated for the k5seal.c and k5sealv3.c files. In the process I have also added memory clearing functions to other data that was not being initialized. I have also restructured the k5arcfour_init routine. Some of this was taken from the trunk head in the subversion repository, some is my removing intermediate storage items to simplify the code flow. I would like to see the intent of this patch incorporated into the main line development, I have no burning desire to have the patch as written incorporated. Regards, Howard -------------- next part -------------- A non-text attachment was scrubbed... Name: krb5-1.6.3-meminitfix.patch Type: text/x-patch Size: 6218 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081209/a4407c04/krb5-1.6.3-meminitfix.bin From hartmans at MIT.EDU Tue Dec 9 16:04:17 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 09 Dec 2008 16:04:17 -0500 Subject: GSSAPI AEAD API, rrc and memory layout Message-ID: I'm doing the code review for the GSS-API AEAD implementation. RFC 4121 has a concept called the right rotation count (RRC) that describes how much a token has been rotated in memory. The intent is to allow supporting mechanisms like Microsoft SSPI that do not support adding text at the end. RFC 4121 requires that all implementations accept any value of the RRC, including values greater than the size of the token. The AEAD API does this for stream buffer types. However if the API is passed in header, trailer and data buffers, it is very selective in what rrc values it supports. Whether this is a problem kind of boils down to what it means to use the buffer types on decrypt. Are these buffer types hint about how the data is layed out, or is it actually a requirement that the header be in the header chunk. I think that in the interest of interop and being liberal in what we receive, we probably want to accept any rrc value. However I want to bring it up here, as it seems like a lot of special-case code that will only get used when we test it and if someone else comes up with a strange implementation. Note that it is only possible to handle RRC in a well defined manner if the length of the header buffer plus length of the trailer buffer, plus length of the pad buffer is the header length plus the trailer length, plus the pad length. In other words, you can move the overhead around, possibly even having it land on data once rotated, but you need to have the right amount of overhead or something is very wrong. If we do decide to handle RRC, then presumably what we'd do is write a rotate_iov function that would produce a new gss_iov_buffer_destc * (array) and that would move things around in memory. The lengths of all the data buffers , the relative ordering of the data and sign_only buffers, and the memory locations of the data buffers will be constant. The header and trailer buffers will probably need to get reallocated and copied as their length may change. Thoughts? --Sam From ghudson at MIT.EDU Tue Dec 9 17:05:00 2008 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Tue, 9 Dec 2008 17:05:00 -0500 (EST) Subject: Review of krb4 removal project; concluding December 12, 2008 Message-ID: <200812092205.mB9M50MO011985@outgoing.mit.edu> Prior to my joining the Kerberos Consortium, a decision was made to remove krb4 support from the krb5 1.7 release. I have been tasked with implementing this change. I've done a project writeup so that some of the details can be discussed before I rev up the buzzsaw. Please review http://k5wiki.kerberos.org/wiki/Projects/Remove_krb4. I've set a three-day review timeline since it's a pretty short and simple project. From dave.smith.to at gmail.com Fri Dec 12 12:46:47 2008 From: dave.smith.to at gmail.com (Dave Smith) Date: Fri, 12 Dec 2008 12:46:47 -0500 Subject: GSSAPI across a message oriented middleware. Message-ID: <5ea453f90812120946h3365f929w828de95e6c7591b8@mail.gmail.com> I'm exploring the the possibility of using Kerberos and GSSAPI with our JMS based messaging system. Ideally, client applications would not connect directly to the kerberos server, and all protocols would be implemented through the messaging system. However, all the protocols appear connection oriented, so I'm at an impass. All client applications and services will be developed in Java. Does anyone have expreience with this type of setup. Any help would be appreciated. Thanks. DS/ From mike503 at gmail.com Fri Dec 12 23:32:07 2008 From: mike503 at gmail.com (mike) Date: Fri, 12 Dec 2008 20:32:07 -0800 Subject: Development Request: Implementing SPNEGO into nginx Message-ID: First off, I'm sorry if this is a bit off-topic for the list, but I don't really know where else to post it. The nginx portion is probably quite easy, I'm thinking understanding and implementing the SPNEGO/krb/gssapi/etc/etc. stuff will be more complex. For those who don't know, nginx is a high performance webserver - quite possibly the highest performing one on the web (depending on the featureset you're looking for) - I have been using it for a while for public websites but I would like to use it now for intranet websites as well. The company I work for uses IWA for transparent SSO and seems to deprecating NTLM for Kerberos-based SPNEGO (algorithm city) - I'd want what looks like mod_auth_kerb ported to nginx, and I'd be willing to pay (as well as possibly drum up some extra funds if needed) - I am wondering if anyone on this list would be interested or would know anyone who is interested in this? I'm thinking all of the work is pretty much done for implementing the Kerberos stuff, it just needs to be reworked to work with nginx's authentication mechanism, I'm sure you could take it's auth_basic and dump in the relevant pieces, alter any Makefiles or anything to include extra libraries and probably be done. I have a bid request up on RentACoder but I am thinking the detail scares away most of the developers on there (seems like a majority are web-based) http://www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?lngBidRequestId=1064860 I would love to have any kind of discussion on this, on or off list (whatever you feel is appropriate) - I hoped to get the attention of competent C developers with Kerberos knowledge, since the nginx piece is probably -very- easy. I don't know C, or I'd attempt it myself. Please let me know! Thanks, mike From ghudson at MIT.EDU Mon Dec 15 13:10:56 2008 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Mon, 15 Dec 2008 13:10:56 -0500 (EST) Subject: Project approved: krb4 removal Message-ID: <200812151811.mBFIAuYT010360@outgoing.mit.edu> The krb4 removal project has been approved. The project page is here: http://k5wiki.kerberos.org/wiki/Projects/Remove_krb4 I began work on this last week during the review process. Barring tricky bugs, I hope to be done by the end of this week. From metze at samba.org Mon Dec 15 14:01:19 2008 From: metze at samba.org (Stefan (metze) Metzmacher) Date: Mon, 15 Dec 2008 20:01:19 +0100 Subject: GSSAPI AEAD API, rrc and memory layout In-Reply-To: References: Message-ID: <4946A97F.3090009@samba.org> Sam Hartman schrieb: > I'm doing the code review for the GSS-API AEAD implementation. > > RFC 4121 has a concept called the right rotation count (RRC) that > describes how much a token has been rotated in memory. The intent is > to allow supporting mechanisms like Microsoft SSPI that do not support > adding text at the end. > > RFC 4121 requires that all implementations accept any value of the > RRC, including values greater than the size of the token. > > The AEAD API does this for stream buffer types. > > However if the API is passed in header, trailer and data buffers, it > is very selective in what rrc values it supports. > > Whether this is a problem kind of boils down to what it means to use > the buffer types on decrypt. Are these buffer types hint about how > the data is layed out, or is it actually a requirement that the header > be in the header chunk. > > > I think that in the interest of interop and being liberal in what we > receive, we probably want to accept any rrc value. However I want to > bring it up here, as it seems like a lot of special-case code that > will only get used when we test it and if someone else comes up with a > strange implementation. > > Note that it is only possible to handle RRC in a well defined manner > if the length of the header buffer plus length of the trailer buffer, > plus length of the pad buffer is the header length plus the trailer > length, plus the pad length. In other words, you can move the > overhead around, possibly even having it land on data once rotated, > but you need to have the right amount of overhead or something is very > wrong. > > > If we do decide to handle RRC, then presumably what we'd do is write a > rotate_iov function that would produce a new gss_iov_buffer_destc * > (array) and that would move things around in memory. The lengths of > all the data buffers , the relative ordering of the data and sign_only > buffers, and the memory locations of the data buffers will be > constant. The header and trailer buffers will probably need to get > reallocated and copied as their length may change. I think we need to able to receive any RRC and maybe use a rotate_iov function, but in the end the DATA needs to end up in the DATA_BUFFERs. metze -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081215/eb57fb51/signature.bin From hartmans at MIT.EDU Mon Dec 15 14:55:27 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 15 Dec 2008 14:55:27 -0500 Subject: GSSAPI AEAD API, rrc and memory layout In-Reply-To: <4946A97F.3090009@samba.org> (Stefan Metzmacher's message of "Mon, 15 Dec 2008 20:01:19 +0100") References: <4946A97F.3090009@samba.org> Message-ID: >>>>> "Stefan" == Stefan (metze) Metzmacher writes: Stefan> I think we need to able to receive any RRC and maybe use a Stefan> rotate_iov function, but in the end the DATA needs to end Stefan> up in the DATA_BUFFERs. I completely agree the data needs to end up in the data buffers. From hotz at jpl.nasa.gov Mon Dec 15 19:11:04 2008 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Mon, 15 Dec 2008 16:11:04 -0800 Subject: GSSAPI across a message oriented middleware. In-Reply-To: References: Message-ID: <4946F218.4020606@jpl.nasa.gov> krbdev-request at mit.edu wrote: > Date: Fri, 12 Dec 2008 12:46:47 -0500 > From: "Dave Smith" > Subject: GSSAPI across a message oriented middleware. > To: krbdev at mit.edu > Message-ID: > <5ea453f90812120946h3365f929w828de95e6c7591b8 at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I'm exploring the the possibility of using Kerberos and GSSAPI with our JMS > based messaging system. Ideally, client applications would not connect > directly to the kerberos server, and all protocols would be implemented > through the messaging system. > > However, all the protocols appear connection oriented, so I'm at an impass. > All client applications and services will be developed in Java. > > Does anyone have expreience with this type of setup. Any help would be > appreciated. Thanks. > > DS/ Standard notice: this sort of question belongs on kerberos at mit.edu, not here. This list is for issues relating to the MIT implementation of Kerberos itself. That said, I've been down this path a few years ago. The JMS standards explicitly exclude security. What that means in practice is that if you get anything at all it's custom to the specific implementation, possibly insecure, and probably torques your code into decidedly non-portable shapes. JMS was designed to be deployed on intranets behind firewalls. The prevalence of "slow consumer" performance impacts is another symptom of the design target. OTOH I see no fundamental reason why the standards should be incompatible with operating over GSSAPI connections. If you have the resources to push an update to the JMS specification please go for it. -- 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 tlyu at MIT.EDU Tue Dec 16 11:59:17 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Tue, 16 Dec 2008 11:59:17 -0500 Subject: GSS IOV flags Message-ID: Love expressed a desire to combine the flag and type fields of gss_iov_buffer_desc_struct, but said he was willing to live without it. Looking at SSPI, the flag and type fields are combined. Does this change anybody's mind in favor of Love's proposed change? If there is an existing API out there (SSPI), and we can make our implementation look more like SSPI without causing problems for us, I think we should. Does anyone believe that making this change to align more closely with SSPI will cause problems? From hartmans at MIT.EDU Tue Dec 16 14:04:47 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 16 Dec 2008 14:04:47 -0500 Subject: RRC and sign_only Message-ID: We discussed the RRC issue at today's release meeting. AT this point in time we don't think it makes sense to support arbitrary rrc in the non-stream case. We would however like you to move sign_only to being a buffer type rather than a flag. From lukeh at padl.com Tue Dec 16 19:12:44 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 17 Dec 2008 11:12:44 +1100 Subject: RRC and sign_only In-Reply-To: References: Message-ID: <49297846-DCC2-41F3-BC28-656413A9FAA8@padl.com> > We would however like you to move sign_only to being a buffer type > rather than a flag. Fixed in r21489. -- luke From lukeh at padl.com Tue Dec 16 19:12:36 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 17 Dec 2008 11:12:36 +1100 Subject: GSS IOV flags In-Reply-To: References: Message-ID: Fixed in r21489. typedef struct gss_iov_buffer_desc_struct { OM_uint32 type; gss_buffer_desc buffer; } gss_iov_buffer_desc, *gss_iov_buffer_t; #define GSS_IOV_BUFFER_TYPE_EMPTY 0 #define GSS_IOV_BUFFER_TYPE_DATA 1 /* Packet data */ #define GSS_IOV_BUFFER_TYPE_HEADER 2 /* Mechanism header */ #define GSS_IOV_BUFFER_TYPE_MECH_PARAMS 3 /* Mechanism specific parameters */ #define GSS_IOV_BUFFER_TYPE_TRAILER 7 /* Mechanism trailer */ #define GSS_IOV_BUFFER_TYPE_PADDING 9 /* Padding */ #define GSS_IOV_BUFFER_TYPE_STREAM 10 /* Complete wrap token */ #define GSS_IOV_BUFFER_TYPE_SIGN_ONLY 11 /* Sign only packet data */ #define GSS_IOV_BUFFER_FLAG_MASK 0xFFFF0000 #define GSS_IOV_BUFFER_FLAG_ALLOCATE 0x00010000 /* indicates GSS can allocate */ #define GSS_IOV_BUFFER_FLAG_ALLOCATED 0x00020000 /* indicates caller should free */ #define GSS_IOV_BUFFER_TYPE(_type) ((_type) & ~(GSS_IOV_BUFFER_FLAG_MASK)) #define GSS_IOV_BUFFER_FLAGS(_type) ((_type) & GSS_IOV_BUFFER_FLAG_MASK) -- Luke On 17/12/2008, at 3:59 AM, Tom Yu wrote: > Love expressed a desire to combine the flag and type fields of > gss_iov_buffer_desc_struct, but said he was willing to live without > it. Looking at SSPI, the flag and type fields are combined. Does > this change anybody's mind in favor of Love's proposed change? > > If there is an existing API out there (SSPI), and we can make our > implementation look more like SSPI without causing problems for us, I > think we should. Does anyone believe that making this change to align > more closely with SSPI will cause problems? > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > -- www.padl.com | www.fghr.net From metze at samba.org Wed Dec 17 02:10:09 2008 From: metze at samba.org (Stefan (metze) Metzmacher) Date: Wed, 17 Dec 2008 08:10:09 +0100 Subject: GSS IOV flags In-Reply-To: References: Message-ID: <4948A5D1.4010008@samba.org> Hi Luke, > typedef struct gss_iov_buffer_desc_struct { > OM_uint32 type; > gss_buffer_desc buffer; > } gss_iov_buffer_desc, *gss_iov_buffer_t; > > #define GSS_IOV_BUFFER_TYPE_EMPTY 0 I think we should define this one a bit more, because SSPI has this: #define SECBUFFER_EMPTY 0 // Undefined, replaced by provider see http://msdn.microsoft.com/en-us/library/aa380533(VS.85).aspx and http://technet.microsoft.com/en-us/library/bb742535.aspx I would like to have have a TYPE that's ignore by the provider completely and the caller can be sure the provider doesn't mofify it. That's why I originally used: #define GSS_IOV_BUFFER_TYPE_IGNORE 0 I'm fine with keeping GSS_IOV_BUFFER_TYPE_EMPTY but we should defin what it means. > #define GSS_IOV_BUFFER_TYPE_DATA 1 /* Packet data */ > #define GSS_IOV_BUFFER_TYPE_HEADER 2 /* Mechanism header */ > #define GSS_IOV_BUFFER_TYPE_MECH_PARAMS 3 /* Mechanism specific > parameters */ > #define GSS_IOV_BUFFER_TYPE_TRAILER 7 /* Mechanism trailer */ > #define GSS_IOV_BUFFER_TYPE_PADDING 9 /* Padding */ > #define GSS_IOV_BUFFER_TYPE_STREAM 10 /* Complete wrap token */ > #define GSS_IOV_BUFFER_TYPE_SIGN_ONLY 11 /* Sign only packet data */ any reason for not counting from 0-7? > #define GSS_IOV_BUFFER_FLAG_MASK 0xFFFF0000 > #define GSS_IOV_BUFFER_FLAG_ALLOCATE 0x00010000 /* indicates GSS > can allocate */ I think that should be 'indicates GSS should/must allocate' > #define GSS_IOV_BUFFER_FLAG_ALLOCATED 0x00020000 /* indicates > caller should free */ > > #define GSS_IOV_BUFFER_TYPE(_type) ((_type) & > ~(GSS_IOV_BUFFER_FLAG_MASK)) > #define GSS_IOV_BUFFER_FLAGS(_type) ((_type) & > GSS_IOV_BUFFER_FLAG_MASK) In general it looks good. metze > On 17/12/2008, at 3:59 AM, Tom Yu wrote: > >> Love expressed a desire to combine the flag and type fields of >> gss_iov_buffer_desc_struct, but said he was willing to live without >> it. Looking at SSPI, the flag and type fields are combined. Does >> this change anybody's mind in favor of Love's proposed change? >> >> If there is an existing API out there (SSPI), and we can make our >> implementation look more like SSPI without causing problems for us, I >> think we should. Does anyone believe that making this change to align >> more closely with SSPI will cause problems? >> _______________________________________________ >> krbdev mailing list krbdev at mit.edu >> https://mailman.mit.edu/mailman/listinfo/krbdev >> > > -- > www.padl.com | www.fghr.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081217/c10a887a/signature.bin From metze at samba.org Wed Dec 17 02:13:51 2008 From: metze at samba.org (Stefan (metze) Metzmacher) Date: Wed, 17 Dec 2008 08:13:51 +0100 Subject: RRC and sign_only In-Reply-To: References: Message-ID: <4948A6AF.1090307@samba.org> Hi Sam, > We discussed the RRC issue at today's release meeting. AT this point > in time we don't think it makes sense to support arbitrary rrc in the > non-stream case. I think it don't make sense to have different semantics depending on which api an application uses. And we should allow every per RFC valid request with any api. metze -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081217/3e200e19/signature.bin From lukeh at padl.com Wed Dec 17 06:17:06 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 17 Dec 2008 22:17:06 +1100 Subject: GSS IOV flags In-Reply-To: <4948A5D1.4010008@samba.org> References: <4948A5D1.4010008@samba.org> Message-ID: <827E8065-87CF-4A9C-9C34-8C803D882A5C@padl.com> Hi Metze, > #define SECBUFFER_EMPTY 0 // Undefined, replaced by provider > see http://msdn.microsoft.com/en-us/library/aa380533(VS.85).aspx > and http://technet.microsoft.com/en-us/library/bb742535.aspx > > I would like to have have a TYPE that's ignore by the provider > completely and the caller can be sure the provider doesn't mofify > it. That's why I originally used: > > #define GSS_IOV_BUFFER_TYPE_IGNORE 0 > > I'm fine with keeping GSS_IOV_BUFFER_TYPE_EMPTY but we should defin > what it means. Can you think of any reason where we might need something that behaves like SECBUFFER_EMPTY? >> #define GSS_IOV_BUFFER_TYPE_DATA 1 /* Packet data */ >> #define GSS_IOV_BUFFER_TYPE_HEADER 2 /* Mechanism header >> */ >> #define GSS_IOV_BUFFER_TYPE_MECH_PARAMS 3 /* Mechanism specific >> parameters */ >> #define GSS_IOV_BUFFER_TYPE_TRAILER 7 /* Mechanism >> trailer */ >> #define GSS_IOV_BUFFER_TYPE_PADDING 9 /* Padding */ >> #define GSS_IOV_BUFFER_TYPE_STREAM 10 /* Complete wrap >> token */ >> #define GSS_IOV_BUFFER_TYPE_SIGN_ONLY 11 /* Sign only packet >> data */ > > any reason for not counting from 0-7? I tried to keep the types aligned with the equivalent SSPI types, to make it easier for anyone that might want to build a shim (in either direction). >> #define GSS_IOV_BUFFER_FLAG_MASK 0xFFFF0000 >> #define GSS_IOV_BUFFER_FLAG_ALLOCATE 0x00010000 /* >> indicates GSS >> can allocate */ > > I think that should be 'indicates GSS should/must allocate' OK, will fix. -- Luke From lukeh at padl.com Wed Dec 17 06:19:54 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 17 Dec 2008 22:19:54 +1100 Subject: RRC and sign_only In-Reply-To: <4948A6AF.1090307@samba.org> References: <4948A6AF.1090307@samba.org> Message-ID: <275C9385-FFA3-42A7-901D-380B601FE891@padl.com> On 17/12/2008, at 6:13 PM, Stefan (metze) Metzmacher wrote: > Hi Sam, > >> We discussed the RRC issue at today's release meeting. AT this point >> in time we don't think it makes sense to support arbitrary rrc in the >> non-stream case. > > I think it don't make sense to have different semantics depending on > which api an application uses. And we should allow every per RFC valid > request with any api. I know where you're coming from, but I'm not convinced (and/or lazy :-)). BTW, I've tested the GSS IOV code in mskrb-integ against W2K8 with LDAP and RPC (both rc4-hmac and AES). (I tested the LDAP support by commenting out the gss_[un]wrap() implementations, which forced the mechglue to provide shims on top of gss_[un]wrap_iov(). See gssint_[un]seal_iov_shim().) -- Luke From hartmans at MIT.EDU Wed Dec 17 10:36:12 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Wed, 17 Dec 2008 10:36:12 -0500 Subject: RRC and sign_only In-Reply-To: <4948A6AF.1090307@samba.org> (Stefan Metzmacher's message of "Wed, 17 Dec 2008 08:13:51 +0100") References: <4948A6AF.1090307@samba.org> Message-ID: >>>>> "Stefan" == Stefan (metze) Metzmacher writes: Stefan> Hi Sam, >> We discussed the RRC issue at today's release meeting. AT this >> point in time we don't think it makes sense to support >> arbitrary rrc in the non-stream case. Stefan> I think it don't make sense to have different semantics Stefan> depending on which api an application uses. And we should Stefan> allow every per RFC valid request with any api. You may well be right. We'd certainly evaluate a patch in this regard. All we decided is that we thought asking Luke to focus on other things made more sense for our project now. I think there is general agreement that supporting arbitrary RRC would not be bad. From ghudson at MIT.EDU Wed Dec 17 10:47:51 2008 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 17 Dec 2008 10:47:51 -0500 Subject: RRC and sign_only In-Reply-To: <4948A6AF.1090307@samba.org> References: <4948A6AF.1090307@samba.org> Message-ID: <1229528871.12360.5.camel@ray> On Wed, 2008-12-17 at 08:13 +0100, Stefan (metze) Metzmacher wrote: > I think it don't make sense to have different semantics depending on > which api an application uses. And we should allow every per RFC valid > request with any api. If you are using the IOV API in non-stream mode, you are not really using the RFC wire format; you're using an extension. It's reasonable for this extension to have restrictions not imposed by the RFC. Put another way, it makes sense to have different semantics depending on which API an application uses *if* the different API usages are for different network protocols. From lha at kth.se Wed Dec 17 11:39:44 2008 From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Wed, 17 Dec 2008 08:39:44 -0800 Subject: RRC and sign_only In-Reply-To: <1229528871.12360.5.camel@ray> References: <4948A6AF.1090307@samba.org> <1229528871.12360.5.camel@ray> Message-ID: <410CE7E4-5FE6-48D1-A4AF-CEFE8DA4313E@kth.se> 17 dec 2008 kl. 07:47 skrev Greg Hudson: > On Wed, 2008-12-17 at 08:13 +0100, Stefan (metze) Metzmacher wrote: >> I think it don't make sense to have different semantics depending on >> which api an application uses. And we should allow every per RFC >> valid >> request with any api. > > If you are using the IOV API in non-stream mode, you are not really > using the RFC wire format; you're using an extension. It's reasonable > for this extension to have restrictions not imposed by the RFC. I beg to differ. > Put another way, it makes sense to have different semantics > depending on > which API an application uses *if* the different API usages are for > different network protocols. Only SIGN_ONLY make it non RFC. Love From hartmans at MIT.EDU Wed Dec 17 12:15:46 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Wed, 17 Dec 2008 12:15:46 -0500 Subject: RRC and sign_only In-Reply-To: <410CE7E4-5FE6-48D1-A4AF-CEFE8DA4313E@kth.se> (Love =?iso-8859-1?Q?H=F6rnquist=09=C5strand's?= message of "Wed, 17 Dec 2008 08:39:44 -0800") References: <4948A6AF.1090307@samba.org> <1229528871.12360.5.camel@ray> <410CE7E4-5FE6-48D1-A4AF-CEFE8DA4313E@kth.se> Message-ID: >>>>> "Love" == Love H?rnquist ?strand writes: Love> 17 dec 2008 kl. 07:47 skrev Greg Hudson: >> On Wed, 2008-12-17 at 08:13 +0100, Stefan (metze) Metzmacher >> wrote: >>> I think it don't make sense to have different semantics >>> depending on which api an application uses. And we should >>> allow every per RFC valid request with any api. >> If you are using the IOV API in non-stream mode, you are not >> really using the RFC wire format; you're using an extension. >> It's reasonable for this extension to have restrictions not >> imposed by the RFC. I have to agree with Greg. If you would e explain why you disagree, it would be easier to see where we're coming from. Consider for example a buffer layout with 10 bytes of data, a trailer, the header and then the remainder of data. Even without sign_only, that layout will never be produced by RFC 4121. From dalmeida at MIT.EDU Wed Dec 17 12:43:35 2008 From: dalmeida at MIT.EDU (Danilo Almeida) Date: Wed, 17 Dec 2008 09:43:35 -0800 Subject: GSS IOV flags In-Reply-To: <827E8065-87CF-4A9C-9C34-8C803D882A5C@padl.com> References: <4948A5D1.4010008@samba.org> <827E8065-87CF-4A9C-9C34-8C803D882A5C@padl.com> Message-ID: <210901c9606e$fdf8f470$f9eadd50$@edu> >> #define GSS_IOV_BUFFER_TYPE_DATA 1 /* Packet data */ >> #define GSS_IOV_BUFFER_TYPE_HEADER 2 /* Mechanism header >> */ >> #define GSS_IOV_BUFFER_TYPE_MECH_PARAMS 3 /* Mechanism specific >> parameters */ >> #define GSS_IOV_BUFFER_TYPE_TRAILER 7 /* Mechanism >> trailer */ >> #define GSS_IOV_BUFFER_TYPE_PADDING 9 /* Padding */ >> #define GSS_IOV_BUFFER_TYPE_STREAM 10 /* Complete wrap >> token */ >> #define GSS_IOV_BUFFER_TYPE_SIGN_ONLY 11 /* Sign only packet >> data */ > > any reason for not counting from 0-7? I tried to keep the types aligned with the equivalent SSPI types, to make it easier for anyone that might want to build a shim (in either direction). Plus not starting at 0 lets you use 0 as a convenient value for "uninitialized". - Danilo From hartmans at painless-security.com Wed Dec 17 15:41:05 2008 From: hartmans at painless-security.com (Sam Hartman) Date: Wed, 17 Dec 2008 15:41:05 -0500 Subject: canonicalize, as_req, pa_svr_referral, pa_server_referral Message-ID: [There are two pa types I'm going to discuss pa_svr_referral is sent in the encrypted authorization data field (you know, the one that doesn't actually exist in RFC 4120 but MS sometimes uses) while pa_server_referral is a padata specified in the referrals draft. They include roughly the same information.] This all started because I was reviewing your changes to krb5.hin and noticed adding enc_padata to the KDC reply structure. That structure is exposed in our public ABI and we try to avoid changing structures in our ABI. It might be possible to change this structure because it seems to always be allocated by libkrb5, although we'd need to check with Sun and Apple, so if we have to make that change it will complicate the merge significantly. I also wanted to do a security review of the referrals situation. As far as I can tell: * changing the sname or srealm in an as-rep without pa-svr-referral or pa-server-referral is problematic. The client has no way of knowing whether the KDC changed the sname or whether the name was changed by a man-in-the-middle along the way. You have this problem somewhat with client names, but it seems far worse with server names. * It is fine to do w2k3 style aliasing where you give the client the sname it requested even if it is an alias without any padata. * It seems fine to give the client back a TGT instead of a service name for cross-realm. So, my question is to what extent do we need to support service name aliases in the AS? If the answer is not much, let's remove that from the client and server and lose enc_padata. If the answer is that we need that, then we're going to need to do a number of things. * Actually implement support for verifying pa_svr_referral in the client. * Have the main body of the KDC generate these whenever a referral happens rather than calling into the DB backend. I don't see any reason why this is DB specific * Talk to folks about the ABI change. From jhutz at cmu.edu Wed Dec 17 19:09:08 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Wed, 17 Dec 2008 19:09:08 -0500 Subject: RRC and sign_only In-Reply-To: <200812171640.mBHGe61i023102@raisinbran.srv.cs.cmu.edu> References: <4948A6AF.1090307@samba.org> <1229528871.12360.5.camel@ray> <200812171640.mBHGe61i023102@raisinbran.srv.cs.cmu.edu> Message-ID: <97735ED62E8052FD58FF2610@minbar.fac.cs.cmu.edu> --On Wednesday, December 17, 2008 08:39:44 AM -0800 Love H?rnquist ?strand wrote: > > 17 dec 2008 kl. 07:47 skrev Greg Hudson: > >> On Wed, 2008-12-17 at 08:13 +0100, Stefan (metze) Metzmacher wrote: >>> I think it don't make sense to have different semantics depending on >>> which api an application uses. And we should allow every per RFC >>> valid >>> request with any api. >> >> If you are using the IOV API in non-stream mode, you are not really >> using the RFC wire format; you're using an extension. It's reasonable >> for this extension to have restrictions not imposed by the RFC. > > I beg to differ. >> Put another way, it makes sense to have different semantics >> depending on >> which API an application uses *if* the different API usages are for >> different network protocols. I have to agree with Love here. Essentially what you're saying is that if you use this API, it might not interoperate, because it cannot successfully decode anything that an RFC4121 implementation might send. Further, you can't predict whether it will fail without violating the abstraction and peering into the token to see what the RRC is. I suppose you could guarantee it won't break by only using the API with new applications that are specified such that only certain RRC values are permitted, but that would require that _every_ implementation of such an application use some non-standard interface to inform its GSS-API implementation of the restriction. There is no standard way to do this because the RRC is that the discretion of the sending RFC4121 implementation, not of the application, which is supposed to be using a mechanism-agnostic interface. Sam says... > Consider for example a buffer layout with 10 bytes of data, a trailer, > the header and then the remainder of data. Even without sign_only, > that layout will never be produced by RFC 4121. There is no guarantee of this. Perhaps it will never be produced by your implementation of RFC4121, or Microsoft's, but that's not the same thing. RFC4121 does not specify how a sender determines what RRC to use; it only gives some hints about a use case involving more efficient implementation of a particular use of a particular nonstandard API. And, Luke says... > BTW, I've tested the GSS IOV code in mskrb-integ against W2K8 with > LDAP and RPC (both rc4-hmac and AES). This smells of cargo-cult programming ("well, I tried foo, and it worked for me, so it must be right"), and I know you're better than that. Having a few tests work is not a substitute for correctly implementing the protocol. The interface in question is not part of the GSS-API, so failing to support arbitrary RRC values does not mean it will be noncompliant. It will probably even interoperate with the current major implementations. But it won't be guaranteed to interoperate with everything, and if/when this gets standardized, I don't expect to see a special case like "if the mechanism happens to be RFC4121, and this interface is used, then the sender MUST have used an RRC value we think is convenient". -- Jeff From lha at kth.se Wed Dec 17 19:14:09 2008 From: lha at kth.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Wed, 17 Dec 2008 16:14:09 -0800 Subject: RRC and sign_only In-Reply-To: References: <4948A6AF.1090307@samba.org> <1229528871.12360.5.camel@ray> <410CE7E4-5FE6-48D1-A4AF-CEFE8DA4313E@kth.se> Message-ID: > >>> On Wed, 2008-12-17 at 08:13 +0100, Stefan (metze) Metzmacher >>> wrote: >>>> I think it don't make sense to have different semantics >>>> depending on which api an application uses. And we should >>>> allow every per RFC valid request with any api. >>> If you are using the IOV API in non-stream mode, you are not >>> really using the RFC wire format; you're using an extension. >>> It's reasonable for this extension to have restrictions not >>> imposed by the RFC. > > I have to agree with Greg. > If you would e explain why you disagree, it would be easier to see > where we're coming from. > > Consider for example a buffer layout with 10 bytes of data, a trailer, > the header and then the remainder of data. Even without sign_only, > that layout will never be produced by RFC 4121. Greg say that the api use must be limited to STREAM use, everything else is of bounds, I don't agree with that.an Love From ghudson at MIT.EDU Wed Dec 17 19:54:21 2008 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 17 Dec 2008 19:54:21 -0500 Subject: RRC and sign_only In-Reply-To: <97735ED62E8052FD58FF2610@minbar.fac.cs.cmu.edu> References: <4948A6AF.1090307@samba.org> <1229528871.12360.5.camel@ray> <200812171640.mBHGe61i023102@raisinbran.srv.cs.cmu.edu> <97735ED62E8052FD58FF2610@minbar.fac.cs.cmu.edu> Message-ID: <1229561661.12360.23.camel@ray> On Wed, 2008-12-17 at 19:09 -0500, Jeffrey Hutzelman wrote: > I have to agree with Love here. Essentially what you're saying is that if > you use this API, it might not interoperate, because it cannot successfully > decode anything that an RFC4121 implementation might send. If you are decoding an RFC4121 message, you will use the API in stream mode (or just use the non-iov API). I'm not sure you're understanding the situation at hand here (although I believe Love is), so I'm struggling to find a good analogy. If the wire format were XML, then you might imagine an analagous API which can be used in two modes: (1) "Here is an XML document to decode into a DOM" (analagous to stream mode) (2) Here is a header tag, some body content, and a trailer tag; please construct a DOM (analagous to non-stream mode) In the first case, the API is acting as an XML decoder and should parse everything the XML standard talks about. In the second case, there is no particular reason to believe that the API is processing a well-formed XML document, and might reasonably impose additional restrictions such as "no comments alongside the header tag". I believe the analogy to Love's argument is that, even in the second case, the API might be being used to process a well-formed XML document. But I'd say that possibility is merely coincidental, and does not bind the API (in that usage mode) to honor all aspects of the standard. >From a practical perspective, as I understand the situation, honoring all rrc values has no benefit and requires using some grotty vector-rotation code which would be difficult to adequately test. So I'm inclined toward the philosophical perspective that we don't need to do it, even if the argument seems a little tortured to some. From lukeh at padl.com Thu Dec 18 02:30:13 2008 From: lukeh at padl.com (Luke Howard) Date: Thu, 18 Dec 2008 18:30:13 +1100 Subject: canonicalize, as_req, pa_svr_referral, pa_server_referral In-Reply-To: References: Message-ID: <058705FA-8D2A-4C9E-8F75-16FC7E04F0E2@padl.com> > So, my question is to what extent do we need to support service name > aliases in the AS? If the answer is not much, let's remove that from > the client and server and lose enc_padata. Windows interop does require support for realm aliases in the AS-REQ case (because Windows clients will send the NetBIOS name in an AS-REQ unless you are logging on with a UPN). enc_padata is just for TGS-REP. I'm happy to remove that code. -- Luke From lukeh at padl.com Thu Dec 18 02:42:34 2008 From: lukeh at padl.com (Luke Howard) Date: Thu, 18 Dec 2008 18:42:34 +1100 Subject: RRC and sign_only In-Reply-To: <97735ED62E8052FD58FF2610@minbar.fac.cs.cmu.edu> References: <4948A6AF.1090307@samba.org> <1229528871.12360.5.camel@ray> <200812171640.mBHGe61i023102@raisinbran.srv.cs.cmu.edu> <97735ED62E8052FD58FF2610@minbar.fac.cs.cmu.edu> Message-ID: <7080978E-599A-4CA8-8CB1-39C28890BB69@padl.com> > I have to agree with Love here. Essentially what you're saying is > that if > you use this API, it might not interoperate, because it cannot > successfully > decode anything that an RFC4121 implementation might send. Further, > you > can't predict whether it will fail without violating the abstraction > and > peering into the token to see what the RRC is. I suppose you could > guarantee it won't break by only using the API with new applications > that > are specified such that only certain RRC values are permitted, but > that > would require that _every_ implementation of such an application use > some > non-standard interface to inform its GSS-API implementation of the > restriction. There is no standard way to do this because the RRC is > that > the discretion of the sending RFC4121 implementation, not of the > application, which is supposed to be using a mechanism-agnostic > interface. I would argue if RFC4121 is the goal, one should be using STREAM or gss_unwrap(). >> BTW, I've tested the GSS IOV code in mskrb-integ against W2K8 with >> LDAP and RPC (both rc4-hmac and AES). > > This smells of cargo-cult programming ("well, I tried foo, and it > worked > for me, so it must be right"), and I know you're better than that. > Having > a few tests work is not a substitute for correctly implementing the > protocol. Heh. Well, as usual it's often quicker to fix than it is to try to win an argument :-) I agree it's always good to implement things with a view towards standardization, etc, but don't forget that the whole DCE_STYLE thing is very Windows-specific and my primary goal was interoperability with that. My reservation (apart from the usual amount of laziness) regarding supporting arbitrary RRC in the multiple buffer case is: if an application is managing explicit buffers, why would the sending GSS implementation change the meaning of the buffers by rotating contents of one into another? To me it only makes sense to use RRC to support the trailer-less buffer configuration. If one is using gss_wrap(), then yes, I agree we should accept arbitrary RRC because that's what the RFC says. -- Luke From jhutz at cmu.edu Thu Dec 18 03:19:55 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Thu, 18 Dec 2008 03:19:55 -0500 Subject: RRC and sign_only In-Reply-To: <200812180055.mBI0tRtE026762@grapenut.srv.cs.cmu.edu> References: <4948A6AF.1090307@samba.org> <1229528871.12360.5.camel@ray> <200812171640.mBHGe61i023102@raisinbran.srv.cs.cmu.edu> <97735ED62E8052FD58FF2610@minbar.fac.cs.cmu.edu> <200812180055.mBI0tRtE026762@grapenut.srv.cs.cmu.edu> Message-ID: <6ACE649532BF31405F6552A2@minbar.fac.cs.cmu.edu> --On Wednesday, December 17, 2008 07:54:21 PM -0500 Greg Hudson wrote: > On Wed, 2008-12-17 at 19:09 -0500, Jeffrey Hutzelman wrote: >> I have to agree with Love here. Essentially what you're saying is that >> if you use this API, it might not interoperate, because it cannot >> successfully decode anything that an RFC4121 implementation might send. > > If you are decoding an RFC4121 message, you will use the API in stream > mode (or just use the non-iov API). > > I'm not sure you're understanding the situation at hand here (although I > believe Love is), so I'm struggling to find a good analogy. If the wire > format were XML, then you might imagine an analagous API which can be > used in two modes: I'm afraid the analogy was not terribly useful to me; I don't know much about XML, but have a pretty good understanding of how RFC4121 works. However, I think I see where I went wrong. For some reason I thought we were talking about the GSS-API layer interface, and I'm firmly convinced that at that layer, all interfaces which accept GSS-API per-message tokens must be able to process any valid token. It's now clear to me that Sam was talking about the lower-layer crypto API, and at that layer, I agree it's entirely reasonable for some cases not to support arbitrary RRC. It's OK that some interfaces are not useful in constructing an RFC4121 implementation. -- Jeff From lukeh at padl.com Thu Dec 18 03:30:31 2008 From: lukeh at padl.com (Luke Howard) Date: Thu, 18 Dec 2008 19:30:31 +1100 Subject: RRC and sign_only In-Reply-To: <6ACE649532BF31405F6552A2@minbar.fac.cs.cmu.edu> References: <4948A6AF.1090307@samba.org> <1229528871.12360.5.camel@ray> <200812171640.mBHGe61i023102@raisinbran.srv.cs.cmu.edu> <97735ED62E8052FD58FF2610@minbar.fac.cs.cmu.edu> <200812180055.mBI0tRtE026762@grapenut.srv.cs.cmu.edu> <6ACE649532BF31405F6552A2@minbar.fac.cs.cmu.edu> Message-ID: > It's now clear to me that Sam was talking about the lower-layer > crypto API, > and at that layer, I agree it's entirely reasonable for some cases > not to > support arbitrary RRC. It's OK that some interfaces are not useful in > constructing an RFC4121 implementation. You can construct RFC4121 gss_unwrap() on top of gss_unwrap_iov(), as long as you use STREAM. Arbitrary RRC is accepted. Indeed, should a mechanism provide gss_[un]wrap_iov() but not gss_[un]wrap(), the mechglue will synthesise the latter. I used this to test RFC4121 interoperability. http://src.mit.edu/opengrok/xref/branches/mskrb-integ/src/lib/gssapi/mechglue/g_unseal.c http://src.mit.edu/opengrok/xref/branches/mskrb-integ/src/lib/gssapi/mechglue/g_seal.c -- Luke From tlyu at MIT.EDU Thu Dec 18 16:01:52 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Thu, 18 Dec 2008 16:01:52 -0500 Subject: RRC and sign_only In-Reply-To: (Love =?iso-8859-1?Q?H=F6rnquist_=C5strand's?= message of "Wed, 17 Dec 2008 16:14:09 -0800") References: <4948A6AF.1090307@samba.org> <1229528871.12360.5.camel@ray> <410CE7E4-5FE6-48D1-A4AF-CEFE8DA4313E@kth.se> Message-ID: Love H?rnquist ?strand writes: >> >>>> On Wed, 2008-12-17 at 08:13 +0100, Stefan (metze) Metzmacher >>>> wrote: >>>>> I think it don't make sense to have different semantics >>>>> depending on which api an application uses. And we should >>>>> allow every per RFC valid request with any api. >>>> If you are using the IOV API in non-stream mode, you are not >>>> really using the RFC wire format; you're using an extension. >>>> It's reasonable for this extension to have restrictions not >>>> imposed by the RFC. >> >> I have to agree with Greg. >> If you would e explain why you disagree, it would be easier to see >> where we're coming from. >> >> Consider for example a buffer layout with 10 bytes of data, a trailer, >> the header and then the remainder of data. Even without sign_only, >> that layout will never be produced by RFC 4121. > > Greg say that the api use must be limited to STREAM use, everything > else is of bounds, I don't agree with that.an Are you saying that you would like an application to be able to use gss_unwrap_iov in non-stream mode to decode messages known to originate from a RFC 4121 implementation that produces unusual RRC values, i.e. ones that do not match the submitted buffer layout? What is the use case for this? Does SSPI produce such encodings? Also, it seems to me that it is easiest to implement the "mismatched RRC" case in a less-efficient way, i.e. with additional copies that would otherwise not be needed if the RRC did match. I see several possibilities: 1. Reject RRC mismatches in non-stream mode. Make no plans to change this behavior. 2. Reject RRC mismatches in non-stream mode. Consider it a low-priority bug until a need is demonstrated. 3. Accept RRC mismatches in non-stream mode, possibly with performance penalties due to copying. Unless there are strong objections, I say that we do (2) unless Luke says that implementing (3) is fairly cheap and does not present substantial testing challenges. As gss_unwrap_iov is not (yet) standardized, we could argue that its interface requires the same buffer layout on sender and receiver when not running in stream mode. It would not necessarily accept all valid RFC 4121 encodings and is not fully compatible with RFC 4121 wrap tokens unless operating in stream mode. On the other hand, maybe there are valid use cases for a caller to want to unwrap arbitrary RFC 4121 wrap tokens using the non-stream mode of gss_unwrap_iov. Please describe such use cases if you know about them. From hartmans at painless-security.com Thu Dec 18 17:38:01 2008 From: hartmans at painless-security.com (Sam Hartman) Date: Thu, 18 Dec 2008 17:38:01 -0500 Subject: canonicalize, as_req, pa_svr_referral, pa_server_referral In-Reply-To: <058705FA-8D2A-4C9E-8F75-16FC7E04F0E2@padl.com> (Luke Howard's message of "Thu, 18 Dec 2008 18:30:13 +1100") References: <058705FA-8D2A-4C9E-8F75-16FC7E04F0E2@padl.com> Message-ID: Luke, Ken, Tom and I are discussing this on Jabber. Can you describe in more detail the netbios realm name situation? It seems like several attacks are possible and I'd like to understand why they are of no concern to windows or to what extent they exist. In the password server case, if I can change the service you are connecting to so that it is one that I have compromised, it semes I'm likely to learn your new password. What protects against this? In the TGS case--that is AS to get a TGT--it seems like I can do some damage by redirecting you to the wrong realm. If you're using pkinit, I can give you a ticket even if I don't know your password. Then I can direct you to fake servers of my choice. All I need is a KDC certificate that you are willing to trust. So, for environments like MIT, where we have realms like zone.mit.edu that are known to run at very low assurance, if clients are willing to talk to these realms at all, it seems problematic. Even without pkinit, it seems like you can run into some problems if you share a password. From lukeh at padl.com Thu Dec 18 18:00:36 2008 From: lukeh at padl.com (Luke Howard) Date: Fri, 19 Dec 2008 10:00:36 +1100 Subject: canonicalize, as_req, pa_svr_referral, pa_server_referral In-Reply-To: References: <058705FA-8D2A-4C9E-8F75-16FC7E04F0E2@padl.com> Message-ID: <65ADEB1D-1253-4581-AB0F-B9BA1E776EFF@padl.com> > Can you describe in more detail the netbios realm name situation? Assuming the NetBIOS name MSAD for the realm MS.COM. A non-UPN logon to AD will send an AS-REQ for krbtgt/MSAD@ MSAD. If the canonicalize flag is unset, the reply server will be krbtgt/MSAD at MS.COM . If the canonicalize flag is set, the reply server will be krbtgt/MS.COM at MS.COM . The client realm in the reply is also always canonicalized (something which I didn't realise until just now). -- Luke From hartmans at MIT.EDU Mon Dec 22 15:39:08 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 22 Dec 2008 15:39:08 -0500 Subject: Session key extraction Message-ID: Luke's changes introduce a mechanism independent API for extracting the session key from a context. Windows has this feature where you can get a session key from any SSPI context. According to Luke, some windows protocols such as SMB need this. I'm very uncomfortable with this concept: using a session key without knowing what kind of key it is or what structure it is seems kind of dangerous. 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.) Examples of interfaces I'd be more comfortable with: * Get the Windows session key from this context. I.E. defined only for mechanisms used on windows and defined to be the thing SSPI would give you. * Something like lucid_context that is not mechanism independent. Does this make sense to people? From ghudson at MIT.EDU Mon Dec 22 16:19:44 2008 From: ghudson at MIT.EDU (Greg Hudson) Date: Mon, 22 Dec 2008 16:19:44 -0500 Subject: Session key extraction In-Reply-To: References: Message-ID: <1229980784.12360.65.camel@ray> On Mon, 2008-12-22 at 15:39 -0500, Sam Hartman wrote: > Windows has this feature where you can get a session key from any SSPI context. According to Luke, some windows protocols such as SMB need this. I can confirm from reading SSPI docs that Windows has the feature. You get the session key as an opaque counted array of unsigned char. I could see a protocol having its own (ill-advised) constraints on how encryption or checksumming is done such that it would want to pull out the key. > I'm very uncomfortable with this concept: using a session key without > knowing what kind of key it is or what structure it is seems kind of > dangerous. I'd be interested in exploring these risks before deciding the interface is a bad idea. In another medium, Sam mentioned: 1. DES keys are not uniformly distributed. This could be addressed by removing the DES key "structure" (the parity bits) to yield a 56-bit key. Are there other conventional cryptosystems which have key structures which are not so easy to remove? 2. Using one cryptosystem's keys with another cryptosystem might create vulnerabilities. Presumably we're talking about vulnerabilities more subtle than "the application's cryptosystem is so weak that it reveals the key, compromising the mechanism's cryptosystem." Thinking about it briefly: in some cases, even using the key with the same cryptosystem, but without any associated state, could be a problem. For instance, if the cryptosystem uses the key to produce a PRNG stream which is XOR'd with the plain text, using the same key to encrypt two messages with the same stream position could reveal both plaintexts. I can also think of exotic cases where a provider might not be able to come up with a key. For instance: * A mechanism draws from a large body of previously negotiated one-time-pad data to encrypt data. (Both sides share a secret, but it's a very large secret, and it can't be used for any other purpose, so if you were to answer the application's query for session key data you would have to coordinate that with the other party--something the API doesn't really allow for.) * A mechanism uses public-key crypto operations for all messages. (Ruinously expensive today, but perhaps that won't always be true, or perhaps the mechanism is only used for small amounts of message data and the users are highly concerned with mathematical provability.) In this case the two parties may not ever negotiate a shared secret. Such exotic cases might be covered by allowing the mechanism to return a 0-byte session key. From raeburn at MIT.EDU Mon Dec 22 18:02:57 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Mon, 22 Dec 2008 18:02:57 -0500 Subject: Session key extraction In-Reply-To: References: Message-ID: <450F8F12-68B2-4351-9376-C81E55A29353@mit.edu> On Dec 22, 2008, at 15:39, Sam Hartman wrote: > Luke's changes introduce a mechanism independent API for extracting > the session key from a context. > I'm very uncomfortable with this concept: using a session key without > knowing what kind of key it is or what structure it is seems kind of > dangerous. Agreed, though I would hope it's used either as input to a hash or encryption function that wouldn't care about the structure; even if it is, though, using it for the application's own purpose and simultaneously using it within GSSAPI-type calls (including just session establishment) doesn't seem wise. And Greg's got good points about the idea possibly not even being applicable in any reasonable way to some future mechanism. > * Get the Windows session key from this context. I.E. defined only > for mechanisms used on windows > and defined to be the thing SSPI would give you. This would make the purpose clear... > * Something like lucid_context that is not mechanism independent. I assume being mechanism-dependent is the main reason the lucid context support doesn't suffice for this now? Ken From lukeh at padl.com Mon Dec 22 18:10:50 2008 From: lukeh at padl.com (Luke Howard) Date: Tue, 23 Dec 2008 10:10:50 +1100 Subject: Session key extraction In-Reply-To: References: Message-ID: <180FCEC9-F29A-4453-99F3-626C10FC64C2@padl.com> > 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. -- Luke From lukeh at padl.com Mon Dec 22 18:21:02 2008 From: lukeh at padl.com (Luke Howard) Date: Tue, 23 Dec 2008 10:21:02 +1100 Subject: Session key extraction In-Reply-To: <1229980784.12360.65.camel@ray> References: <1229980784.12360.65.camel@ray> Message-ID: <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> > I could see a protocol having its own (ill-advised) constraints on how > encryption or checksumming is done such that it would want to pull out > the key. SMB uses it for SMB signing and application-layer encryption with RC4. DRS uses it for encrypting directory attributes with RC4 (with derived keys). See [MS-DRSR] 4.1.10.5.10, [MS-KILE] 3.1.1.2 and [MS-SMB] 3.1.1.2. >> I'm very uncomfortable with this concept: using a session key without >> knowing what kind of key it is or what structure it is seems kind of >> dangerous. > > I'd be interested in exploring these risks before deciding the > interface > is a bad idea. In another medium, Sam mentioned: I agree it's a bad idea but it is a requirement for Windows interoperability. Otherwise vendors will need to fork Kerberos (as Novell has done with DSfW), build their own GSS implementation (as Samba 3 has done) or use an alternative Kerberos distribution (as Samba 4 has done). > 1. DES keys are not uniformly distributed. This could be addressed by > removing the DES key "structure" (the parity bits) to yield a 56-bit > key. Are there other conventional cryptosystems which have key > structures which are not so easy to remove? Windows from memory uses the parity bits. -- Luke From lukeh at padl.com Mon Dec 22 18:21:56 2008 From: lukeh at padl.com (Luke Howard) Date: Tue, 23 Dec 2008 10:21:56 +1100 Subject: Session key extraction In-Reply-To: <450F8F12-68B2-4351-9376-C81E55A29353@mit.edu> References: <450F8F12-68B2-4351-9376-C81E55A29353@mit.edu> Message-ID: >> * Something like lucid_context that is not mechanism independent. > > I assume being mechanism-dependent is the main reason the lucid > context support doesn't suffice for this now? That's one reason. The other reason is that lucid context deletes the context after export. -- Luke From jhutz at cmu.edu Mon Dec 22 18:33:49 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Mon, 22 Dec 2008 18:33:49 -0500 Subject: Session key extraction In-Reply-To: <200812222120.mBMLKVBh008765@raisinbran.srv.cs.cmu.edu> References: <200812222120.mBMLKVBh008765@raisinbran.srv.cs.cmu.edu> Message-ID: --On Monday, December 22, 2008 04:19:44 PM -0500 Greg Hudson wrote: > I could see a protocol having its own (ill-advised) constraints on how > encryption or checksumming is done such that it would want to pull out > the key. I can, too, and so could a number of other people. To support that, we defined an extension to GSS-API (RFC4401) to allow applications to extract psuedo-random keying material for application use. >> I'm very uncomfortable with this concept: using a session key without >> knowing what kind of key it is or what structure it is seems kind of >> dangerous. I am, too. Additionally, there is the problem that not all mechanisms necessarily have such a key, and that no mechanisms I know of (certainly, no standards-track mechanisms) specify what key should be used for such a purpose. There are some mechanisms, including Kerberos, for which it is possible to make a reasonable guess, but even for these, there may be more than one reasonable guess. For example, for RFC4121, one could imagine using the Kerberos ticket session key, whatever subkey is used to derive keys for creating GSS tokens, any of the derived keys, or some other thing such as a key derived with a different key usage. > 1. DES keys are not uniformly distributed. This could be addressed by > removing the DES key "structure" (the parity bits) to yield a 56-bit > key. Are there other conventional cryptosystems which have key > structures which are not so easy to remove? Generally, no. DES keys actually have two classes of problems here which do not generally apply to other cryptosystems. One is the introduction of bits (parity bits) which are not actually keying material but rather are intended to help verify the correctness of a DES key transported over an unreliable medium. I'm not really an expert, but I am unaware of any other cryptosystem in wide use which has this "feature". The second issue is that DES has a number of weak and semi-weak keys which are represented by otherwise valid patterns, and which anyone choosing a key, or designing an algorthim for deriving a key, must be careful to avoid. As far as I've been able to tell, more recent practice has been to design ciphers so that no such keys exist, and all possible bitstrings of the appropriate length are suitable for use as keys. However, it is best not to depend on this, and instead to avoid relying on using as a key unknown data not specifically generated for the cipher in question. > 2. Using one cryptosystem's keys with another cryptosystem might create > vulnerabilities. Presumably we're talking about vulnerabilities more > subtle than "the application's cryptosystem is so weak that it reveals > the key, compromising the mechanism's cryptosystem." Right. The obvious cases I can think of are ones where the applications cryptosystem requires some structure in the key that is not present, those where the application assumes the key is uniformly distributed when it is not (as when it is a DES key with parity bits), and cases where the application's cryptosystem requires a longer key than that used by the mechanism. > Thinking about it briefly: in some cases, even using the key with the > same cryptosystem, but without any associated state, could be a problem. > For instance, if the cryptosystem uses the key to produce a PRNG stream > which is XOR'd with the plain text, using the same key to encrypt two > messages with the same stream position could reveal both plaintexts. Correct. This is one reason why using single-session keys and key derivation is so important, particularly depending on the mode in use (the one you describe turns out to be fairly common nowadays). > I can also think of exotic cases where a provider might not be able to > come up with a key. For instance: > > * A mechanism draws from a large body of previously negotiated > one-time-pad data to encrypt data. (Both sides share a secret, but it's > a very large secret, and it can't be used for any other purpose, so if > you were to answer the application's query for session key data you > would have to coordinate that with the other party--something the API > doesn't really allow for.) > > * A mechanism uses public-key crypto operations for all messages. > (Ruinously expensive today, but perhaps that won't always be true, or > perhaps the mechanism is only used for small amounts of message data and > the users are highly concerned with mathematical provability.) In this > case the two parties may not ever negotiate a shared secret. > > Such exotic cases might be covered by allowing the mechanism to return a > 0-byte session key. You might also have a GSS-API mechanism which provides only integrity protection for per-message tokens, or even one which doesn't do GSS_wrap() at all. Such a mechanism may also have no shared key. Additionally, there is the problem that a "give me the key" operation is useful only if it produces the same result when called by both parties to the context. So, if the goal is to support implementations of application protocols that use the corresponding SSPI feature, then it is necessary to return the same key that SSPI would, or it won't work. I'd be nervous about a "Get the Windows key" feature, but it may be necessary to allow implementation of some Windows protocols. If this happens, I think it should have exactly the semantics Sam described, inclulding just failing for mechanisms not used on Windows. Applications other than existing Windows protocols should use the RFC4401 interface, which is portable to more implementations, more likely to exist in new mechanisms, and safer to use. -- Jeff From jaltman at secure-endpoints.com Mon Dec 22 19:14:19 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Mon, 22 Dec 2008 19:14:19 -0500 Subject: Session key extraction In-Reply-To: References: Message-ID: <49502D5B.4060704@secure-endpoints.com> My opinion is as follows: regardless of whether you think its a good idea or a bad idea, there are protocols that Microsoft implemented that are widely deployed and for which it is impossible to implement the security solutions that Microsoft developed as a incrementally better idea than what came previously. In order to implement this class of protocols it is necessary that the session key be exported after gss session establishment. The protocols are now publicly documented by Microsoft on their developers web site. In order for the Consortium's distribution to be used out of the box by third parties to implement these protocols they need this functionality. That isn't to say that it should not come with a note perhaps indicating that the functionality is only for Microsoft compatibility and should not be used when designing any new protocols. I do not believe that it would be wise to restrict the usage to only Microsoft implemented key types. It is impossible to say what might be implemented in the future. I believe the functionality should be provided. 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/20081222/b10e875d/smime-0001.bin From krishnag at likewisesoftware.com Mon Dec 22 19:25:43 2008 From: krishnag at likewisesoftware.com (Krishna Ganugapati) Date: Mon, 22 Dec 2008 19:25:43 -0500 Subject: Session key extraction References: <180FCEC9-F29A-4453-99F3-626C10FC64C2@padl.com> Message-ID: <23447137FA0DAA4D95EF535FF356BE460F5B82@mse3be2.mse3.exchange.ms> We totally need this in our current shipping product. We'd like to remove our extra gss_inquire_context2 and use the standard distro one. Please kindly keep this feature. ________________________________ From: Luke Howard [mailto:lukeh at padl.com] Sent: Mon 12/22/2008 3:10 PM To: Sam Hartman Cc: krbdev at mit.edu Dev List; Gerald (Jerry) Carter; Krishna Ganugapati; Rahul Srinivas; Andrew Bartlett Subject: Re: Session key extraction > 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. -- Luke From sbuckley at MIT.EDU Mon Dec 22 21:08:32 2008 From: sbuckley at MIT.EDU (Stephen C. Buckley) Date: Mon, 22 Dec 2008 21:08:32 -0500 Subject: Session key extraction In-Reply-To: <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> Message-ID: <7D6A6B89-B5D8-4F5B-B102-2C2DF67BF80F@mit.edu> So one advantage to adopting the same vices as our friends is that we can all help one another outgrow them. S Sent from my mobile device. On Dec 22, 2008, at 6:21 PM, Luke Howard wrote: >> I could see a protocol having its own (ill-advised) constraints on >> how >> encryption or checksumming is done such that it would want to pull >> out >> the key. > > SMB uses it for SMB signing and application-layer encryption with RC4. > DRS uses it for encrypting directory attributes with RC4 (with derived > keys). See [MS-DRSR] 4.1.10.5.10, [MS-KILE] 3.1.1.2 and [MS-SMB] > 3.1.1.2. > >>> I'm very uncomfortable with this concept: using a session key >>> without >>> knowing what kind of key it is or what structure it is seems kind of >>> dangerous. >> >> I'd be interested in exploring these risks before deciding the >> interface >> is a bad idea. In another medium, Sam mentioned: > > I agree it's a bad idea but it is a requirement for Windows > interoperability. Otherwise vendors will need to fork Kerberos (as > Novell has done with DSfW), build their own GSS implementation (as > Samba 3 has done) or use an alternative Kerberos distribution (as > Samba 4 has done). > >> 1. DES keys are not uniformly distributed. This could be addressed >> by >> removing the DES key "structure" (the parity bits) to yield a 56-bit >> key. Are there other conventional cryptosystems which have key >> structures which are not so easy to remove? > > Windows from memory uses the parity bits. > > -- Luke > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev From ghudson at MIT.EDU Mon Dec 22 23:04:23 2008 From: ghudson at MIT.EDU (Greg Hudson) Date: Mon, 22 Dec 2008 23:04:23 -0500 Subject: Session key extraction In-Reply-To: <49502D5B.4060704@secure-endpoints.com> References: <49502D5B.4060704@secure-endpoints.com> Message-ID: <1230005063.12360.68.camel@ray> On Mon, 2008-12-22 at 19:14 -0500, Jeffrey Altman wrote: > The protocols are now publicly documented by Microsoft on their > developers web site. In order for the Consortium's distribution to > be used out of the box by third parties to implement these protocols > they need this functionality. That isn't to say that it should not > come with a note perhaps indicating that the functionality is only > for Microsoft compatibility and should not be used when designing > any new protocols. I think that's the consensus of this discussion. (That is, provide the interface, but document it as being purely for compatibility with SSPI.) > I do not believe that it would be wise to restrict the usage to only > Microsoft implemented key types. It is impossible to say what might > be implemented in the future. If there is any ambiguity about what key to return for a given mechanism, we are much safer if we do *not* implement key export for a mechanism before Microsoft does. It's much better to be stuck in the situation of "SSPI provides X, we provide nothing" than to be stuck in the situation of "SSPI provides X, we provide Y." The former is easily fixable; the latter is much harder. From lha at kth.se Mon Dec 22 23:22:00 2008 From: lha at kth.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Tue, 23 Dec 2008 05:22:00 +0100 Subject: Session key extraction In-Reply-To: References: Message-ID: <6FD7EF54-9FDF-4AA8-9BD9-C70AFB4D00F5@kth.se> > > Luke's changes introduce a mechanism independent API for extracting > the session key from a context. There is discussion about DES in this thread, why is that an issue and why is it not disabled ? To talk to msft products you need the key extraction, why not just tag it with the keytype and let application do the wrong thing? Love From tlyu at MIT.EDU Mon Dec 22 23:40:31 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 22 Dec 2008 23:40:31 -0500 Subject: Session key extraction In-Reply-To: <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> (Luke Howard's message of "Tue, 23 Dec 2008 10:21:02 +1100") References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> Message-ID: Luke Howard writes: >>> I'm very uncomfortable with this concept: using a session key without >>> knowing what kind of key it is or what structure it is seems kind of >>> dangerous. >> >> I'd be interested in exploring these risks before deciding the >> interface >> is a bad idea. In another medium, Sam mentioned: > > I agree it's a bad idea but it is a requirement for Windows > interoperability. Otherwise vendors will need to fork Kerberos (as > Novell has done with DSfW), build their own GSS implementation (as > Samba 3 has done) or use an alternative Kerberos distribution (as > Samba 4 has done). Is this proposed API for session key extraction meant to be similar to the SSPI QueryContextAttributes function with the SECPKG_ATTR_SESSION_KEY attribute? The implementation currently committed to mskrb-integ returns a buffer with the raw bytes of the session key. This give the caller no information about the encryption algorithm, which could cause problems. Is there any plan to implement the equivalent of the SECPKG_ATTR_KEY_INFO attribute, which in SSPI provides information about the encryption algorithm associated with the context? Having this information gives callers at least a chance of using the session key with the correct encryption algorithm. From jaltman at secure-endpoints.com Mon Dec 22 23:46:36 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Mon, 22 Dec 2008 23:46:36 -0500 Subject: Session key extraction In-Reply-To: <1230005063.12360.68.camel@ray> References: <49502D5B.4060704@secure-endpoints.com> <1230005063.12360.68.camel@ray> Message-ID: <49506D2C.8030906@secure-endpoints.com> Greg Hudson wrote: > If there is any ambiguity about what key to return for a given > mechanism, we are much safer if we do *not* implement key export for a > mechanism before Microsoft does. It's much better to be stuck in the > situation of "SSPI provides X, we provide nothing" than to be stuck in > the situation of "SSPI provides X, we provide Y." The former is easily > fixable; the latter is much harder. That is a good point but it leaves developers and administrators in a very awkward position of ensuring that only MSFT implemented key types are negotiated for a context that might require a key export. A better approach if you are unsure of what to implement would be to discuss the situation with your board member and come to an agreement on what the implementation should be. Jeffrey Altman From lukeh at padl.com Mon Dec 22 23:49:20 2008 From: lukeh at padl.com (Luke Howard) Date: Tue, 23 Dec 2008 15:49:20 +1100 Subject: Session key extraction In-Reply-To: References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> Message-ID: <019F58A4-B67C-4AB7-AF39-58BBDE27557C@padl.com> > Is this proposed API for session key extraction meant to be similar to > the SSPI QueryContextAttributes function with the > SECPKG_ATTR_SESSION_KEY attribute? The implementation currently > committed to mskrb-integ returns a buffer with the raw bytes of the > session key. This give the caller no information about the encryption > algorithm, which could cause problems. Acknowledged, although note that no Microsoft protocols I am aware of (aside from the mechanisms themselves) actually care about the algorithm. > Is there any plan to implement the equivalent of the > SECPKG_ATTR_KEY_INFO attribute, which in SSPI provides information > about the encryption algorithm associated with the context? Having > this information gives callers at least a chance of using the session > key with the correct encryption algorithm. Sure, we can do this; then we need to define mechanism-agnostic algorithm types (I suppose OIDs can be used for this). -- Luke From lukeh at padl.com Mon Dec 22 23:56:10 2008 From: lukeh at padl.com (Luke Howard) Date: Tue, 23 Dec 2008 15:56:10 +1100 Subject: Session key extraction In-Reply-To: <019F58A4-B67C-4AB7-AF39-58BBDE27557C@padl.com> References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <019F58A4-B67C-4AB7-AF39-58BBDE27557C@padl.com> Message-ID: > Sure, we can do this; then we need to define mechanism-agnostic > algorithm types (I suppose OIDs can be used for this). They don't need to be mechanism-agnostic; my bad. -- Luke From lukeh at padl.com Tue Dec 23 00:24:23 2008 From: lukeh at padl.com (Luke Howard) Date: Tue, 23 Dec 2008 16:24:23 +1100 Subject: Session key extraction In-Reply-To: References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> Message-ID: > Is there any plan to implement the equivalent of the > SECPKG_ATTR_KEY_INFO attribute, which in SSPI provides information > about the encryption algorithm associated with the context? Having > this information gives callers at least a chance of using the session > key with the correct encryption algorithm. OK, now calling gss_inquire_sec_context_by_oid() with GSS_C_INQ_SESSION_KEY will return a buffer set with two members. The first is the session key; the second is an OID identifying the session key type. For the Kerberos mechanism, the OID is: 1.2.840.113554.1.2.2.4. -- Luke From Nicolas.Williams at sun.com Tue Dec 23 00:25:21 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 22 Dec 2008 23:25:21 -0600 Subject: Session key extraction In-Reply-To: References: Message-ID: <20081223052521.GA12468@Sun.COM> This is a terrible idea that cannot really be avoided now. Oh well. Put a big warning in front of this, hope there's still time to see NegoEx fixed, move on. Nico -- From Nicolas.Williams at sun.com Tue Dec 23 00:35:18 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 22 Dec 2008 23:35:18 -0600 Subject: Session key extraction In-Reply-To: <1230005063.12360.68.camel@ray> References: <49502D5B.4060704@secure-endpoints.com> <1230005063.12360.68.camel@ray> Message-ID: <20081223053518.GE12468@Sun.COM> On Mon, Dec 22, 2008 at 11:04:23PM -0500, Greg Hudson wrote: > If there is any ambiguity about what key to return for a given > mechanism, we are much safer if we do *not* implement key export for a > mechanism before Microsoft does. It's much better to be stuck in the > situation of "SSPI provides X, we provide nothing" than to be stuck in > the situation of "SSPI provides X, we provide Y." The former is easily > fixable; the latter is much harder. If libgss is a plugin framework then you'll need to hardcode in it the list of mechanisms that are allowed to export this key. Otherwise there's no way to enforce this. Count me as being in favor of enforcing whatever restrictions can reasonably be enforced. That does not include uses of the key, as I don't think it's feasible for libgss/mech_krb5 to enforce use only for Windows protocols. From Nicolas.Williams at sun.com Tue Dec 23 00:31:18 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 22 Dec 2008 23:31:18 -0600 Subject: Session key extraction In-Reply-To: References: <200812222120.mBMLKVBh008765@raisinbran.srv.cs.cmu.edu> Message-ID: <20081223053118.GD12468@Sun.COM> On Mon, Dec 22, 2008 at 06:33:49PM -0500, Jeffrey Hutzelman wrote: > I'd be nervous about a "Get the Windows key" feature, but it may be > necessary to allow implementation of some Windows protocols. If this > happens, I think it should have exactly the semantics Sam described, > inclulding just failing for mechanisms not used on Windows. Applications > other than existing Windows protocols should use the RFC4401 interface, > which is portable to more implementations, more likely to exist in new > mechanisms, and safer to use. I don't see how you can enforce what the application can do with the key short of implementing the operations that use the key in those protocols and exporting only an API for those operations. And then you'd have to worry about misuse of those. From Nicolas.Williams at sun.com Tue Dec 23 00:27:19 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 22 Dec 2008 23:27:19 -0600 Subject: Session key extraction In-Reply-To: <23447137FA0DAA4D95EF535FF356BE460F5B82@mse3be2.mse3.exchange.ms> References: <180FCEC9-F29A-4453-99F3-626C10FC64C2@padl.com> <23447137FA0DAA4D95EF535FF356BE460F5B82@mse3be2.mse3.exchange.ms> Message-ID: <20081223052719.GB12468@Sun.COM> On Mon, Dec 22, 2008 at 07:25:43PM -0500, Krishna Ganugapati wrote: > We totally need this in our current shipping product. We'd like to > remove our extra gss_inquire_context2 and use the standard distro > one. Please kindly keep this feature. If it's a for a proprietary protocol then I strongly urge you to apply some key derivation function to the session key, preferably the krb5 mechanism's GSS_Pseudo_random(). If it's for interop with Windows protocols, understood. Nico -- From Nicolas.Williams at sun.com Tue Dec 23 00:28:46 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 22 Dec 2008 23:28:46 -0600 Subject: Session key extraction In-Reply-To: <180FCEC9-F29A-4453-99F3-626C10FC64C2@padl.com> References: <180FCEC9-F29A-4453-99F3-626C10FC64C2@padl.com> Message-ID: <20081223052846.GC12468@Sun.COM> On Tue, Dec 23, 2008 at 10:10:50AM +1100, Luke Howard wrote: > Microsoft protocols that need this include SMB and DRS (replication > service). I believe Samba, Novell, and Likewise will require this. Perhaps you'll need to add NegoEx to that list. > Presently there is no explicit API for this, it is indirected through > gss_inquire_sec_context_by_oid() with GSS_C_INQ_SESSION_KEY. Yes, I like something like that. But add the word "DANGER" to the symbol name (or something scary). From lukeh at padl.com Tue Dec 23 01:06:22 2008 From: lukeh at padl.com (Luke Howard) Date: Tue, 23 Dec 2008 17:06:22 +1100 Subject: Session key extraction In-Reply-To: <20081223052719.GB12468@Sun.COM> References: <180FCEC9-F29A-4453-99F3-626C10FC64C2@padl.com> <23447137FA0DAA4D95EF535FF356BE460F5B82@mse3be2.mse3.exchange.ms> <20081223052719.GB12468@Sun.COM> Message-ID: <03674B2E-D2C4-4B9E-85CB-58DA514AD13D@padl.com> On 23/12/2008, at 4:27 PM, Nicolas Williams wrote: > On Mon, Dec 22, 2008 at 07:25:43PM -0500, Krishna Ganugapati wrote: >> We totally need this in our current shipping product. We'd like to >> remove our extra gss_inquire_context2 and use the standard distro >> one. Please kindly keep this feature. > > If it's a for a proprietary protocol then I strongly urge you to apply > some key derivation function to the session key, preferably the krb5 > mechanism's GSS_Pseudo_random(). If it's for interop with Windows > protocols, understood. It is for Windows interop. -- Luke From lukeh at padl.com Tue Dec 23 03:06:26 2008 From: lukeh at padl.com (Luke Howard) Date: Tue, 23 Dec 2008 19:06:26 +1100 Subject: Session key extraction In-Reply-To: References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> Message-ID: <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> Folks, I should add some background on the implemented mechanism and credential introspection APIs. I implemented these for Heimdal some years ago; since then, Heimdal has re-implemented them, and my original version ported to MIT (and contributed by Novell). Essentially they provide a way to inquire and set attributes on contexts and credentials, attributes being defined by OIDs. The bulk of the APIs are defined here: http://www.ogf.org/documents/GFD.24.pdf All mechanism-specific APIs in GSS-API have been re-implemented in terms of these to avoid abstraction violations. 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). Another approach would be GSS_Query_context_attr(), as defined in NegoEx. But that seems a bit SSPI-ish. -- Luke From hartmans at MIT.EDU Tue Dec 23 09:47:16 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 23 Dec 2008 09:47:16 -0500 Subject: Session key extraction In-Reply-To: <49502D5B.4060704@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 22 Dec 2008 19:14:19 -0500") References: <49502D5B.4060704@secure-endpoints.com> Message-ID: >>>>> "Jeffrey" == Jeffrey Altman writes: Jeffrey> My opinion is as follows: regardless of whether you think Jeffrey> its a good idea or a bad idea, there are protocols that Jeffrey> Microsoft implemented that are widely deployed and for Jeffrey> which it is impossible to implement the security Jeffrey> solutions that Microsoft developed as a incrementally Jeffrey> better idea than what came previously. Completely agreed. Jeffrey> In order to implement this class of protocols it is Jeffrey> necessary that the session key be exported after gss Jeffrey> session establishment. Completely agreed. Jeffrey> The protocols are now publicly documented by Microsoft on Jeffrey> their developers web site. In order for the Consortium's Jeffrey> distribution to be used out of the box by third parties Jeffrey> to implement these protocols they need this Jeffrey> functionality. That isn't to say that it should not come Jeffrey> with a note perhaps indicating that the functionality is Jeffrey> only for Microsoft compatibility and should not be used Jeffrey> when designing any new protocols. Completely agreed. Jeffrey> I do not believe that it would be wise to restrict the Jeffrey> usage to only Microsoft implemented key types. It is Jeffrey> impossible to say what might be implemented in the Jeffrey> future. I'm not sure how I feel about this. Jeffrey> I believe the functionality should be provided. I mostly agree with you here. I believe that we should work with people who have plans to implement these protocols with our code base and come up with a mutually acceptable interface. For example I prefer a Kerberos-specific interface to a GSS mechanism-independent interface. I think wemay want an interface that can be shared by an NTLM mechanism. I think that discussion is far easier if held with someone doing actual implementation than held in a vacuum beforehand. --Sam From hartmans at MIT.EDU Tue Dec 23 09:36:22 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 23 Dec 2008 09:36:22 -0500 Subject: Session key extraction In-Reply-To: <1229980784.12360.65.camel@ray> (Greg Hudson's message of "Mon, 22 Dec 2008 16:19:44 -0500") References: <1229980784.12360.65.camel@ray> Message-ID: >>>>> "Greg" == Greg Hudson writes: Greg> On Mon, 2008-12-22 at 15:39 -0500, Sam Hartman wrote: >> Windows has this feature where you can get a session key from >> any SSPI context. According to Luke, some windows protocols >> such as SMB need this. Greg> I can confirm from reading SSPI docs that Windows has the Greg> feature. You get the session key as an opaque counted array Greg> of unsigned char. Greg> I could see a protocol having its own (ill-advised) Greg> constraints on how encryption or checksumming is done such Greg> that it would want to pull out the key. >> I'm very uncomfortable with this concept: using a session key >> without knowing what kind of key it is or what structure it is >> seems kind of dangerous. Greg> I'd be interested in exploring these risks before deciding Greg> the interface is a bad idea. In another medium, Sam Greg> mentioned: My base concern is that this goes against the abstract model of GSS-API, and what is generally accepted as reasonable abstract models for key management in the security community. I can try and defend both of those, but ultimately, I will be very uncomfortable with this interface even if I cannot come up with a concrete reason why it is broken. The structural argument applies to DES and potentially to exotic crypto systems that provide provable security. It seems unlikely that we'd choose to use a block cipher that was exotic because their performance tend to be horrible and because the assumptions you need to make for AES seem acceptable to us today. However I find the structural argument interesting because GSS is a very generalized framework. However on the train yesterday, I realized that there is a significant concern in how this key will be used. The application needs to understand the authentication mechanism and understand how the session key is used by that mechanism in order to avoid breaking the security guarantees of that mechanism. As an example, if the Kerberos session key from the ticket is returned for this value, then the application needs to be very careful not to create an oracle for generating ciphertext in that key. Such an oracle could be used by an attacker to forge tickets encrypted in the key. In contrast, consider a mechanism that provided something like Kerberos's subsession key. If the application never uses the GSS context after extracting the subsession key, then the application can do whatever it wants with the subsession key because that key is only cryptographically significant in the context of a security context that will never be used. (Actually even this is not true; a sufficiently badly designed application could provide exposure of information exchanged during the authentication process to an attacker). So, applications secure under this alternate mechanism might not be secure for Kerberos. These are some of the reasons why key management protocols generally release keys only in a specific context and for a specific purpose. Take a look at RFC 4962 for the sorts of requirements that the IETF is placing on a protocol feature that hands keys over from one part of a system to another. That document is not as clear as we hoped it was at time of publication; you might not be able to get that much from it, but it is an example that my concerns are shared by others. I'd be happy with a protocol feature that released a pseudo-random bit string to an application for use in keying, guaranteeing that bit string was cryptographically independent of the security of the gss-api authentication and context. I am happy (only because it is historically necessary) with a mechanism that releases a Kerberos session key to applications that understand they are getting a Kerberos session key and presumably can be audited to make sure they use that key in a manner that will not break the security of the ticket. I'm happy with a similar facility that gives applications an NTLM key labeled as an NTLM key. I even believe we might come up with a set of security practices for a Windows SSPI session key that NTLM and Kerberos session keys both meet and release keys to applications in that context. I don't want to do that work--writing up the security practices for use of that key--in a vacuum. I'd rather be talking to consumers. In the interests of minimizing my work, I'd even rather specify a set of acceptable uses sufficient for the needs of the consumers rather than specify a set of constraints. --Sam From hartmans at MIT.EDU Tue Dec 23 09:50:17 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 23 Dec 2008 09:50:17 -0500 Subject: Session key extraction In-Reply-To: <23447137FA0DAA4D95EF535FF356BE460F5B82@mse3be2.mse3.exchange.ms> (Krishna Ganugapati's message of "Mon, 22 Dec 2008 19:25:43 -0500") References: <180FCEC9-F29A-4453-99F3-626C10FC64C2@padl.com> <23447137FA0DAA4D95EF535FF356BE460F5B82@mse3be2.mse3.exchange.ms> Message-ID: >>>>> "Krishna" == Krishna Ganugapati writes: Krishna> We totally need this in our current shipping Krishna> product. We'd like to remove our extra Krishna> gss_inquire_context2 and use the standard distro Krishna> one. Please kindly keep this feature. Krishna> ________________________________ Do you need this for mechanisms other than NTLM and Kerberos? Are you willing to use a feature that is specifically labeled as a Windows interoperability feature? --Sam Are you willing to work with us on discussions of security constraints that keys need to meet? Or alternatively on a set of protocols where the use has been reviewed and security problems have not been found? From krishnag at likewisesoftware.com Tue Dec 23 10:06:50 2008 From: krishnag at likewisesoftware.com (Krishna Ganugapati) Date: Tue, 23 Dec 2008 10:06:50 -0500 Subject: Session key extraction References: <180FCEC9-F29A-4453-99F3-626C10FC64C2@padl.com> <23447137FA0DAA4D95EF535FF356BE460F5B82@mse3be2.mse3.exchange.ms> <20081223052719.GB12468@Sun.COM> Message-ID: <23447137FA0DAA4D95EF535FF356BE460F5B86@mse3be2.mse3.exchange.ms> This is for interop with Windows protocols. ________________________________ From: Nicolas Williams [mailto:Nicolas.Williams at sun.com] Sent: Mon 12/22/2008 9:27 PM To: Krishna Ganugapati Cc: Luke Howard; Sam Hartman; krbdev at mit.edu; Rahul Srinivas Subject: Re: Session key extraction On Mon, Dec 22, 2008 at 07:25:43PM -0500, Krishna Ganugapati wrote: > We totally need this in our current shipping product. We'd like to > remove our extra gss_inquire_context2 and use the standard distro > one. Please kindly keep this feature. If it's a for a proprietary protocol then I strongly urge you to apply some key derivation function to the session key, preferably the krb5 mechanism's GSS_Pseudo_random(). If it's for interop with Windows protocols, understood. Nico -- From krishnag at likewisesoftware.com Tue Dec 23 10:10:21 2008 From: krishnag at likewisesoftware.com (Krishna Ganugapati) Date: Tue, 23 Dec 2008 10:10:21 -0500 Subject: Session key extraction References: <180FCEC9-F29A-4453-99F3-626C10FC64C2@padl.com><23447137FA0DAA4D95EF535FF356BE460F5B82@mse3be2.mse3.exchange.ms> Message-ID: <23447137FA0DAA4D95EF535FF356BE460F5B87@mse3be2.mse3.exchange.ms> We only require this for NTLM and Kerberos. I think we'd be flexible to use this as a feature labeled Windows interop. By the way, we have a full gss-ntlm provider which we'd be happy to contribute... ________________________________ From: Sam Hartman [mailto:hartmans at mit.edu] Sent: Tue 12/23/2008 6:50 AM To: Krishna Ganugapati Cc: Luke Howard; krbdev at MIT.EDU; Rahul Srinivas Subject: Re: Session key extraction >>>>> "Krishna" == Krishna Ganugapati writes: Krishna> We totally need this in our current shipping Krishna> product. We'd like to remove our extra Krishna> gss_inquire_context2 and use the standard distro Krishna> one. Please kindly keep this feature. Krishna> ________________________________ Do you need this for mechanisms other than NTLM and Kerberos? Are you willing to use a feature that is specifically labeled as a Windows interoperability feature? --Sam Are you willing to work with us on discussions of security constraints that keys need to meet? Or alternatively on a set of protocols where the use has been reviewed and security problems have not been found? From Nicolas.Williams at sun.com Tue Dec 23 12:40:37 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 23 Dec 2008 11:40:37 -0600 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: <20081223174037.GO12468@Sun.COM> On Tue, Dec 23, 2008 at 07:06:26PM +1100, Luke Howard wrote: > Essentially they provide a way to inquire and set attributes on > contexts and credentials, attributes being defined by OIDs. The bulk > of the APIs are defined here: > > http://www.ogf.org/documents/GFD.24.pdf The project proposal should be specific as to which subset of these you plan to implement. Also, there's the question of what base OIDs to use. > All mechanism-specific APIs in GSS-API have been re-implemented in > terms of these to avoid abstraction violations. I'm not sure I understand. > 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). What's the 'spi' part of these names about? > Another approach would be GSS_Query_context_attr(), as defined in > NegoEx. But that seems a bit SSPI-ish. I don't mind. Nico -- From Nicolas.Williams at sun.com Tue Dec 23 12:42:02 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 23 Dec 2008 11:42:02 -0600 Subject: Session key extraction In-Reply-To: <20081223174037.GO12468@Sun.COM> References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> <20081223174037.GO12468@Sun.COM> Message-ID: <20081223174202.GB12594@Sun.COM> On Tue, Dec 23, 2008 at 11:40:37AM -0600, Nicolas Williams wrote: > On Tue, Dec 23, 2008 at 07:06:26PM +1100, Luke Howard wrote: > > Another approach would be GSS_Query_context_attr(), as defined in > > NegoEx. But that seems a bit SSPI-ish. > > I don't mind. I spoke too soon: I prefer interfaces that use OIDs (though, of course, these should be hidden from the developer, in that symbolic names should be provided for all OIDs known to the mechglue and for all OIDs known to each mechanism). From hartmans at MIT.EDU Tue Dec 23 13:38:20 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 23 Dec 2008 13:38:20 -0500 Subject: mechglue SPI to mechanisms In-Reply-To: <20081223174202.GB12594@Sun.COM> (Nicolas Williams's message of "Tue, 23 Dec 2008 11:42:02 -0600") References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> <20081223174037.GO12468@Sun.COM> <20081223174202.GB12594@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Tue, Dec 23, 2008 at 11:40:37AM -0600, Nicolas Nicolas> Williams wrote: >> On Tue, Dec 23, 2008 at 07:06:26PM +1100, Luke Howard wrote: > >> Another approach would be GSS_Query_context_attr(), as defined >> in > NegoEx. But that seems a bit SSPI-ish. >> >> I don't mind. Nicolas> I spoke too soon: I prefer interfaces that use OIDs Nicolas> (though, of course, these should be hidden from the Nicolas> developer, in that symbolic names should be provided for Nicolas> all OIDs known to the mechglue and for all OIDs known to Nicolas> each mechanism). So, I'm not sure how extensive of a project discussion is needed here. I seem to recall a fairly extensive discussion of this issue years ago. I don't think I have a lot more time to write this up than to slap a copy of gssapi_ext.h into a project and to make sure that everything there is actually implemented. This shouldn't stopp you from raising objections, of course, just be aware that this is in many ways very much a side project along-side the real work Luke has been working on. It actually gives us a shipping mechglue layer. I think that's really neat, but it doesn't create more hours in the day for a long debate. so, let's have the objections we need to have (if any), but focus on rapid closure and on ways to meet objections that involve minimal code change where possible. I have a couple of write-ups ahead in the queue , so you may want to get a head start by looking at src/lib/gssapi/generic/gssapi_ext.h on the mskrb-integ branch. We already have the session key APIs as an open issue and we've already discussed the IOV stuff in significant detail. From hartmans at MIT.EDU Tue Dec 23 13:42:45 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 23 Dec 2008 13:42:45 -0500 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 Message-ID: I'm starting a review of the PAC and Principal APIs project, ending January 10, 2009. The PAC and principal APIs project defines some APIs that are useful in an active-directory enviroment. Contents * 1 PAC API * 2 Principal parsing and comparison * 3 User to User tickets * 4 Constants This is in some sense a catch all project for some APIs that Luke has introduced into the krb5 library. From hartmans at painless-security.com Tue Dec 23 14:01:31 2008 From: hartmans at painless-security.com (Sam Hartman) Date: Tue, 23 Dec 2008 14:01:31 -0500 Subject: kinit and enterprise names Message-ID: Luke, do we want some mechanism to request an enterprise name for kinit? From lha at kth.se Tue Dec 23 14:36:33 2008 From: lha at kth.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Tue, 23 Dec 2008 20:36:33 +0100 Subject: kinit and enterprise names In-Reply-To: References: Message-ID: <697C1621-D64B-4249-BA17-77B936D19CC1@kth.se> 23 dec 2008 kl. 20:01 skrev Sam Hartman: > Luke, do we want some mechanism to request an enterprise name for > kinit? Heimdal uses kinit --canonicalize to turn on parsing as KRB5_PRINCIPAL_PARSE_ENTERPRISE (and at the same time request client canonicalion of the KDC). Love From hartmans at painless-security.com Tue Dec 23 14:40:35 2008 From: hartmans at painless-security.com (Sam Hartman) Date: Tue, 23 Dec 2008 14:40:35 -0500 Subject: kinit and enterprise names In-Reply-To: <697C1621-D64B-4249-BA17-77B936D19CC1@kth.se> (Love =?iso-8859-1?Q?H=F6rnquist=09=C5strand's?= message of "Tue, 23 Dec 2008 20:36:33 +0100") References: <697C1621-D64B-4249-BA17-77B936D19CC1@kth.se> Message-ID: >>>>> "Love" == Love H?rnquist ?strand writes: Love> 23 dec 2008 kl. 20:01 skrev Sam Hartman: >> Luke, do we want some mechanism to request an enterprise name >> for kinit? Love> Heimdal uses kinit --canonicalize to turn on parsing as Love> KRB5_PRINCIPAL_PARSE_ENTERPRISE (and at the same time Love> request client canonicalion of the KDC). Luke added a canonicalize flag, but it does not also parse as enterprise. It seems desirable if we make --canonicalize imply enterprise to have a option that turns on canonicalize but does not imply enterprise name. From raeburn at MIT.EDU Tue Dec 23 14:58:39 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Tue, 23 Dec 2008 14:58:39 -0500 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 In-Reply-To: References: Message-ID: > krb5_error_code KRB5_CALLCONV krb5_pac_get_buffer (krb5_context > context, krb5_pac pac, krb5_ui_4 type, krb5_data *data); Does each type permit only one entry? Doc issue: Is this a copy the caller needs to free, or a reference to data in the krb5_pac object? > #define KRB5_PRINCIPAL_UNPARSE_SHORT 1 > #define KRB5_PRINCIPAL_UNPARSE_NO_REALM 2 > #define KRB5_PRINCIPAL_UNPARSE_DISPLAY 4 ... which mean what precisely? > #define KRB5_PRINCIPAL_PARSE_NO_REALM 1 Absence of realm is okay? Discard the supplied realm? > #define KRB5_PRINCIPAL_PARSE_MUST_REALM 2 "Realm" not verb. Better name? "Require"? > #define KRB5_PRINCIPAL_PARSE_ENTERPRISE 4 I assume this means "stick the entire string into the first component, and give it NT-ENTERPRISE type"? Is unquoting of \. and \@ and such done? > The following flag is defined for krb5_get_credentials: You listed two flags here... GC_USER_USER has been around for a while, so I assume GC_CANONICALIZE is the new bit. > #define KRB5_GC_USER_USER 1 /* want user-user ticket */ > #define KRB5_GC_CANONICALIZE 4 /* set canonicalize KDC option */ > The user_user flag searches the ccache for a credential encrypted in > the right TGT. I think that's been long-standing behavior, hasn't it? Or is this a change? Ken (supposedly on vacation...) From hartmans at MIT.EDU Tue Dec 23 15:05:06 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 23 Dec 2008 15:05:06 -0500 Subject: Please review Projects/Aliases Message-ID: Please take a look at http://k5wiki.kerberos.org/wiki/Projects/Aliases It's not in review yet because there are outstanding issues--in particular making sure that we have not introduced security problems not present in Windows and deciding what to do if Windows has some security issues. --Sam From hartmans at MIT.EDU Tue Dec 23 15:14:24 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 23 Dec 2008 15:14:24 -0500 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 In-Reply-To: (Ken Raeburn's message of "Tue, 23 Dec 2008 14:58:39 -0500") References: Message-ID: >>>>> "Ken" == Ken Raeburn writes: >> krb5_error_code KRB5_CALLCONV krb5_pac_get_buffer (krb5_context >> context, krb5_pac pac, krb5_ui_4 type, krb5_data *data); Ken> Does each type permit only one entry? Yes. Ken> Doc issue: Is this a copy the caller needs to free, or a Ken> reference to data in the krb5_pac object? Will address. >> #define KRB5_PRINCIPAL_UNPARSE_SHORT 1 #define >> KRB5_PRINCIPAL_UNPARSE_NO_REALM 2 #define >> KRB5_PRINCIPAL_UNPARSE_DISPLAY 4 Ken> ... which mean what precisely? Luke? >> #define KRB5_PRINCIPAL_PARSE_NO_REALM 1 Ken> Absence of realm is okay? Discard the supplied realm? Luke? >> #define KRB5_PRINCIPAL_PARSE_MUST_REALM 2 Ken> "Realm" not verb. Better name? "Require"? If this is shipping in Heimdal, I think we should keep it. Otherwise I'm happy to change. >> #define KRB5_PRINCIPAL_PARSE_ENTERPRISE 4 Ken> I assume this means "stick the entire string into the first Ken> component, and give it NT-ENTERPRISE type"? Yes. Ken> Is unquoting of Ken> \. and \@ and such done? Unsure. >> The following flag is defined for krb5_get_credentials: Ken> You listed two flags here... GC_USER_USER has been around for Ken> a while, so I assume GC_CANONICALIZE is the new bit. >> #define KRB5_GC_USER_USER 1 /* want user-user ticket */ #define >> KRB5_GC_CANONICALIZE 4 /* set canonicalize KDC option */ >> The user_user flag searches the ccache for a credential >> encrypted in the right TGT. Ken> I think that's been long-standing behavior, hasn't it? Or is Ken> this a change? I thought that was a new flag. I guess I misread the diff. From lukeh at padl.com Tue Dec 23 17:37:10 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 24 Dec 2008 09:37:10 +1100 Subject: Session key extraction In-Reply-To: <20081223174037.GO12468@Sun.COM> References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> <20081223174037.GO12468@Sun.COM> Message-ID: <82CE7D1D-0384-47FE-8A4D-7B47961AE13C@padl.com> > The project proposal should be specific as to which subset of these > you > plan to implement. OK. > Also, there's the question of what base OIDs to use. True, currently they're under the PADL arc but I will change this. >> All mechanism-specific APIs in GSS-API have been re-implemented in >> terms of these to avoid abstraction violations. > > I'm not sure I understand. The current MIT code exposes the mechglue context layout to the Kerberos mechanism. This is an abstraction violation and will not work with stacked mechanisms. Look, for example, at gss_krb5_get_tkt_flags() in krb5_gss_glue.c. >> 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). > > What's the 'spi' part of these names about? That was your suggestion :-) I believe the idea was that APIs tagged with gssspi_ were to be called by mechanisms only. -- Luke From lukeh at padl.com Tue Dec 23 17:38:52 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 24 Dec 2008 09:38:52 +1100 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 In-Reply-To: References: Message-ID: Note that API compatibility with Heimdal was a motivator here. -- Luke On 24/12/2008, at 5:42 AM, Sam Hartman wrote: > I'm starting a review of the PAC and Principal APIs project, ending > January 10, 2009. > > The PAC and principal APIs project defines some APIs that are > useful in an > active-directory enviroment. > > Contents > > * 1 PAC API > * 2 Principal parsing and comparison > * 3 User to User tickets > * 4 Constants > > > This is in some sense a catch all project for some APIs that Luke has > introduced into the krb5 library. > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > -- www.padl.com | www.fghr.net From lukeh at padl.com Tue Dec 23 17:56:41 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 24 Dec 2008 09:56:41 +1100 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 In-Reply-To: References: Message-ID: >>> #define KRB5_PRINCIPAL_UNPARSE_SHORT 1 #define >>> KRB5_PRINCIPAL_UNPARSE_NO_REALM 2 #define >>> KRB5_PRINCIPAL_UNPARSE_DISPLAY 4 > > Ken> ... which mean what precisely? > Luke? Again, these are from Heimdal. KRB5_PRINCIPAL_UNPARSE_SHORT -- omit the realm if it is the local realm. KRB5_PRINCIPAL_UNPARSE_NO_REALM -- omit the realm always. KRB5_PRINCIPAL_UNPARSE_DISPLAY -- don't escape. > >>> #define KRB5_PRINCIPAL_PARSE_NO_REALM 1 > > Ken> Absence of realm is okay? Discard the supplied realm? > Luke? KRB5_PRINCIPAL_PARSE_NO_REALM omits the realm in the parsed principal. >>> #define KRB5_PRINCIPAL_PARSE_MUST_REALM 2 > > Ken> "Realm" not verb. Better name? "Require"? > > If this is shipping in Heimdal, I think we should keep it. > Otherwise I'm happy to change. I believe it is shipping in Heimdal. KRB5_PRINCIPAL_PARSE_MUST_REALM requires that the to-be-parsed name has a realm component. --luke From lukeh at padl.com Tue Dec 23 18:16:42 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 24 Dec 2008 10:16:42 +1100 Subject: kinit and enterprise names In-Reply-To: References: Message-ID: On 24/12/2008, at 6:01 AM, Sam Hartman wrote: > > Luke, do we want some mechanism to request an enterprise name for > kinit? Sure, see r21581 (-E option). -- Luke From hartmans at MIT.EDU Tue Dec 23 19:38:33 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 23 Dec 2008 19:38:33 -0500 Subject: Session key extraction In-Reply-To: <82CE7D1D-0384-47FE-8A4D-7B47961AE13C@padl.com> (Luke Howard's message of "Wed, 24 Dec 2008 09:37:10 +1100") References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> <20081223174037.GO12468@Sun.COM> <82CE7D1D-0384-47FE-8A4D-7B47961AE13C@padl.com> Message-ID: >>>>> "Luke" == Luke Howard writes: >> The project proposal should be specific as to which subset of >> these you plan to implement. Luke> OK. >> Also, there's the question of what base OIDs to use. Luke> True, currently they're under the PADL arc but I will change Luke> this. padl arc is fine. If you use another arc make sure you get it registered or note it for me to deal with. From lukeh at padl.com Tue Dec 23 19:46:20 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 24 Dec 2008 11:46:20 +1100 Subject: Session key extraction In-Reply-To: References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> <20081223174037.GO12468@Sun.COM> <82CE7D1D-0384-47FE-8A4D-7B47961AE13C@padl.com> Message-ID: On 24/12/2008, at 11:38 AM, Sam Hartman wrote: >>>>>> "Luke" == Luke Howard writes: > >>> The project proposal should be specific as to which subset of >>> these you plan to implement. > > Luke> OK. > >>> Also, there's the question of what base OIDs to use. > > Luke> True, currently they're under the PADL arc but I will change > Luke> this. > > padl arc is fine. > If you use another arc make sure you get it registered or note it > for me to deal with. I changed it to the following: * Provisionally reserved for Kerberos session key algorithm * identifiers is: * iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) * krb5(2) krb5_enctype(4) = 1.2.840.113554.1.2.2.4 * Provisionally reserved for Kerberos mechanism-specific APIs: * iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) * krb5(2) krb5_gssapi_ext(5) = 1.2.840.113554.1.2.2.5 (Recall 1.2.840.113554.1.2.2.3 is used by Microsoft's user-to-user mechanism.) -- luke From Nicolas.Williams at sun.com Tue Dec 23 21:15:51 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 23 Dec 2008 20:15:51 -0600 Subject: Session key extraction In-Reply-To: <82CE7D1D-0384-47FE-8A4D-7B47961AE13C@padl.com> References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> <20081223174037.GO12468@Sun.COM> <82CE7D1D-0384-47FE-8A4D-7B47961AE13C@padl.com> Message-ID: <20081224021551.GS12468@Sun.COM> On Wed, Dec 24, 2008 at 09:37:10AM +1100, Luke Howard wrote: > >Also, there's the question of what base OIDs to use. > > True, currently they're under the PADL arc but I will change this. Why change it? I don't care what the prefix as is. What I care about is that the assignments be made by someone with authority to use the given prefix(es). > >>All mechanism-specific APIs in GSS-API have been re-implemented in > >>terms of these to avoid abstraction violations. > > > >I'm not sure I understand. > > The current MIT code exposes the mechglue context layout to the > Kerberos mechanism. This is an abstraction violation and will not work > with stacked mechanisms. Look, for example, at > gss_krb5_get_tkt_flags() in krb5_gss_glue.c. Any chance to fix this? Will MIT adopt Solaris' mechglue? (Solaris' needs some cleanup, but on the whole is pretty good.) > >>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). > > > >What's the 'spi' part of these names about? > > That was your suggestion :-) I believe the idea was that APIs tagged > with gssspi_ were to be called by mechanisms only. Ah, OK, thanks! From Nicolas.Williams at sun.com Tue Dec 23 21:16:28 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 23 Dec 2008 20:16:28 -0600 Subject: Session key extraction In-Reply-To: References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> <20081223174037.GO12468@Sun.COM> <82CE7D1D-0384-47FE-8A4D-7B47961AE13C@padl.com> Message-ID: <20081224021628.GT12468@Sun.COM> On Wed, Dec 24, 2008 at 11:46:20AM +1100, Luke Howard wrote: > I changed it to the following: > > * Provisionally reserved for Kerberos session key algorithm > * identifiers is: > * iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) > * krb5(2) krb5_enctype(4) = 1.2.840.113554.1.2.2.4 > * Provisionally reserved for Kerberos mechanism-specific APIs: > * iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) > * krb5(2) krb5_gssapi_ext(5) = 1.2.840.113554.1.2.2.5 > > (Recall 1.2.840.113554.1.2.2.3 is used by Microsoft's user-to-user > mechanism.) Danger... From lukeh at padl.com Tue Dec 23 22:11:10 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 24 Dec 2008 14:11:10 +1100 Subject: Session key extraction In-Reply-To: <20081224021551.GS12468@Sun.COM> References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> <20081223174037.GO12468@Sun.COM> <82CE7D1D-0384-47FE-8A4D-7B47961AE13C@padl.com> <20081224021551.GS12468@Sun.COM> Message-ID: <0FA97BA6-0530-4FE8-9B02-781571BAF387@padl.com> On 24/12/2008, at 1:15 PM, Nicolas Williams wrote: > On Wed, Dec 24, 2008 at 09:37:10AM +1100, Luke Howard wrote: >>> Also, there's the question of what base OIDs to use. >> >> True, currently they're under the PADL arc but I will change this. > > Why change it? I don't care what the prefix as is. What I care about > is that the assignments be made by someone with authority to use the > given prefix(es). Well, I have the authority for PADL. I can change it back if Sam can't arrange registration under the Kerberos arc. >>>> All mechanism-specific APIs in GSS-API have been re-implemented in >>>> terms of these to avoid abstraction violations. >>> >>> I'm not sure I understand. >> >> The current MIT code exposes the mechglue context layout to the >> Kerberos mechanism. This is an abstraction violation and will not >> work >> with stacked mechanisms. Look, for example, at >> gss_krb5_get_tkt_flags() in krb5_gss_glue.c. > > Any chance to fix this? Will MIT adopt Solaris' mechglue? (Solaris' > needs some cleanup, but on the whole is pretty good.) It's fixed now in mskrb-integ. I thought the MIT mechglue was based on Sun's? I pulled in some more changes from the original Sun drop, too (to support dynamic loading, gss_mechanism_ext, etc). Is there anything else you require? -- Luke From lukeh at padl.com Tue Dec 23 22:11:25 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 24 Dec 2008 14:11:25 +1100 Subject: Session key extraction In-Reply-To: <20081224021628.GT12468@Sun.COM> References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> <20081223174037.GO12468@Sun.COM> <82CE7D1D-0384-47FE-8A4D-7B47961AE13C@padl.com> <20081224021628.GT12468@Sun.COM> Message-ID: On 24/12/2008, at 1:16 PM, Nicolas Williams wrote: > On Wed, Dec 24, 2008 at 11:46:20AM +1100, Luke Howard wrote: >> I changed it to the following: >> >> * Provisionally reserved for Kerberos session key algorithm >> * identifiers is: >> * iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) >> * krb5(2) krb5_enctype(4) = 1.2.840.113554.1.2.2.4 >> * Provisionally reserved for Kerberos mechanism-specific APIs: >> * iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) >> * krb5(2) krb5_gssapi_ext(5) = 1.2.840.113554.1.2.2.5 >> >> (Recall 1.2.840.113554.1.2.2.3 is used by Microsoft's user-to-user >> mechanism.) > > Danger... Meaning? -- Luke From hartmans at MIT.EDU Tue Dec 23 22:25:32 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 23 Dec 2008 22:25:32 -0500 Subject: Session key extraction In-Reply-To: <20081224021551.GS12468@Sun.COM> (Nicolas Williams's message of "Tue, 23 Dec 2008 20:15:51 -0600") References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> <20081223174037.GO12468@Sun.COM> <82CE7D1D-0384-47FE-8A4D-7B47961AE13C@padl.com> <20081224021551.GS12468@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, Dec 24, 2008 at 09:37:10AM +1100, Luke Howard Nicolas> wrote: >> >Also, there's the question of what base OIDs to use. >> >> True, currently they're under the PADL arc but I will change >> this. Nicolas> Why change it? I don't care what the prefix as is. What Nicolas> I care about is that the assignments be made by someone Nicolas> with authority to use the given prefix(es). Tom is the registrar for that arc; I've asked him to evaluate the assignments. From Nicolas.Williams at sun.com Tue Dec 23 22:37:09 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 23 Dec 2008 21:37:09 -0600 Subject: Session key extraction In-Reply-To: References: <1229980784.12360.65.camel@ray> <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> <20081223174037.GO12468@Sun.COM> <82CE7D1D-0384-47FE-8A4D-7B47961AE13C@padl.com> <20081224021551.GS12468@Sun.COM> Message-ID: <20081224033709.GA12468@Sun.COM> On Tue, Dec 23, 2008 at 10:25:32PM -0500, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Wed, Dec 24, 2008 at 09:37:10AM +1100, Luke Howard > Nicolas> wrote: > >> >Also, there's the question of what base OIDs to use. > >> > >> True, currently they're under the PADL arc but I will change > >> this. > > Nicolas> Why change it? I don't care what the prefix as is. What > Nicolas> I care about is that the assignments be made by someone > Nicolas> with authority to use the given prefix(es). > > Tom is the registrar for that arc; I've asked him to evaluate the > assignments. Oh, I didn't know that. Could you please establish a pattern like: - 1.2.840.113554.1.2.2.3. - 1.2.840.113554.1.2.2.4. - I.e., 1.2.840.113554.1.2.2.. ? From Nicolas.Williams at sun.com Tue Dec 23 22:37:41 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 23 Dec 2008 21:37:41 -0600 Subject: Session key extraction In-Reply-To: References: <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> <20081223174037.GO12468@Sun.COM> <82CE7D1D-0384-47FE-8A4D-7B47961AE13C@padl.com> <20081224021628.GT12468@Sun.COM> Message-ID: <20081224033741.GB12468@Sun.COM> On Wed, Dec 24, 2008 at 02:11:25PM +1100, Luke Howard wrote: > On 24/12/2008, at 1:16 PM, Nicolas Williams wrote: > >On Wed, Dec 24, 2008 at 11:46:20AM +1100, Luke Howard wrote: > >>I changed it to the following: > > > >Danger... > > Meaning? Sorry, I didn't know that Tom was the registrar for 1.2.840.113554.1.2.2. From tlyu at MIT.EDU Tue Dec 23 23:45:12 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Tue, 23 Dec 2008 23:45:12 -0500 Subject: Session key extraction In-Reply-To: <20081224033741.GB12468@Sun.COM> (Nicolas Williams's message of "Tue, 23 Dec 2008 21:37:41 -0600") References: <90D86A17-264A-484D-A4B9-39B9E3748FEF@padl.com> <93C1BC0C-D435-418E-85C8-052A08CC2CDB@padl.com> <20081223174037.GO12468@Sun.COM> <82CE7D1D-0384-47FE-8A4D-7B47961AE13C@padl.com> <20081224021628.GT12468@Sun.COM> <20081224033741.GB12468@Sun.COM> Message-ID: Nicolas Williams writes: > On Wed, Dec 24, 2008 at 02:11:25PM +1100, Luke Howard wrote: >> On 24/12/2008, at 1:16 PM, Nicolas Williams wrote: >> >On Wed, Dec 24, 2008 at 11:46:20AM +1100, Luke Howard wrote: >> >>I changed it to the following: >> > >> >Danger... >> >> Meaning? > > Sorry, I didn't know that Tom was the registrar for > 1.2.840.113554.1.2.2. I'm not. And Microsoft's use of 1.2.840.113554.1.2.2.3 is not recorded in the registry for the MIT-infosys arc. From lha at kth.se Wed Dec 24 00:32:43 2008 From: lha at kth.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Wed, 24 Dec 2008 06:32:43 +0100 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 In-Reply-To: References: Message-ID: 23 dec 2008 kl. 23:56 skrev Luke Howard: >>>> #define KRB5_PRINCIPAL_UNPARSE_SHORT 1 #define >>>> KRB5_PRINCIPAL_UNPARSE_NO_REALM 2 #define >>>> KRB5_PRINCIPAL_UNPARSE_DISPLAY 4 >> >> Ken> ... which mean what precisely? >> Luke? > > Again, these are from Heimdal. > > KRB5_PRINCIPAL_UNPARSE_SHORT -- omit the realm if it is the local > realm. > KRB5_PRINCIPAL_UNPARSE_NO_REALM -- omit the realm always. > KRB5_PRINCIPAL_UNPARSE_DISPLAY -- don't escape. > >> >>>> #define KRB5_PRINCIPAL_PARSE_NO_REALM 1 >> >> Ken> Absence of realm is okay? Discard the supplied realm? >> Luke? > > KRB5_PRINCIPAL_PARSE_NO_REALM omits the realm in the parsed principal. > >>>> #define KRB5_PRINCIPAL_PARSE_MUST_REALM 2 >> >> Ken> "Realm" not verb. Better name? "Require"? >> >> If this is shipping in Heimdal, I think we should keep it. >> Otherwise I'm happy to change. > > I believe it is shipping in Heimdal. KRB5_PRINCIPAL_PARSE_MUST_REALM > requires that the to-be-parsed name has a realm component. Yes, KRB5_PRINCIPAL_PARSE_NO_REALM and KRB5_PRINCIPAL_PARSE_MUST_REALM are each other opposite. I like the suggestion to rename KRB5_PRINCIPAL_PARSE_MUST_REALM to KRB5_PRINCIPAL_PARSE_REQUIRE_REALM, lets do that. Love From lukeh at padl.com Wed Dec 24 00:58:07 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 24 Dec 2008 16:58:07 +1100 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 In-Reply-To: References: Message-ID: <2AE1F363-F259-4E0B-8985-FAE86E218DBE@padl.com> >> > Yes, KRB5_PRINCIPAL_PARSE_NO_REALM and > KRB5_PRINCIPAL_PARSE_MUST_REALM are each other opposite. > > I like the suggestion to rename KRB5_PRINCIPAL_PARSE_MUST_REALM to > KRB5_PRINCIPAL_PARSE_REQUIRE_REALM, lets do that. OK, committed in r21586. -- Luke From punadikar.sachin at gmail.com Wed Dec 24 00:49:01 2008 From: punadikar.sachin at gmail.com (Sachin Punadikar) Date: Wed, 24 Dec 2008 11:19:01 +0530 Subject: Possible bug in "kg_ctx_internalize()" function in MIT 1.6.3 Message-ID: <9549b1d80812232149k375130cic12bed9585025add@mail.gmail.com> Hi, I think, people from krbdev mailing list might have answer to below Awaiting clarification. Thanks. - Sachin ---------- Forwarded message ---------- From: Sachin Punadikar Date: Mon, Dec 1, 2008 at 3:33 PM Subject: kg_ctx_internalize() function in MIT 1.6.3 To: kerberos at mit.edu Hello, I was going through the gssapi MIT krb1.6.3 code and I feel there is a possible bug in kg_ctx_internalize() function defined in src/lib/gssapi/krb5/ser_sctx.c file. As I understand the function should unpack entities in the same order in which they were packed by kg_ctx_externalize() function. But it misses the order while unpacking the last two structure variables as shown below. Since acceptor_subkey_cksumtype was packed before cred_rcache and also occurs before in the _krb5_gss_cred_id_rec structure definition, acceptor_subkey_cksumtype should be unpacked BEFORE cred_rcache, else the values will get swapped. Current Code in kg_ctx_internalize() function: if (!kret) kret = krb5_ser_unpack_int32(&ibuf, &bp, &remain); ctx->cred_rcache = ibuf; if (!kret) kret = krb5_ser_unpack_int32(&ibuf, &bp, &remain); ctx->acceptor_subkey_cksumtype = ibuf; Proposed Code in kg_ctx_internalize() function with change in sequence while unpacking: if (!kret) kret = krb5_ser_unpack_int32(&ibuf, &bp, &remain); ctx->acceptor_subkey_cksumtype = ibuf; if (!kret) kret = krb5_ser_unpack_int32(&ibuf, &bp, &remain); ctx->cred_rcache = ibuf; Kindly let me know if this is valid. - Sachin From lukeh at padl.com Wed Dec 24 01:19:13 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 24 Dec 2008 17:19:13 +1100 Subject: Possible bug in "kg_ctx_internalize()" function in MIT 1.6.3 In-Reply-To: <9549b1d80812232149k375130cic12bed9585025add@mail.gmail.com> References: <9549b1d80812232149k375130cic12bed9585025add@mail.gmail.com> Message-ID: Sachin, I noticed this too whilst adding support for authorization data serialization, and fixed it in r21558 (mskrb-integ branch). http://src.mit.edu/fisheye/changelog/krb5/branches/mskrb-integ?cs=21558 regards, -- Luke On 24/12/2008, at 4:49 PM, Sachin Punadikar wrote: > Hi, > I think, people from krbdev mailing list might have answer to below > Awaiting clarification. > Thanks. > - Sachin > > ---------- Forwarded message ---------- > From: Sachin Punadikar > Date: Mon, Dec 1, 2008 at 3:33 PM > Subject: kg_ctx_internalize() function in MIT 1.6.3 > To: kerberos at mit.edu > > > Hello, > > I was going through the gssapi MIT krb1.6.3 code and I feel there > is a > possible bug in kg_ctx_internalize() function defined in > src/lib/gssapi/krb5/ser_sctx.c file. > > As I understand the function should unpack entities in the same > order in > which they were packed by kg_ctx_externalize() function. But it > misses the > order while unpacking the last two structure variables as shown > below. Since > acceptor_subkey_cksumtype was packed before cred_rcache and also > occurs > before in the _krb5_gss_cred_id_rec structure definition, > acceptor_subkey_cksumtype should be unpacked BEFORE cred_rcache, > else the > values will get swapped. > > Current Code in kg_ctx_internalize() function: > > if (!kret) > kret = krb5_ser_unpack_int32(&ibuf, &bp, &remain); > ctx->cred_rcache = ibuf; > if (!kret) > kret = krb5_ser_unpack_int32(&ibuf, &bp, &remain); > ctx->acceptor_subkey_cksumtype = ibuf; > > Proposed Code in kg_ctx_internalize() function with change in > sequence > while unpacking: > > if (!kret) > kret = krb5_ser_unpack_int32(&ibuf, &bp, &remain); > ctx->acceptor_subkey_cksumtype = ibuf; > if (!kret) > kret = krb5_ser_unpack_int32(&ibuf, &bp, &remain); > ctx->cred_rcache = ibuf; > > > Kindly let me know if this is valid. > > - Sachin > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > -- www.padl.com | www.fghr.net From tlyu at MIT.EDU Wed Dec 24 01:23:17 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Wed, 24 Dec 2008 01:23:17 -0500 Subject: Possible bug in "kg_ctx_internalize()" function in MIT 1.6.3 In-Reply-To: <9549b1d80812232149k375130cic12bed9585025add@mail.gmail.com> (Sachin Punadikar's message of "Wed, 24 Dec 2008 11:19:01 +0530") References: <9549b1d80812232149k375130cic12bed9585025add@mail.gmail.com> Message-ID: "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. > Thanks. > - Sachin > > ---------- Forwarded message ---------- > From: Sachin Punadikar > Date: Mon, Dec 1, 2008 at 3:33 PM > Subject: kg_ctx_internalize() function in MIT 1.6.3 > To: kerberos at mit.edu > > > Hello, > > I was going through the gssapi MIT krb1.6.3 code and I feel there is a > possible bug in kg_ctx_internalize() function defined in > src/lib/gssapi/krb5/ser_sctx.c file. > > As I understand the function should unpack entities in the same order in > which they were packed by kg_ctx_externalize() function. But it misses the > order while unpacking the last two structure variables as shown below. Since > acceptor_subkey_cksumtype was packed before cred_rcache and also occurs > before in the _krb5_gss_cred_id_rec structure definition, > acceptor_subkey_cksumtype should be unpacked BEFORE cred_rcache, else the > values will get swapped. > > Current Code in kg_ctx_internalize() function: > > if (!kret) > kret = krb5_ser_unpack_int32(&ibuf, &bp, &remain); > ctx->cred_rcache = ibuf; > if (!kret) > kret = krb5_ser_unpack_int32(&ibuf, &bp, &remain); > ctx->acceptor_subkey_cksumtype = ibuf; > > Proposed Code in kg_ctx_internalize() function with change in sequence > while unpacking: > > if (!kret) > kret = krb5_ser_unpack_int32(&ibuf, &bp, &remain); > ctx->acceptor_subkey_cksumtype = ibuf; > if (!kret) > kret = krb5_ser_unpack_int32(&ibuf, &bp, &remain); > ctx->cred_rcache = ibuf; > > > Kindly let me know if this is valid. > > - Sachin > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev From tlyu at MIT.EDU Sun Dec 28 17:04:25 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Sun, 28 Dec 2008 17:04:25 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 Message-ID: I am starting a review of http://k5wiki.kerberos.org/wiki/Projects/replay_cache_collision_avoidance ending January 12, 2009. This is a slight modification of Jeff Altman's previous early-stage proposal: * Removed Base64 encoding because there is no existing Base64 support in the krb5 library, and I see no convincing reason to adding such at this time. I also found a way to store the unencoded binary data directly. * Clarified some replay cache file format quirks. * Use a more general extension record mechanism. * Propose using MD5 instead of SHA-1. There is no reason to require a cryptographically strong hash here, and truncating a SHA-1 hash to 128 bits adds additional complexity. -- Tom Yu Development Manager MIT Kerberos Consortium From ghudson at MIT.EDU Sun Dec 28 19:59:09 2008 From: ghudson at MIT.EDU (Greg Hudson) Date: Sun, 28 Dec 2008 19:59:09 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: References: Message-ID: <1230512349.6322.5.camel@ray> I have two comments: 1. I don't see why it is necessary to store and compare the full authenticator text. The consequences of a false hash collision are a false replay denial; but the odds of this happening by accident are vanishingly low, even if the hash function is insecure. (And if it happens on purpose, we don't care.) 2 If we are storing the full authenticator text, I'm not sure that it will save any time to also store a hash. Comparing two different authenticators should be fast because we can stop as soon as we hit the first byte which differs. Also, the time spent reading the record will be comparable to the time spent comparing it. From tlyu at MIT.EDU Sun Dec 28 22:32:29 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Sun, 28 Dec 2008 22:32:29 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: <1230512349.6322.5.camel@ray> (Greg Hudson's message of "Sun, 28 Dec 2008 19:59:09 -0500") References: <1230512349.6322.5.camel@ray> Message-ID: Greg Hudson writes: > I have two comments: > > 1. I don't see why it is necessary to store and compare the full > authenticator text. The consequences of a false hash collision are a > false replay denial; but the odds of this happening by accident are > vanishingly low, even if the hash function is insecure. (And if it > happens on purpose, we don't care.) This is a good point. > 2 If we are storing the full authenticator text, I'm not sure that it > will save any time to also store a hash. Comparing two different > authenticators should be fast because we can stop as soon as we hit the > first byte which differs. Also, the time spent reading the record will > be comparable to the time spent comparing it. For a fixed client name, the first difference would likely be at the application checksum, which could be farther into the encoded authenticator cleartext than the length of an MD5 hash. The point about needing to spend time reading in the entire authenticator cleartext is also a good one. These points lead me to lean toward abandoning the "store whole authenticator cleartext" scheme. This does cause me to think that this scheme has a problem when faced with the scenario of a replay cache shared between an old and a new implementation. Consider two authenticators that would match under the old implementation, but one authenticator is recorded by an old implementation and one is recorded by a new implementation. Now imagine that a new implementation receives a replay of the authenticator recorded by the old implementation. Its hash won't match the hash of the entry recorded by the new implementation, so this authenticator should be accepted by the new implementation IF it is known that no old implementation has written to the file. How do we make this determination usefully? I think I might have somewhat of an idea of how to do this, but need to think about it some more. It has to do with ensuring that a new implementation always writes pairs of entries (hash entry immediately followed by old-style entry) and keeps track of which entries are not paired with hash entries. From jaltman at secure-endpoints.com Mon Dec 29 00:06:06 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Mon, 29 Dec 2008 00:06:06 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: References: <1230512349.6322.5.camel@ray> Message-ID: <49585ABE.3070709@secure-endpoints.com> Tom Yu wrote: > Greg Hudson writes: > >> I have two comments: >> >> 1. I don't see why it is necessary to store and compare the full >> authenticator text. The consequences of a false hash collision are a >> false replay denial; but the odds of this happening by accident are >> vanishingly low, even if the hash function is insecure. (And if it >> happens on purpose, we don't care.) > > This is a good point. The reason the full authenticator is being stored is not so that it can be compared today but so that it is available for alternate comparisons in the future. If you go back through the history of the replay cache discussions there were concerns that it might be possible to alter the binary authenticator by adjusting the asn.1 representation of the components. >> 2 If we are storing the full authenticator text, I'm not sure that it >> will save any time to also store a hash. Comparing two different >> authenticators should be fast because we can stop as soon as we hit the >> first byte which differs. Also, the time spent reading the record will >> be comparable to the time spent comparing it. > > For a fixed client name, the first difference would likely be at the > application checksum, which could be farther into the encoded > authenticator cleartext than the length of an MD5 hash. The point > about needing to spend time reading in the entire authenticator > cleartext is also a good one. These points lead me to lean toward > abandoning the "store whole authenticator cleartext" scheme. > > This does cause me to think that this scheme has a problem when faced > with the scenario of a replay cache shared between an old and a new > implementation. > > Consider two authenticators that would match under the old > implementation, but one authenticator is recorded by an old > implementation and one is recorded by a new implementation. Now > imagine that a new implementation receives a replay of the > authenticator recorded by the old implementation. Its hash won't > match the hash of the entry recorded by the new implementation, so > this authenticator should be accepted by the new implementation IF it > is known that no old implementation has written to the file. How do > we make this determination usefully? > > I think I might have somewhat of an idea of how to do this, but need > to think about it some more. It has to do with ensuring that a new > implementation always writes pairs of entries (hash entry immediately > followed by old-style entry) and keeps track of which entries are not > paired with hash entries. There are absolutely weaknesses while both formats are supported. Supporting both formats provides a viable transition path. 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/20081229/8690b572/smime.bin From tlyu at MIT.EDU Mon Dec 29 00:13:38 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 29 Dec 2008 00:13:38 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: <49585ABE.3070709@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 29 Dec 2008 00:06:06 -0500") References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> Message-ID: Jeffrey Altman writes: > Tom Yu wrote: >> Greg Hudson writes: >> >>> I have two comments: >>> >>> 1. I don't see why it is necessary to store and compare the full >>> authenticator text. The consequences of a false hash collision are a >>> false replay denial; but the odds of this happening by accident are >>> vanishingly low, even if the hash function is insecure. (And if it >>> happens on purpose, we don't care.) >> >> This is a good point. > > The reason the full authenticator is being stored is not so that it can > be compared today but so that it is available for alternate comparisons > in the future. > > If you go back through the history of the replay cache discussions > there were concerns that it might be possible to alter the binary > authenticator by adjusting the asn.1 representation of the components. I will try to dig up records of those discussions, but a pointer would be helpful. Can this alteration be done by an attacker lacking knowledge of the session key? I thought we made sure that any modern Kerberos cryptosystem (not one of the single-DES ones...) would not be vulnerable to such cryptographic attacks. From ghudson at MIT.EDU Mon Dec 29 02:42:04 2008 From: ghudson at MIT.EDU (Greg Hudson) Date: Mon, 29 Dec 2008 02:42:04 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> Message-ID: <1230536524.6322.38.camel@ray> On Mon, 2008-12-29 at 00:13 -0500, Tom Yu wrote: > I will try to dig up records of those discussions, but a pointer would > be helpful. I found: http://mailman.mit.edu/pipermail/krbdev/2005-May/003444.html http://mailman.mit.edu/pipermail/krbdev/2005-June/003455.html These posts from Sam are particularly relevant: http://mailman.mit.edu/pipermail/krbdev/2005-June/003457.html http://mailman.mit.edu/pipermail/krbdev/2005-June/003464.html The conversation picks up again in 2008: http://mailman.mit.edu/pipermail/krbdev/2008-May/006601.html I'm not finding any piece of discussion specifically connecting the dots between "maybe an attacker can perturb the authenticator a little bit and change its hash without invalidating it" and "we should store the authenticator". In fact, Sam seemed to be arguing simply for hashing the decrypted authenticator rather than its encrypted form. From hartmans at MIT.EDU Mon Dec 29 07:33:10 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 29 Dec 2008 07:33:10 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: <1230536524.6322.38.camel@ray> (Greg Hudson's message of "Mon, 29 Dec 2008 02:42:04 -0500") References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> Message-ID: >>>>> "Greg" == Greg Hudson writes: Greg> On Mon, 2008-12-29 at 00:13 -0500, Tom Yu wrote: >> I will try to dig up records of those discussions, but a >> pointer would be helpful. Greg> I found: Greg> http://mailman.mit.edu/pipermail/krbdev/2005-May/003444.html Greg> http://mailman.mit.edu/pipermail/krbdev/2005-June/003455.html Greg> These posts from Sam are particularly relevant: Greg> http://mailman.mit.edu/pipermail/krbdev/2005-June/003457.html Greg> http://mailman.mit.edu/pipermail/krbdev/2005-June/003464.html Greg> The conversation picks up again in 2008: Greg> http://mailman.mit.edu/pipermail/krbdev/2008-May/006601.html Greg> I'm not finding any piece of discussion specifically Greg> connecting the dots between "maybe an attacker can perturb Greg> the authenticator a little bit and change its hash without Greg> invalidating it" and "we should store the authenticator". Greg> In fact, Sam seemed to be arguing simply for hashing the Greg> decrypted authenticator rather than its encrypted form. I think it is sufficient from a security standpoint. I'm not sure that two authenticators will differ in their decrypted form if they are produced by the same client at the same time using the same session key and no subsession key. However please see the thread from July 2008 on ietf-krb-wg titled "Replays and ciphertext Comparison." In that thread Ken and I discuss whether RFC 3961 gives you strong enough guarantees that changes to the ciphertext will be detected. Quoting Ken: Ken> On Jul 10, 2008, at 13:59, Sam Hartman wrote: >> However, I don't think that this is guaranteed to be safe. >> Consider for example an encryption system based on CBC that >> stores length information about the message so that the >> application does not need to do so. Also, assume that the >> encryption system MACs the plaintext not the ciphertext. >> >> An attacker could change final padding with this encryption >> system, changing the ciphertext, but not the plaintext. Ken> The specification of the decrypt function in 3961 says, Ken> "verifies the integrity of the supplied ciphertext". That Ken> suggests that changing the ciphertext, even if the only Ken> effect in decrypting is to alter some padding bytes added on Ken> the end of the encoded ASN.1 message or other blob, should be Ken> detected and treated as an error. While I didn't read RFC 3961 that way originally, I find Ken's reading compelling. I believe that current Kerberos crypto systems meet that invarient. So, I believe storing a hash of the encrypted text is appropriate and sufficient. From tlyu at MIT.EDU Mon Dec 29 08:02:22 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 29 Dec 2008 08:02:22 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: <1230536524.6322.38.camel@ray> (Greg Hudson's message of "Mon, 29 Dec 2008 02:42:04 -0500") References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> Message-ID: Greg Hudson writes: > On Mon, 2008-12-29 at 00:13 -0500, Tom Yu wrote: >> I will try to dig up records of those discussions, but a pointer would >> be helpful. > > I found: > > http://mailman.mit.edu/pipermail/krbdev/2005-May/003444.html > http://mailman.mit.edu/pipermail/krbdev/2005-June/003455.html > > These posts from Sam are particularly relevant: > > http://mailman.mit.edu/pipermail/krbdev/2005-June/003457.html > http://mailman.mit.edu/pipermail/krbdev/2005-June/003464.html Thanks. The above messages from Sam concern changes to the AP-REQ that are not the actual ciphertext of the encrypted authenticator. If an attacker does not know the key, and manipulates the ciphertext, the result will not be valid ciphertext except with probability on the order of a successful exhaustive key search of the cipher. Sam, if you know of a way that changing the actual ciphertext without knowing the key will cause problems, please explain. This message http://mailman.mit.edu/pipermail/krbdev/2005-May/003445.html does imply that storing binary strings in the replay cache could cause problems for old implementations. The worst case I can come up with, given the current form of the proposal, is that an old implementation would truncate the extension records at the leading zero byte when doing an expunge. A new implementation could detect this corruption and compensate accordingly, possibly with an increased number of false positives. What proportion of false positives is acceptable in a mixed-code deployment? One interesting possibility is to store a truncated copy of the hash in the microseconds field, which an old implementation would likely preserve when performing an expunge. Since we have two counted byte arrays in the record, we could make one of them the extension record that starts with a zero byte, and another that looks like a normal null-terminated string and would be preserved by an old implementation. > The conversation picks up again in 2008: > > http://mailman.mit.edu/pipermail/krbdev/2008-May/006601.html > > I'm not finding any piece of discussion specifically connecting the dots > between "maybe an attacker can perturb the authenticator a little bit > and change its hash without invalidating it" and "we should store the > authenticator". In fact, Sam seemed to be arguing simply for hashing > the decrypted authenticator rather than its encrypted form. I'd still like to know what benefit hashing the decrypted authenticator has above hashing the ciphertext. As Roland pointed out elsewhere in that thread, the mandatory parts of the cleartext authenticator contain nothing that is guaranteed to be different for multiple rapidly consecutive legitimate requests. Hashing the ciphertext makes it less likely that false positives will occur. From tlyu at MIT.EDU Mon Dec 29 08:11:46 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 29 Dec 2008 08:11:46 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: (Sam Hartman's message of "Mon, 29 Dec 2008 07:33:10 -0500") References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> Message-ID: Sam Hartman writes: > However please see the thread from July 2008 on ietf-krb-wg titled > "Replays and ciphertext Comparison." In that thread Ken and I discuss > whether RFC 3961 gives you strong enough guarantees that changes to > the ciphertext will be detected. > > Quoting Ken: > > Ken> On Jul 10, 2008, at 13:59, Sam Hartman wrote: > >> However, I don't think that this is guaranteed to be safe. > >> Consider for example an encryption system based on CBC that > >> stores length information about the message so that the > >> application does not need to do so. Also, assume that the > >> encryption system MACs the plaintext not the ciphertext. > >> > >> An attacker could change final padding with this encryption > >> system, changing the ciphertext, but not the plaintext. > > Ken> The specification of the decrypt function in 3961 says, > Ken> "verifies the integrity of the supplied ciphertext". That > Ken> suggests that changing the ciphertext, even if the only > Ken> effect in decrypting is to alter some padding bytes added on > Ken> the end of the encoded ASN.1 message or other blob, should be > Ken> detected and treated as an error. > > > While I didn't read RFC 3961 that way originally, I find Ken's reading > compelling. I believe that current Kerberos crypto systems meet that > invarient. > So, I believe storing a hash of the encrypted text is appropriate and > sufficient. I agree. Relatedly, I think we should consider reworking RFC 3961 to use terminology and concepts better aligned with current research in provably secure cryptography, but that's for another time. From ghudson at MIT.EDU Mon Dec 29 11:45:39 2008 From: ghudson at MIT.EDU (Greg Hudson) Date: Mon, 29 Dec 2008 11:45:39 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> Message-ID: <1230569139.6322.46.camel@ray> On Mon, 2008-12-29 at 08:02 -0500, Tom Yu wrote: > What proportion of false positives is acceptable in a mixed-code > deployment? I think mixed-code deployments are going to be rare. It's good that we're going to effort to prevent things from breaking in such deployments, but I don't think we need to bend over backwards to ensure that we still get a reduction in false positives in such environments. > One interesting possibility is to store a truncated copy of the hash > in the microseconds field, which an old implementation would likely > preserve when performing an expunge. Speaking of which, the project proposal says: For new servers reading entries written by old servers, the string fields will be valid principal names and the time stamp value will not be a small integer. As a result, the server will know it is dealing with an old style entry and perform an old style check. This might lead to false positives but there is nothing we can do without additional information that is not available. but the earlier part of the proposal doesn't mention anything about putting a small integer in the time stamp value of hash records. Is there a missing bit of the proposal? > I'd still like to know what benefit hashing the decrypted > authenticator has above hashing the ciphertext. As Roland pointed out > elsewhere in that thread, the mandatory parts of the cleartext > authenticator contain nothing that is guaranteed to be different for > multiple rapidly consecutive legitimate requests. Hashing the > ciphertext makes it less likely that false positives will occur. I think Sam has reversed his position on that point based on discussion with Ken, and we can safely hash the authenticator ciphertext. From tlyu at MIT.EDU Mon Dec 29 11:57:18 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 29 Dec 2008 11:57:18 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: <1230569139.6322.46.camel@ray> (Greg Hudson's message of "Mon, 29 Dec 2008 11:45:39 -0500") References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> <1230569139.6322.46.camel@ray> Message-ID: Greg Hudson writes: > On Mon, 2008-12-29 at 08:02 -0500, Tom Yu wrote: >> What proportion of false positives is acceptable in a mixed-code >> deployment? > > I think mixed-code deployments are going to be rare. It's good that > we're going to effort to prevent things from breaking in such > deployments, but I don't think we need to bend over backwards to ensure > that we still get a reduction in false positives in such environments. I think that looking for pairs of entries as an indication of a record written by a new implementation will reduce the number of false positives for authenticators received by new implementations. I'm fairly sure this gives us at least a somewhat improved false-positive rate in a mixed-code deployment. >> One interesting possibility is to store a truncated copy of the hash >> in the microseconds field, which an old implementation would likely >> preserve when performing an expunge. > > Speaking of which, the project proposal says: > > For new servers reading entries written by old servers, the > string fields will be valid principal names and the time stamp > value will not be a small integer. As a result, the server will > know it is dealing with an old style entry and perform an old > style check. This might lead to false positives but there is > nothing we can do without additional information that is not > available. > > but the earlier part of the proposal doesn't mention anything about > putting a small integer in the time stamp value of hash records. Is > there a missing bit of the proposal? I think I forgot to update part of the proposal after I removed the part of the prior version of the proposal that would put identifying information in the timestamp field. I think it turns out that using the timestamp that way would cause an old implementation to prematurely expunge new-style cache records. >> I'd still like to know what benefit hashing the decrypted >> authenticator has above hashing the ciphertext. As Roland pointed out >> elsewhere in that thread, the mandatory parts of the cleartext >> authenticator contain nothing that is guaranteed to be different for >> multiple rapidly consecutive legitimate requests. Hashing the >> ciphertext makes it less likely that false positives will occur. > > I think Sam has reversed his position on that point based on discussion > with Ken, and we can safely hash the authenticator ciphertext. Ok, it looks like we have consensus on this part. From hartmans at MIT.EDU Mon Dec 29 12:28:14 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 29 Dec 2008 12:28:14 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: (Tom Yu's message of "Mon, 29 Dec 2008 08:02:22 -0500") References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> Message-ID: >>>>> "Tom" == Tom Yu writes: Tom> Sam, if you know of a way that changing the actual ciphertext Tom> without knowing the key will cause problems, please explain. Tom> This message Tom> http://mailman.mit.edu/pipermail/krbdev/2005-May/003445.html Tom> does imply that storing binary strings in the replay cache Tom> could cause problems for old implementations. The worst case Tom> I can come up with, given the current form of the proposal, Tom> is that an old implementation would truncate the extension Tom> records at the leading zero byte when doing an expunge. A Tom> new implementation could detect this corruption and Tom> compensate accordingly, possibly with an increased number of Tom> false positives. Tom> What proportion of false positives is acceptable in a Tom> mixed-code deployment? Tom> One interesting possibility is to store a truncated copy of Tom> the hash in the microseconds field, which an old Tom> implementation would likely preserve when performing an Tom> expunge. Tom> Since we have two counted byte arrays in the record, we could Tom> make one of them the extension record that starts with a zero Tom> byte, and another that looks like a normal null-terminated Tom> string and would be preserved by an old implementation. >> The conversation picks up again in 2008: >> >> http://mailman.mit.edu/pipermail/krbdev/2008-May/006601.html >> >> I'm not finding any piece of discussion specifically connecting >> the dots between "maybe an attacker can perturb the >> authenticator a little bit and change its hash without >> invalidating it" and "we should store the authenticator". In >> fact, Sam seemed to be arguing simply for hashing the decrypted >> authenticator rather than its encrypted form. Tom> I'd still like to know what benefit hashing the decrypted Tom> authenticator has above hashing the ciphertext. As Roland Tom> pointed out elsewhere in that thread, the mandatory parts of Tom> the cleartext authenticator contain nothing that is Tom> guaranteed to be different for multiple rapidly consecutive Tom> legitimate requests. Hashing the ciphertext makes it less Tom> likely that false positives will occur. Tom> _______________________________________________ krbdev Tom> mailing list krbdev at mit.edu Tom> https://mailman.mit.edu/mailman/listinfo/krbdev As I explain in another message, I think that RFC 3961 allows us to avoid this. However, consider a stream cipher that integrity protects the plaintext, *not* the ciphertext. I think changes to the confounder would be undetected. It does not fall out of any of the standard definitions of security for symmetric ciphers--not even non-malleability--guarantees that it is hard given one ciphertext to construct another valid ciphertext with the same plaintext. From hartmans at MIT.EDU Mon Dec 29 12:31:52 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 29 Dec 2008 12:31:52 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: <1230569139.6322.46.camel@ray> (Greg Hudson's message of "Mon, 29 Dec 2008 11:45:39 -0500") References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> <1230569139.6322.46.camel@ray> Message-ID: >>>>> "Greg" == Greg Hudson writes: Greg> On Mon, 2008-12-29 at 08:02 -0500, Tom Yu wrote: >> What proportion of false positives is acceptable in a >> mixed-code deployment? Greg> I think mixed-code deployments are going to be rare. It's Greg> good that we're going to effort to prevent things from Greg> breaking in such deployments, but I don't think we need to Greg> bend over backwards to ensure that we still get a reduction Greg> in false positives in such environments. Greg, here are things that I think will make mixed-code reasonably common. * Using the native Java interface along side an OS library * different 64-bit and 32-bit libraries * Using Heimdal and MIT code on the same system I think the standard we want is to try and avoid increasing the false positive rate over what it is today. From hartmans at MIT.EDU Mon Dec 29 12:34:58 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 29 Dec 2008 12:34:58 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: (Sam Hartman's message of "Mon, 29 Dec 2008 12:31:52 -0500") References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> <1230569139.6322.46.camel@ray> Message-ID: You know, my examples aren't so good. I don't think Java and MIT share a replay cache format. I don't think Haemdal and MIT do either. From jaltman at secure-endpoints.com Mon Dec 29 12:44:57 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Mon, 29 Dec 2008 12:44:57 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> <1230569139.6322.46.camel@ray> Message-ID: <49590C99.50308@secure-endpoints.com> Sam Hartman wrote: > You know, my examples aren't so good. I don't think Java and MIT share a replay cache format. Solaris GSS (or other vendor provided implementation) MIT Kerberos (mixed versions due to static libraries) CyberSafe -------------- 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/20081229/33068c67/smime.bin From Tim.Alsop at CyberSafe.com Mon Dec 29 12:53:20 2008 From: Tim.Alsop at CyberSafe.com (Tim Alsop) Date: Mon, 29 Dec 2008 17:53:20 +0000 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: <49590C99.50308@secure-endpoints.com> References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> <1230569139.6322.46.camel@ray> <49590C99.50308@secure-endpoints.com> Message-ID: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E4902DFB@exchange.cybersafe.local> Hi, The CyberSafe TrustBroker products use a replay cache file located in /var/tmp (symlink = /krb5/tmp/rc). The replay cache file can be relocated by changing the symlink after the product has been installed (or changing registry entry on Windows version). The format of the file is the same as MIT replay cache file format. The KDC (TrustBroker Security Server) has an option to disable replay attack, and network replay detection. Thanks, Tim -----Original Message----- From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of Jeffrey Altman Sent: 29 December 2008 17:45 Cc: krbdev at mit.edu Subject: Re: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 Sam Hartman wrote: > You know, my examples aren't so good. I don't think Java and MIT share a replay cache format. Solaris GSS (or other vendor provided implementation) MIT Kerberos (mixed versions due to static libraries) CyberSafe From tlyu at MIT.EDU Mon Dec 29 12:57:26 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 29 Dec 2008 12:57:26 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: (Sam Hartman's message of "Mon, 29 Dec 2008 12:28:14 -0500") References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> Message-ID: Sam Hartman writes: >>>>>> "Tom" == Tom Yu writes: > > Tom> Sam, if you know of a way that changing the actual ciphertext > Tom> without knowing the key will cause problems, please explain. > > Tom> This message > > Tom> http://mailman.mit.edu/pipermail/krbdev/2005-May/003445.html > > Tom> does imply that storing binary strings in the replay cache > Tom> could cause problems for old implementations. The worst case > Tom> I can come up with, given the current form of the proposal, > Tom> is that an old implementation would truncate the extension > Tom> records at the leading zero byte when doing an expunge. A > Tom> new implementation could detect this corruption and > Tom> compensate accordingly, possibly with an increased number of > Tom> false positives. > > Tom> What proportion of false positives is acceptable in a > Tom> mixed-code deployment? > > Tom> One interesting possibility is to store a truncated copy of > Tom> the hash in the microseconds field, which an old > Tom> implementation would likely preserve when performing an > Tom> expunge. > > Tom> Since we have two counted byte arrays in the record, we could > Tom> make one of them the extension record that starts with a zero > Tom> byte, and another that looks like a normal null-terminated > Tom> string and would be preserved by an old implementation. > > >> The conversation picks up again in 2008: > >> > >> http://mailman.mit.edu/pipermail/krbdev/2008-May/006601.html > >> > >> I'm not finding any piece of discussion specifically connecting > >> the dots between "maybe an attacker can perturb the > >> authenticator a little bit and change its hash without > >> invalidating it" and "we should store the authenticator". In > >> fact, Sam seemed to be arguing simply for hashing the decrypted > >> authenticator rather than its encrypted form. > > Tom> I'd still like to know what benefit hashing the decrypted > Tom> authenticator has above hashing the ciphertext. As Roland > Tom> pointed out elsewhere in that thread, the mandatory parts of > Tom> the cleartext authenticator contain nothing that is > Tom> guaranteed to be different for multiple rapidly consecutive > Tom> legitimate requests. Hashing the ciphertext makes it less > Tom> likely that false positives will occur. > Tom> _______________________________________________ krbdev > Tom> mailing list krbdev at mit.edu > Tom> https://mailman.mit.edu/mailman/listinfo/krbdev > > > As I explain in another message, I think that RFC 3961 allows us to > avoid this. However, consider a stream cipher that integrity protects > the plaintext, *not* the ciphertext. I think changes to the > confounder would be undetected. Do we know of such an encryption scheme being used with Kerberos? > It does not fall out of any of the standard definitions of security > for symmetric ciphers--not even non-malleability--guarantees that it > is hard given one ciphertext to construct another valid ciphertext > with the same plaintext. Actually the 2000 paper by Bellare and Namprempre describes some formal notions that could help here. We strongly imply in RFC 3961 that the property we desire is INT-CTXT. "We consider two notions of integrity (we use the terms authenticity and integrity interchangeably) for symmetric encryption schemes. INT-PTXT (integrity of plaintexts) requires that it be computationally infeasible to produce a ciphertext decrypting to a message which the sender had never encrypted, while INT-CTXT (integrity of ciphertexts) requires that it be computationally infeasible to produce a ciphertext not previously produced by the sender, regardless of whether or not the underlying plaintext is 'new'. (In both cases, the adversary is allowed a chosen-message attack.) The first of these notions is the more natrual security requirement while the interest of the second, stronger notion is perhaps more in the impleications we discuss below." [1] I don't know whether the terminology is original to those authors, but I think it is useful. [1] M. Bellare and C. Namprempre, "Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm", extended version of a paper appearing in T. Okamoto ed., ASIACRYPT 2000, Lecture Notes in Computer Science 1976, pp. 531-545. Springer-Verlag, 2000. From tlyu at MIT.EDU Mon Dec 29 14:35:24 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 29 Dec 2008 14:35:24 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: (Sam Hartman's message of "Mon, 29 Dec 2008 12:31:52 -0500") References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> <1230569139.6322.46.camel@ray> Message-ID: Sam Hartman writes: >>>>>> "Greg" == Greg Hudson writes: > > Greg> On Mon, 2008-12-29 at 08:02 -0500, Tom Yu wrote: > >> What proportion of false positives is acceptable in a > >> mixed-code deployment? > > Greg> I think mixed-code deployments are going to be rare. It's > Greg> good that we're going to effort to prevent things from > Greg> breaking in such deployments, but I don't think we need to > Greg> bend over backwards to ensure that we still get a reduction > Greg> in false positives in such environments. > > > > Greg, here are things that I think will make mixed-code reasonably common. > * Using the native Java interface along side an OS library > * different 64-bit and 32-bit libraries 64-bit vs 32-bit could be problematic if the two architectures have different sizes for "int". From tlyu at MIT.EDU Mon Dec 29 15:49:20 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 29 Dec 2008 15:49:20 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E4902DFB@exchange.cybersafe.local> (Tim Alsop's message of "Mon, 29 Dec 2008 17:53:20 +0000") References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> <1230569139.6322.46.camel@ray> <49590C99.50308@secure-endpoints.com> <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E4902DFB@exchange.cybersafe.local> Message-ID: Tim Alsop writes: > The CyberSafe TrustBroker products use a replay cache file located > in /var/tmp (symlink = /krb5/tmp/rc). The replay cache file can be > relocated by changing the symlink after the product has been > installed (or changing registry entry on Windows version). The > format of the file is the same as MIT replay cache file format. The > KDC (TrustBroker Security Server) has an option to disable replay > attack, and network replay detection. Thanks, this is useful to know. Is the symlink of a file or a directory? From Tim.Alsop at CyberSafe.com Mon Dec 29 16:08:40 2008 From: Tim.Alsop at CyberSafe.com (Tim Alsop) Date: Mon, 29 Dec 2008 21:08:40 +0000 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 Message-ID: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E4907176@exchange.cybersafe.local> Tom, The symlink is a directory. The directory name is rc Thanks, Tim Sent from my Windows Mobile? phone. -----Original Message----- From: Tom Yu Sent: 29 December 2008 20:52 To: Tim Alsop Cc: jaltman at secure-endpoints.com ; krbdev at mit.edu Subject: Re: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 Tim Alsop writes: > The CyberSafe TrustBroker products use a replay cache file located > in /var/tmp (symlink = /krb5/tmp/rc). The replay cache file can be > relocated by changing the symlink after the product has been > installed (or changing registry entry on Windows version). The > format of the file is the same as MIT replay cache file format. The > KDC (TrustBroker Security Server) has an option to disable replay > attack, and network replay detection. Thanks, this is useful to know. Is the symlink of a file or a directory? From Nicolas.Williams at sun.com Mon Dec 29 16:19:01 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 29 Dec 2008 15:19:01 -0600 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> Message-ID: <20081229211901.GB1872@Sun.COM> On Mon, Dec 29, 2008 at 12:28:14PM -0500, Sam Hartman wrote: > As I explain in another message, I think that RFC 3961 allows us to > avoid this. However, consider a stream cipher that integrity protects > the plaintext, *not* the ciphertext. I think changes to the > confounder would be undetected. Would a such a cipher have a confounder? Or did you mean something like a salt for deriving a message key? In any case, as long as the ciphertext being used is that of an Authenticator that was decrypted and integrity verified then there should not be any problem, BUT: - Do make sure that ASN.1 DER cleartext bits are not included in the definition of "ciphertext" (i.e., no EncryptedData tag, length, etype, kvno, and cipher tags and length), because those might provide a way for an attacker to change the encoding without changing the actual ciphertext. > It does not fall out of any of the standard definitions of security > for symmetric ciphers--not even non-malleability--guarantees that it > is hard given one ciphertext to construct another valid ciphertext > with the same plaintext. I would prefer hashing the cleartext of the Authenticator because there's less to think about with respect to replay attacks, though it does require that the client use a sub-session key in order to help with the false positives issue, but then, I think that clients that reuse ctime/cusec values [when generating multiple authenticators in the same second] typically (if not always) also assert a sub-session key. Nico -- From tlyu at MIT.EDU Mon Dec 29 16:48:03 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 29 Dec 2008 16:48:03 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: <20081229211901.GB1872@Sun.COM> (Nicolas Williams's message of "Mon, 29 Dec 2008 15:19:01 -0600") References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> <20081229211901.GB1872@Sun.COM> Message-ID: Nicolas Williams writes: > - Do make sure that ASN.1 DER cleartext bits are not included in the > definition of "ciphertext" (i.e., no EncryptedData tag, length, > etype, kvno, and cipher tags and length), because those might provide > a way for an attacker to change the encoding without changing the > actual ciphertext. That is what I was intending. I would think that "ciphertext" would unambiguously specify "bytes you input to an encryption scheme (as in RFC 3961)". > I would prefer hashing the cleartext of the Authenticator because > there's less to think about with respect to replay attacks, though it > does require that the client use a sub-session key in order to help with > the false positives issue, but then, I think that clients that reuse > ctime/cusec values [when generating multiple authenticators in the same > second] typically (if not always) also assert a sub-session key. I prefer using the hash of the ciphertext because I believe it gives us a higher chance of avoiding false positives, and the possible attacks on that method require a large work factor on the part of the attacker and that the target uses weak crypto. If we are going to hash the cleartext of the authenticator, we need some more information about the applications where the false positive behavior is problematic. Do such applications actually tend to have clients that send subkeys? From Nicolas.Williams at sun.com Mon Dec 29 23:25:22 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 29 Dec 2008 22:25:22 -0600 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: References: <1230512349.6322.5.camel@ray> <49585ABE.3070709@secure-endpoints.com> <1230536524.6322.38.camel@ray> <20081229211901.GB1872@Sun.COM> Message-ID: <20081230042522.GF1872@Sun.COM> On Mon, Dec 29, 2008 at 04:48:03PM -0500, Tom Yu wrote: > Nicolas Williams writes: > > - Do make sure that ASN.1 DER cleartext bits are not included in the > > definition of "ciphertext" (i.e., no EncryptedData tag, length, > > etype, kvno, and cipher tags and length), because those might provide > > a way for an attacker to change the encoding without changing the > > actual ciphertext. > > That is what I was intending. I would think that "ciphertext" would > unambiguously specify "bytes you input to an encryption scheme (as in > RFC 3961)". OK, good. > > I would prefer hashing the cleartext of the Authenticator because > > there's less to think about with respect to replay attacks, though it > > does require that the client use a sub-session key in order to help with > > the false positives issue, but then, I think that clients that reuse > > ctime/cusec values [when generating multiple authenticators in the same > > second] typically (if not always) also assert a sub-session key. > > I prefer using the hash of the ciphertext because I believe it gives > us a higher chance of avoiding false positives, and the possible Because of confounders. > attacks on that method require a large work factor on the part of the > attacker and that the target uses weak crypto. > > If we are going to hash the cleartext of the authenticator, we need > some more information about the applications where the false positive > behavior is problematic. Do such applications actually tend to have > clients that send subkeys? That's my understanding. But as long as we leave out incidental cleartext from EncryptedData I think we'll be pretty much fine. Nico -- From ghudson at MIT.EDU Tue Dec 30 12:38:59 2008 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Tue, 30 Dec 2008 12:38:59 -0500 (EST) Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 In-Reply-To: Message-ID: <200812301738.mBUHcxki028192@outgoing.mit.edu> I have edited the project proposal to reflect the discussion here (renaming the one flag and adding comments to the others) and added an approval. One fine point: Luke wrote: > KRB5_PRINCIPAL_PARSE_NO_REALM omits the realm in the parsed principal. In both Luke's code and in Heimdal, PARSE_NO_REALM causes an error to occur if the principal string contains a realm. Thus: #define KRB5_PRINCIPAL_PARSE_NO_REALM 1 /* Error if realm is present */ #define KRB5_PRINCIPAL_PARSE_REQUIRE_REALM 2 /* Error if realm is not present */ #define KRB5_PRINCIPAL_PARSE_ENTERPRISE 4 /* Create single-component enterprise principle */ From hartmans at MIT.EDU Tue Dec 30 14:36:32 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 30 Dec 2008 14:36:32 -0500 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 In-Reply-To: (Luke Howard's message of "Wed, 24 Dec 2008 09:38:52 +1100") References: Message-ID: Luke, I have one question. KRB5_PRINCIPAL_UNPARSE_SHORT omits the local realm. What does that actually mean. The code seems to use the default realm. However MIT Kerberos's concept of default realm does not map particularly well say onto AD's concept of the local domain. The default realm is the realm that will be added to a principal if no other realm is specified. It does not imply trust, is may not be the same at the client's realm, it may not be the same as the realm of the current KDC, etc. The workstation may not be registered in the default realm and may not happen to trust KDCs from the default realm. I'm wondering if this is the intended meaning of the flag. I'm also wondering whether the use of UNPARSE_SHORT in pac.c is appropriate given these constraints on the default realm. --Sam From Nicolas.Williams at sun.com Tue Dec 30 15:41:13 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 30 Dec 2008 14:41:13 -0600 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: References: Message-ID: <20081230204112.GK1872@Sun.COM> On Sun, Dec 28, 2008 at 05:04:25PM -0500, Tom Yu wrote: > http://k5wiki.kerberos.org/wiki/Projects/replay_cache_collision_avoidance - This needs to be updated since we seem to agree that the authenticator cleartext should not be used. - In "Is this a long term fix for the problem?" the wiki says that "[the need to reject AP-REQs during the replay cache recovery time] implies that at the very least a change in file format would result in an outage." That's not really true. You could populate the new format file with records from the old one, provided you had an option for hash-less entries in the new format... Nico -- From Nicolas.Williams at sun.com Tue Dec 30 15:44:23 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 30 Dec 2008 14:44:23 -0600 Subject: Dynamic skew (Re: review of Projects/replay_cache_collision_avoidance, ending Jan. 12) In-Reply-To: References: Message-ID: <20081230204422.GL1872@Sun.COM> On Sun, Dec 28, 2008 at 05:04:25PM -0500, Tom Yu wrote: > http://k5wiki.kerberos.org/wiki/Projects/replay_cache_collision_avoidance I've long wondered if we couldn't play with making the skew dynamic to make the replay cache go faster by avoiding the need to commit the rcache to stable storage. On rcache recovery start with a skew of zero and grow it up to 5 minutes as time passes. This means that as long as clients and servers have reasonably synchronized clocks then most outages due to replay cache loss will be very short. Even better: at boot time you can set the initial skew to half the time it took to reach that point from the begining of the boot. If you do this then you don't need to commit the replay cache to stable storage: by the time the first AP-REQ can arrive you'll be past the time window during which replays could occur, and typical server time-to-boot/2 will be a reasonable time skew for client and server clocks. Time to boot is difficult to pin down, unfortunately. There's time spent on hardware POST, BIOS, ... measurements of which may be unavailable. To estimate POST and such time one needs to know whether a boot was cold, warm or fast ("fast reboot" == old kernel loads new kernel and transfers control without taking a trip through the BIOS). So the conservative thing to do is to ignore time spent in POST, BIOS, ... and focus only on kernel start->rcache creation time. Unfortunately there are no portable APIs that I know of for obtaining time to boot from the point the OS kernel started keeping time. To implement a dynamic time skew all you need is an entry in the rcache that tells you the: a) the time it was created, b) the skew at the time the rcache was created. The the current skew is trivial to calculate. (a) is also trivial to determine (whoever creates the rcache knows). (b) can trivially default to zero, and if you have a way to estimate time-to-boot conservatively, then you can have an rc script (or SMF service) to create the rcache at boot time with skew == half the time it took to reach that point from boot. If you ignore time-to-boot and always default the initial skew to zero then this is just so trivial to implement that you might as well do it while implementing the replay_cache_collision_avoidance project, with an option to control whether to fsync() the rcache that defaults to yes. Nico -- From raeburn at MIT.EDU Tue Dec 30 16:04:34 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Tue, 30 Dec 2008 16:04:34 -0500 Subject: Dynamic skew (Re: review of Projects/replay_cache_collision_avoidance, ending Jan. 12) In-Reply-To: <20081230204422.GL1872@Sun.COM> References: <20081230204422.GL1872@Sun.COM> Message-ID: On Dec 30, 2008, at 15:44, Nicolas Williams wrote: > Time to boot is difficult to pin down, unfortunately. There's time > spent on hardware POST, BIOS, ... measurements of which may be > unavailable. To estimate POST and such time one needs to know > whether a > boot was cold, warm or fast ("fast reboot" == old kernel loads new > kernel and transfers control without taking a trip through the BIOS). > So the conservative thing to do is to ignore time spent in POST, BIOS, > ... and focus only on kernel start->rcache creation time. > Unfortunately > there are no portable APIs that I know of for obtaining time to boot > from the point the OS kernel started keeping time. You also need to make sure you don't get confused in the case where the boot-time clock value is bogus, and later corrected by NTP, so that time()-boot_time may be significantly different from seconds_since_boot. (Or, explicitly decide that you will trust the system clock to be accurate at startup.) Ken From Nicolas.Williams at sun.com Tue Dec 30 16:17:42 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 30 Dec 2008 15:17:42 -0600 Subject: Dynamic skew (Re: review of Projects/replay_cache_collision_avoidance, ending Jan. 12) In-Reply-To: References: <20081230204422.GL1872@Sun.COM> Message-ID: <20081230211742.GM1872@Sun.COM> On Tue, Dec 30, 2008 at 04:04:34PM -0500, Ken Raeburn wrote: > You also need to make sure you don't get confused in the case where > the boot-time clock value is bogus, and later corrected by NTP, so > that time()-boot_time may be significantly different from > seconds_since_boot. (Or, explicitly decide that you will trust the > system clock to be accurate at startup.) Right. Getting the correct time portably is going to be difficult, and best left to OS vendors/distros. The glue OS vendors/distros would need is this: an API (or CLI) to create an rcache with a given initial time skew other than zero. Thus all you giuys would have to do is: a) provide a way to record the time an rcache was created and its initial time skew, b) always defaulting the latter to zero, and c) an option to control whether to fsync() the rcache, defaulting to yes. OS vendors/distros could then change the default of (c) if they ensure that any abrupt time synchronization completes prior to any krb5 services coming online. And they could provide for non-zero initial time skew by doing additional OS-specific work. BTW, any time that the local clock changes abruptly there is an impact on the rcache, but RFC4120 does not mention this, probably because such changes are very rare post-boot, but it's important to make any abrupt clock synchronization at boot time before starting any time-sensitive services. Nico -- From ghudson at MIT.EDU Tue Dec 30 17:32:08 2008 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Tue, 30 Dec 2008 17:32:08 -0500 (EST) Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: Message-ID: <200812302232.mBUMW8uq027734@outgoing.mit.edu> I would like to reconsider the presence of the hash algorithm identifier in the proposal. The identifier was added in response to this exchange: http://mailman.mit.edu/pipermail/krbdev/2005-May/003447.html [Jeffrey Altman:] > I think we want to avoid the configurability at the moment. We can > use the server string as a marker for the type but I think having > multiple hash types in the file is only going to get us into trouble. [Jeffrey Hutzelman:] > Configurability in this dimension is not that important, at least > for the moment. However, _extensibility_ is important. Don't paint > yourselves into a corner in which you can't transition from one hash > to another. In my mind, this means the hash type would need to be > recored in each entry, so that future code can handle caches with > two hash types, for transition purposes. Here are my counterarguments: 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.) 2. Since the hash algorithm is not security-critical in this application, it is vanishingly unlikely that we will ever need to change it. 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. In fact, we already have a more general extensibility hook: the four-byte extension magic number extension magic number 0x48415348 ("HASH"). 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. From Nicolas.Williams at sun.com Tue Dec 30 17:45:26 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 30 Dec 2008 16:45:26 -0600 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: <200812302232.mBUMW8uq027734@outgoing.mit.edu> References: <200812302232.mBUMW8uq027734@outgoing.mit.edu> Message-ID: <20081230224526.GO1872@Sun.COM> On Tue, Dec 30, 2008 at 05:32:08PM -0500, ghudson at mit.edu wrote: > I would like to reconsider the presence of the hash algorithm > identifier in the proposal. The identifier was added in response to > this exchange: +1 As long as there's a way to extend the rcache (and there seems to be) then the hash algorithm ID is not really needed. And I think we all agree that it's very unlikely that we'll want to change whatever hash algorithm is selected. Also, for the longer term, I'd rather we have a CCAPI-like rcache type. This would be particularly useful for clusters. But the key is that the rcache needs to be pluggable. And any file format documentation should encourage third parties who are considering re-implementing it to consider a plug-in interface, or to re-use the plug-in interfaces from MIT. I'd really like to avoid the current situation where multiple distinct implementations (with disjoint origins) implement the same ccache/rcache/keytab file formats, with the ensuing constraints on changing those formats. Nico -- From tlyu at MIT.EDU Tue Dec 30 18:23:00 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Tue, 30 Dec 2008 18:23:00 -0500 Subject: summary of feedback on replay cache collision avoidance proposal Message-ID: I have revised the project proposal page http://k5wiki.kerberos.org/wiki/Projects/replay_cache_collision_avoidance to reflect some feedback. Items that we appear to agree on: * Hashing authenticator ciphertext is not a problem and is possibly even desirable. * Retaining the entire authenticator (either clear or ciphertext) provides no security advantages. * Binary data in extension is subject to truncation at null bytes by old implementations, so we should avoid that. Remaining questions: * Whether to use a hash algorithm identifier: Greg has some convincing arguments that we should not use one and should not incur the additional complexity of implementing hash agility. * General form of the extension encoding. We don't have to exactly specify how future extensions will work as long as we don't paint ourselves into a corner. I have suggested one (non-binary) alternative on the project proposal page. The extension for the hash currently includes a hash algorithm identifier, but I am not strongly attached to the idea. -- Tom Yu Development Manager MIT Kerberos Consortium From ghudson at MIT.EDU Tue Dec 30 19:02:43 2008 From: ghudson at MIT.EDU (Greg Hudson) Date: Tue, 30 Dec 2008 19:02:43 -0500 Subject: summary of feedback on replay cache collision avoidance proposal In-Reply-To: References: Message-ID: <1230681763.6322.73.camel@ray> On Tue, 2008-12-30 at 18:23 -0500, Tom Yu wrote: > * General form of the extension encoding. We don't have to exactly > specify how future extensions will work as long as we don't paint > ourselves into a corner. I have suggested one (non-binary) > alternative on the project proposal page. The extension for the > hash currently includes a hash algorithm identifier, but I am not > strongly attached to the idea. I would prefer "HASH:" as the extension identification instead of just "H:" but it's not a big deal. (It's just a little clearer; using "H:" now does not restrict us to single-byte identifiers in the future.) There should presumably be a null byte after the ciphertext. From lukeh at padl.com Tue Dec 30 20:23:29 2008 From: lukeh at padl.com (Luke Howard) Date: Wed, 31 Dec 2008 12:23:29 +1100 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 In-Reply-To: References: Message-ID: On 31/12/2008, at 6:36 AM, Sam Hartman wrote: > Luke, I have one question. > KRB5_PRINCIPAL_UNPARSE_SHORT omits the local realm. > > What does that actually mean. The code seems to use the default > realm. However MIT Kerberos's concept of default realm does not map > particularly well say onto AD's concept of the local domain. The > default realm is the realm that will be added to a principal if no > other realm is specified. It does not imply trust, is may not be the > same at the client's realm, it may not be the same as the realm of the > current KDC, etc. The workstation may not be registered in the > default realm and may not happen to trust KDCs from the default realm. > > > I'm wondering if this is the intended meaning of the flag. I'm also > wondering whether the use of UNPARSE_SHORT in pac.c is appropriate > given these constraints on the default realm. I had assumed that the default realm would be the local domain (perhaps because historically I'd been more concerned with KDC rather than client implementation, and one generally has some more control over the KDC configuration). So: the answer is, I need to think about this some more. I believe Heimdal has a similar issue. --luke From tlyu at MIT.EDU Tue Dec 30 23:36:50 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Tue, 30 Dec 2008 23:36:50 -0500 Subject: summary of feedback on replay cache collision avoidance proposal In-Reply-To: <1230681763.6322.73.camel@ray> (Greg Hudson's message of "Tue, 30 Dec 2008 19:02:43 -0500") References: <1230681763.6322.73.camel@ray> Message-ID: Greg Hudson writes: > On Tue, 2008-12-30 at 18:23 -0500, Tom Yu wrote: >> * General form of the extension encoding. We don't have to exactly >> specify how future extensions will work as long as we don't paint >> ourselves into a corner. I have suggested one (non-binary) >> alternative on the project proposal page. The extension for the >> hash currently includes a hash algorithm identifier, but I am not >> strongly attached to the idea. > > I would prefer "HASH:" as the extension identification instead of just > "H:" but it's not a big deal. (It's just a little clearer; using "H:" > now does not restrict us to single-byte identifiers in the future.) > > There should presumably be a null byte after the ciphertext. Thanks; updated accordingly. From hartmans at MIT.EDU Wed Dec 31 05:57:29 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Wed, 31 Dec 2008 05:57:29 -0500 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 In-Reply-To: (Luke Howard's message of "Wed, 31 Dec 2008 12:23:29 +1100") References: Message-ID: 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. In the PAC case, is the goal that the principal be short if the client and server are in the same realm? You could perhaps clone a context, set the default realm of that context and use unparse_short. From hartmans at MIT.EDU Wed Dec 31 06:03:52 2008 From: hartmans at MIT.EDU (Sam Hartman) Date: Wed, 31 Dec 2008 06:03:52 -0500 Subject: review of Projects/replay_cache_collision_avoidance, ending Jan. 12 In-Reply-To: <200812302232.mBUMW8uq027734@outgoing.mit.edu> (ghudson@MIT.EDU's message of "Tue, 30 Dec 2008 17:32:08 -0500 (EST)") References: <200812302232.mBUMW8uq027734@outgoing.mit.edu> Message-ID: 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. --Sam From Mark.Phalan at Sun.COM Wed Dec 31 12:02:00 2008 From: Mark.Phalan at Sun.COM (Mark Phalan) Date: Wed, 31 Dec 2008 18:02:00 +0100 Subject: tecla support for krb admin utilites Message-ID: <1230742920.6033.4.camel@zup> I just created #6311 with a patch which adds support for libtecla (http://www.astro.caltech.edu/~mcs/tecla/) to libss. The patch really should also modify the build system so that libtecla can be dynamically picked-up or dropped depending on availability. My auto* skills are weak so if anyone would like to add the auto* changes I'd appreciate it. -M From lha at kth.se Wed Dec 31 11:43:03 2008 From: lha at kth.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Wed, 31 Dec 2008 17:43:03 +0100 Subject: Review ofhttp://k5wiki.kerberos.org/wiki/Projects/PAC_and_principal_APIs ending January 10 In-Reply-To: References: Message-ID: Sam, Luke, In heimdal I use KRB5_PRINCIPAL_UNPARSE_NO_REALM for the logon name, and not SHORT name. That said, I think the logon name needs to be passed in and later verified by the caller/plugin/something other than the KDC since the KDC doesn't have enough information about that the Windows LOGON name actually is. Love