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
