There are 3 parties in the AAA/EAP exchange. Not every party is authenticated in the exchange (e.g. the NAS/AAA client is not authenticated by the EAP peer) -- there is only key confirmation taking place.
The NAS can therefore report different identities to the EAP client and to the AAA server. To deal with this issue the solution of channel binding was proposed. There are, however, other solutions as well (theoretically at least). The impersation aspect that is described in Section 5.3.2 of http://tools.ietf.org/html/rfc5247 is a very different thing, namely the case where one authenticator impersonates another authenticator towards the AAA server. Since the identity reported within the channel binding solution is not related to the identity used for authenticating the AAA client to a AAA server (or to a proxy) the two aspects, as Bernard said, are unrelated. Ciao Hannes >-----Original Message----- >From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On >Behalf Of ext Qin Wu >Sent: 18 August, 2009 09:59 >To: Bernard Aboba; emu@ietf.org >Subject: Re: [Emu] Impersonation and Lying NAS problem: two >distinctissues (with different solutions) > >It seems to me, the consistency between EAP peer and EAP >Server can be caused by the Lying NAS Even this NAS is not >malicious authenticator who impersonates another >authenticator, this NAS should be a stupid NAS or >malfunctional NAS who make a mistake for some reason. Because >this NAS distributes inconsistent data to the peer and server >respectively. > >From this aspect, the lying NAS can be understoond as ill NAS. >am I right? >On the other hand, as described in the section 5.3.3, " >it is possible for a first-hop AAA proxy to detect a AAA >client attempting to impersonate another authenticator. >" >Based on this, impersonation issue seems to overlap with >channel binding or lying NAS issue. > >Regards! > >-Qin >----- Original Message ----- >From: "Bernard Aboba" <bernard_ab...@hotmail.com> >To: <emu@ietf.org> >Sent: Tuesday, August 18, 2009 1:42 PM >Subject: [Emu] Impersonation and Lying NAS problem: two >distinct issues (with different solutions) > > >> Dan Harkins said: >> >> "When there are 3 parties involved in this 2 party protocol it is >> justified by saying that the EAP server trusts the NAS so there is no >> security issue when MSK is disclosed to it. But what NAS >identity does >> the EAP server trust? The peer and EAP server derive a shared key and >> for the key to be disclosed to another entity the peer and EAP server >> must have a consistent view of the identity of that entity. >If they cannot >> arrive at a consistent view of all identities then the >protocol deriving >> the key fails. That is not an authorization issue, it's an >authentication >> issue." >> >> RFC 5247 Section 5.3.2 describes problems that can result from a NAS >> impersonating another NAS. Section 5.3.3 describes the Channel >> Binding problem, which is logically distinct. >> >> As noted in Section 5.3.2, it is not possible for a AAA server more >> than one hop from the NAS to verify the NAS Identity. This >verification >> must be handled at the first hop proxy. >> >> Given this, it will typically be outside the scope of a >Channel Binding >> Implementation to address the impersonation issue. >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
