I propose to add a new section which discusses identities. As background, an (un-named) vendor recently made changes to their EAP stack. The configuration for TTLS/PEAP now takes the external (anonymous) identity, and uses that as the inner identity.
i.e. instead of sending "@example.com" for the outer identity, and "myname" for the inner one, it just sends "@example.com" for both. Perhaps unsurprisingly, this causes authentication to fail. The work-around is to reconfigure the supplicant so that the outer identity is the "real" one. This has privacy implications, as the inner identity is now being exposed. I'm proposing new text which explains some basic ideas about identities, and what should/should not be done. I don't think that these proposals are controversial, but they are perhaps surprising to some implementors. Identities ------------ [EAPTLS] Sections 2.1.3 and 2.1.7 recommend the use of anonymous NAIs [RFC7542] in the EAP Identity Response packet. However, as EAP-TLS does not send application data inside of the TLS tunnel, that specification does not address the subject of "inner" identities in tunneled EAP methods. This subject, however, must be addressed for the tunneled methods. Using an anonymous NAI has two benefits. First, an anonymous identity makes it more difficult to track users. Second, an NAI allows the EAP session to be routed in an AAA framework. For the purposes of tunneled EAP methods, we can therefore view the outer TLS layer as being mainly a secure transport layer. That transport layer is responsible for getting the actual (inner) authentication credentials securely from the EAP peer to the EAP server. As the outer identity is simply an anonymous routing identifier, there is little reason for it to be the same as the inner identity. We therefore have a few recommendations on the inner identity, and its relationship to the outer identity. For the purpose of this section, we define the inner identity as the identification information carried inside of the tls tunnel. For PEAP, that identity may be an EAP Response Identity. For TTLS, it may be the User-Name attribute. Implementations MUST not use anonymous identities for the inner identity. If anonymous network access is desired, eap peers MUST use EAP-TLS without peer authentication, as per [EAPTLS] section 2.1.5. EAP servers MUST cause authentication to fail if an EAP peer uses an anonymous identity. Implementations SHOULD NOT use inner identies which contain an NAI realm. The outer identity contains an NAI realm, which ensures that the inner authentication method is routed to the correct destination. As such, any NAI realm in the inner identity is redundant and unnecessary. However, if the inner identity does contain an NAI realm, that realm MUST be identical to the outer identity NAI realm. There is no reason for these realms to be anything other than bit-for-bit identical. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
