> -----Original Message----- > From: Sam Hartman [mailto:[email protected]] > Sent: Friday, April 29, 2011 4:04 AM > To: Jim Schaad > Cc: [email protected]; 'Eliot Lear' > Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 > > >>>>> "Jim" == Jim Schaad <[email protected]> writes: > > > It's absolutely critical for mutual authentication that we have EAP channel > binding. That goes between the peer/initiator/subject and the IDP/EAP > server. > That is independent of GSS channel binding which goes between the > initiator/subject/peer and the RP/acceptor. > > > > Jim> Jim> Since we don't have the channel binding data for the IdP to > Jim> compare unless the channel is going to produce it. There is no > Jim> channel binding data from the GSS-EAP mechanism until the MSK > Jim> is created. This would not be an issue if we were comparing > Jim> text names, but then we have the issue of the difference > Jim> between the DNS name used by the client and the AAAA realm name > Jim> used by the RP. > > > OK, so we also have confusion about channels. EAP channel binding > describes properties of the EAP lower layer--in our case the GSS exchange. > The attributes we care about with regard to this channel are (at least so far) > the acceptor name. > > The other channel, over which we apply GSS channel binding, is between the > subject and RP. That's the channel that might be TLS. There', the attributes > we care about are things like the server certificate or the hash of the finish > messages. > > GSS and EAP channel binding are even more different than is implied so far. > It's not just that the channel is different and the attributes we're talking > about are different. GSS channel binding is intended to detect a man-in-the- > middle attack. EAP channel binding does make sure that both ends of a > connection have a consistent idea of naming. > However it's not really about detecting man in the middle attacks, but more > about maintaining consistency in a complex multi-party system. > > Continual apologies for the terminology confusion. The EAP and GSS > communities independently came up with the term channel binding and > didn't realize the conflict until it was well established in both communities. > > --Sam
I think that I am getting some of the terms straight. What I think I have problems with is the requirements and points at which things occur. 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. The channel binding material is provided by any certificates and the final message (i.e. a cryptographic token for the channel). This will normally be either a one-way authentication of identity (i.e. the client knows who the RP is) or a zero-way authentication of identity (i.e. anonymous on both sides). It could be a mutual authentication, but in that case there would be no reason to involve the entire abfab architecture except potentially for assignment of privileges. 2. Client to RP GSS-API channel - This is slightly weird to think of as a 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 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. 3. RP to IdP channel - This is the weakest of the communication channels in terms of authentication and security. Most of these hops are going to be point-to-point and anybody in the middle can play with the data that is being transferred in either direction. The base architecture is responsible for providing any authentication assurances between the RP and the IdP. All authentication is fully established prior to the EAP conversation between the client and the IdP. 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. 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. Jim _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
