On Sat, Feb 17, 2007 at 11:43:38PM -0800, Narayanan, Vidya wrote: > Yes, the problem of an authenticator providing different identities to > the peer and the server is the typical channel binding problem and can > be detected by simply doing a protected exchange of the identity between > the peer and server. When such a discrepancy is detected, then, keys > won't be handed out or if the identity is part of the key derivation, > then, it will result in a key mismatch anyway. Hence, there is no > problem there. > > In my understanding, Dan's claim is that the server is unable to detect > that an authenticator is claiming an incorrect identity and by virtue of > that, if the authenticator claims the false identity to both the peer > and the server, a key will be provided to the authenticator and that > will match the key that the peer derives, even if the identity was part > of the key derivation. This is the problem that I have detailed in my > earlier email and I belive that can be resolved with the text I > proposed. Yes, this is a problem that should not happen. If this happens, the peer may send out data that is specific to ISP2 to the lying authenticator (which is actually an ISP1 entity but claiming itself to be an ISP2 entity) that is not supposed to see the ISP2-specific data. Going back to your proposed text: "It is RECOMMENDED that the key transport protocol be able to detect impersonation. When it is not feasible to guarantee that, every key handed out from the server to an entity for a given peer MUST be different from every other key handed out for a given peer." I think that detection of impersonation is part of the "Authenticate all parties" *requirement* (not a recommendation). By the way, recent discussion on 3-party key distribution over HOKEY mailing list made me think more about the following text in Section 5 (I don't know whether this is part of Dan's comment as I did not see his original comment on this mailing list): " The authenticator is also a trusted party. The authenticator is trusted not to distribute keying material provided by the AAA server to any other parties. If the authenticator uses a key derivation function to derive additional keying material, the authenticator is trusted to distribute the derived keying material only to the appropriate party that is known to the peer, and no other party. When this approach is used, care must be taken to ensure that the resulting key management system meets all of the principles in this document, confirming that keys used to protect data are to be known only by the peer and authenticator. " I understand that the authenticator is a trusted party for the EAP/AAA server. On the other hand, I don't think we can say that it is a trusted party for the peer before running EAP, unless the link between the peer and the authenticator is already secured or the peer and the authenticator have already a shared key to believe before running EAP. Regards, Yoshihiro Ohba > > Regards, > Vidya > > > -----Original Message----- > > From: Lakshminath Dondeti [mailto:ldondeti@xxxxxxxxxxxx] > > Sent: Saturday, February 17, 2007 9:36 AM > > To: Sam Hartman > > Cc: Narayanan, Vidya; bernarda@xxxxxxxxxxxxx; Dan Harkins; > > ietf@xxxxxxxx > > Subject: Re: comments on draft-houseley-aaa-key-mgmt-07.txt > > > > Sam, > > > > The problem of an entity in the middle giving disparate > > information to the peer and the server is in fact easier to > > solve than the problem Vidya summarized. The disparate > > information problem has been described in the EAP Keying > > Framework document and elsewhere too. > > > > To my understanding, we are beyond that point in the > > discussion in HOKEY and considering the new case of the > > entity in the middle lying to both sides and attempting to > > get a key that another entity in the middle is supposed to get. > > > > Let me put it this way, both issues are considered problems > > to address/solve in this case. > > > > regards, > > Lakshminath > > > > Sam Hartman wrote: > > > Vidya, I found the model you proposed didn't fit what Dan > > was talking > > > about very well. In particular, Dan wants to focus on problems > > > resulting from the fact that the name of the authenticator used > > > between the peer and the authenticator may be different > > than the name > > > of the authenticator used between the authenticator and the AAA > > > server. That distinction did not figure prominently enough in your > > > argument that I could tell whether you and Dan are talking > > about the > > > same thing nor whether I could even tell if I agreed with you. I'd > > > recommend refocusing your model on this distinction; I > > think once you > > > do we may well make significant progress on discussing a > > long-standing > > > issue. > > > > > > --Sam > > > > > > > > > _______________________________________________ > > > Ietf mailing list > > > Ietf@xxxxxxxx > > > https://www1.ietf.org/mailman/listinfo/ietf > > > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf