We're closer. On Wed, May 13, 2015 at 07:10:10PM +0200, Jakob Bohm wrote: > On 13/05/2015 17:46, Nico Williams wrote: > >On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote: > >>On 12/05/2015 21:45, Nico Williams wrote: > >>>On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote: > >>>>How about the following simplifications for the new > >>>>extension, lets call it "GSS-2" (at least in this e-mail). > >>>> > >>>>1. GSS (including SASL/GS2) is always done via the SPNego > >>>>GSS mechanism, which provides standard handling of > >>>>mechanism negotiation (including round-trip optimizations), > >>>>and is already its own standard (complete with workarounds > >>>>for historic bugs in the dominant implementation...). > >>> > >>>SASL/GS2 and SPNEGO are incompatible. > >> > >>How? I thought SPNEGO encapsulated and negotiated > >>arbitrary GSS mechanisms. > > > >The problem is that negotiating twice is bad (for various reasons), and > >SASL has non-GSS mechanisms, so negotiating SASL mechanisms, then GSS is > >a two-level negotiation that is fraught with peril, therefore forbidden. > > Ok, having not studied the standard SASL in GSS > specification, I presumed each GSS-encapsulated SASL > mechanism would have its own GSS mechanism OID in > some systematic way, leaving just one negotiation. SASL/GS2 is the other way around: GSS in SASL. The idea is that you can have GSS as SASL mechanisms in a way that sucks less than the original GSS-in-SASL bridge in RFC2222 (that added an extra round-trip), and which makes it easy to add mechanisms like SCRAM as both, a GSS and a SASL mechanism. I'm perfectly happy to drop SASL though. > >>To me the key benefit of SPNEGO is the existence of > >>already battle tested negotiation code readily available > >>i many/most current GSS implementation. It is one less > >>thing to design and implement wrong. > > > >It's quite complex owing to having been underspecified in the first > >place then having grown a number of bug workarounds over the years. > > Yes, but it is now a mature protocol, and I was trying > to avoid creating yet another near identical > handshake protocol. The only complication in a negotiation mechanism is protecting the negotiation. Since the TLS handshakes are ultimately integrity- protected, there's no complication at all to having the client send a list of mechanisms and the server pick one (the client can even send an optimistic choice's initial context token). In fact, it's much nicer than SPNEGO in many ways; if at all possible one should avoid SPNEGO. Among other things, not using SPNEGO means that it will be much easier to implement this protocol without extensions to GSS (extensions would be needed only to optimize it). > >In your protocol the client already sent a SPNEGO initial security > >context token. A response is required, as GSS context establishment > >token exchanges are strictly synchronous. > > As written, I had forgotten about the "Finished" > messages. Thus the point wasto simply delay the > server GSS response (2. GSS leg) to just after > switching onthe encryption, later in the same > round of messages. The 3. leg (second client to > server "GSS token") would then follow etc. We could extend GSS (see below) to support late channel binding, but since a mechanism might not be able to do it, this protocol would have to fall back on MIC tokens to complete the channel binding, in some cases at a cost of one more round trip. > >With PROT_READY there should be no need for an extra round-trip. > > Depends a lot on the mechanism. Some GSS mechanisms > (other than Kerberos IV/V) cannot use their MIC until > they have received a later token from the other end, > but can incorporate binding data earlier than that. I > think GSS-SRP-6a has that property. Kerberos in particular supports PROT_READY. There is no Kerberos IV GSS mechanism, FYI. I'd never heard of GSS-SRP-6a; do you have a reference? > >>>>6. If the GSS mechanism preferred by the client requires the > >>>>authenticated hash value to be known before sending the > >>>>first GSS leg, then the client shall simply abstain from > >>>>including that first leg in the first leg SPNego message > >>>>if sent in the client hello extension. > >>>If we're doing a MIC exchange then we don't need to know the channel > >>>binding a initial security context token production time. > >>However the early channel binding might save a leg. > > > >You mean late. Your idea seems to be to exposed knowledge of when is > >the latest that a mechanism can begin to use the channel binding so as > >to delay giving it the channel binding until we know it. That would be > >a significant change to GSS, and often it won't help (e.g., Kerberos, > >the mechanism of interest in this thread). > > The idea would be if an implementation (not the protocol > extension specification as such) is blessed with a > non-standard GSS option to provide the channel binding > after the 1. leg, but not with the early MIC use ability > of Kerberos, the the protocol extension should not prevent > it from taking advantage of this to do the channel binding > before the 2. leg, rather than after the n-th leg. If we finish the channel binding state flag extension we can support late channel binding. The application would provide channel bindings late and the mechanism would indicate the channel binding status, and if it couldn't do it then the application would have to fall back on MIC tokens. Where PROT_READY is indicated early the fallback MIC token exchange never costs extra round trips. For 2- and 3-token mechanisms the MIC token exchange also never costs additional round trips regardless of PROT_READY or late channel binding support. For some imaginable mechanisms there is nothing we could do to avoid an extra round trip, but most likely they will never exist. > >>However if the first leg need not be encrypted and > >>need not know thechannel binding, it can be sent a > >>round earlier. This can (I hope) be decided on a per > >>mechanism basis, thus if a GSS mechanism need not know > >>its channel binding until the second leg, > >>implementations that can provide the binding to the > >>GSS layer later can take advantage of it. > > > >No, this can't be decided on a per-mechanism basis, not without first > >modifying GSS significantly. > > The need to encrypt the first leg for privacy (e.g. to > hide the user id) would bea protocol property which > the application could know from standards (no extra > GSS calls or flags needed). E.g. "Mechanism FOO reveals > semi-sensitive information to passive observers of leg1, > but Mechanism BAR does not". As a local matter, this can > even change during the lifetime of the protocol as new > attacks on mechanisms are discovered. An overly > conservative implementation could pretend that all > mechanisms need encryption, an overly optimistic > implementation could pretend that none do. Yes, though if the mechanism was not going to expose the client's identity in the first context token... but yes, this is much better left as an application decision not based on knowledge of the mechanism. > The lack of need to know the channel binding early can > be determined from either: > - A local or global decision to use the MIC technique > for this mechanism. > - Site local availability of extra GSS calls or flags > to provide channel binding later forsome mechanisms. Right. > >>For security it is best if successful authentication > >>of an unauthorized account (thinkroot) is > >>indistinguishable from unsuccessful authentication of > >>that account. > > > >With GSS that's not really true. The mechanism token exchange is a > >black box. It may yield failure with error tokens. The application can > >detect this and elect not to send error tokens, but if a final token was > >expected in the success case then the peer will know what happened > >anyways. It's very difficult to generically ensure what you propose, > >and not that valuable. > > Like other per mechanism properties, this can be simply > tabulated as: > > "for mechanism X, check the authorization before sending > the 2. GSS token and simulate failure using call sequence > A" > "for mechanism Y, check the authorization before sending > the 1. GSS token and simulate failure using call sequence > A" > "for mechanism Z, check the authorization before sending > the 2. GSS token and simulate failure using call sequence > B" > > All done opaquely, but with knowledge of where to put > the "square" black boxes versus the "round" black boxes. I don't think this works as well as you think, and I see very little value in it. For Kerberos this means sending a bogus KRB-ERROR on authorization failure which will confuse the user if there was an error they could have dealt with, or which will not confuse anyone because it will be obvious that this means "authorization denied", so might as well have sent an authorization denied message instead. It would be much easier instead to let the application define its own authorization status message (if it needs one at all) and send it (or shut the door, or provide bogus content, or...) as it pleases. Nico --
