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
