As has been pointed out a couple of times. I should not assuming that the channel I was describing in 1 (client to RP) is going to be TLS either. It could be something w/o security.
Jim > -----Original Message----- > From: Nico Williams [mailto:[email protected]] > Sent: Sunday, December 11, 2011 5:22 PM > To: abfab issue tracker > Cc: [email protected]; [email protected]; > [email protected] > Subject: Re: [abfab] #29: More explicity discussions of the communication > channels with the end-points, cryptography and channel binding > > On Sat, Dec 10, 2011 at 9:31 PM, abfab issue tracker > <[email protected]> wrote: > > The following is a list of the "channels" that I believe exist in the > > current abfab architecture (Please forgive the names that I am using > > as they are made up on the spot): > > > > 1. Client to RP transport channel - This would be the TLS channel > > that exists between the client and the RP. [...] > > > 2. Client to RP GSS-API channel - This is slightly weird to think of > > as a > > While the GSS-API "security context" (GSS term) is indeed a channel just as > much as TLS is a channel, it is best to think of GSS-API w/ channel binding as > an extension to TLS. > > Suppose we were to propose extensions to TLS that provide us with > federated mutual authentication and an attribute-based authorization > model. It'd be hard enough to get consensus for such extensions to TLS, but > then to get those extensions implemented by all the major TLS > implementations would take a long time. > > Then consider that a common design for channels that provide > authentication is to separate key exchange from authentication but then > bind them (e.g., SSHv2, client certs in TLS, ...). > > By using GSS and channel binding we achieve almost exactly what could have > been a TLS extension, and we do it in much the same sort of way that we > might have done it as a TLS extension: separate authentication from key > exchange, then bind the two so that the exchanged keys "speak for" the > authenticated entities. > > Also, the GSS channel is thrown away as soon as we're done with setting it up > and doing the channel binding operation. Before channel binding we had > applications like IMAP and LDAP where there was the option to use *two* > channels (TLS and GSS, with GSS being a channel proper when its per- > message protection facilities were used). Using two channels, one inside the > other, is quite wasteful, both in terms of runtime resources (double the > crypto) and software engineering (since it complicates application > architecture and requires more code). Worse, there may be no way for the > application to securely negotiate among authentication options when using > the old SASL/GSSAPI bridge without ending up with nested channels in some > cases. This is one critical reason that we pursued SASL/GS2 to replace the > old > SASL/GSSAPI bridge. > > Long story short: better to think of GSS w/ CB to TLS as an extension to TLS. > > > channel as it is going to be a channel between the requestor and the > > acceptor, but the keying material is provided by a "third party" to > > both entities. (My understanding is that the client can derive this > > material > > This depends on the mechanism. Some GSS mechanisms involve a third > party and some don't. Federated authentication involves third parties by > definition. (Yes, this is a nit.) > > > on its own, but the RP gets the material from the IdP.) There is no > > cryptographic binding on this channel until the EAP processing has > > totally finished and the MSK is transferred from the IdP to the RP - > > i.e. after the client/IdP authentication has completed. > > I'm not sure what you're getting at with this. A round-trip optimization > issue? > > > 4. Client to IdP - This is the EAP channel. It has the strongest > > mutual authentication between that exists. We have stated that the > > IdP is responsible during this processing to determine that the RP > > that is communication to the client over channel #3 (Rp to IdP) and > > the one talking between the client the RP (channel #1?) are going to > > be the same entity as the client provides the IdP it's version of the > > RP name during the EAP conversation. Thus it needs to reconcile the > > name forms between channel #1 and channel #3 during this authentication > process. > > We should not care at all about reconciliation of the RP names from channels > #1 and #3. Whenever the GSS mechanism provides acceptable > authentication of the RP to the client we can simply ignore the RP name from > TLS. And if the GSS mechanism does not provide authentication of the RP to > the client then we have no real channel binding, and no need to reconcile RP > names anyways. > > > At this point channel #2 and channel #4 are known to have > > cryptographic protections. Channel #1 and channel #3 may or may not > > have cryptographic protections. We need to specify what level of > > services are provided in these channels and how important those services > are. > > Channel #1 (TLS) is always going to be providing cryptographic protection > (end-to-end) for client<->RP communications. Channel #1 may not provide > any authentication -- is that what you meant? > > > ** > > > > It was followed up by a couple of notes by sam, myself and nico. I > > believe that the outcome was that we should get a clear discription > > of the different communication channels, the set of cryptographic > > operations/keys offered by each, and the channel binding opertions > > (type of binding and what it accomplishes) for each channel would be > useful. > > I agree. The picture is relatively simple if viewed as follows: we have a) > TLS > providing session services, b) GSS providing client<->RP mutual > authentication, and with channel binding to TLS it's almost as if GSS were > part > of TLS, c) the specific GSS mechanism in our case provides authentication by > way of one or more third parties. (a) is really entirely optional for > applications, except that we expect it to be part of every application > protocol > that hews to this architecture, thus (a) is not optional to the architecture, > but > because (a) and everything we need for exists already, there's nothing to do > to make it feasible. > > Nico > -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
