The question was asked about making it anonymous NAI mandatory in the Identity Response. That is what my comments were targeted to.
In terms of infrastructure, logging into a wireless controller, switch or NMS and seeing hundreds of "[email protected]" makes an administrator's life miserable. Most folks in a large enterprise responsible for troubleshooting end user access do not have access to the EAP server. The only way to provide the real identity back to the NAS would be sending it back as the IETF User-Name in the Access-Accept with the assumption that the NAS would honor it. tim On 11/14/18, 8:38 AM, "Alan DeKok" <[email protected]> wrote: On Nov 14, 2018, at 8:16 AM, Cappalli, Tim (Aruba Security) <[email protected]> wrote: > > Making it mandatory to use an anonymous NAI will be a huge issue in enterprise where the infrastructure, device and enterprise identity is owned by the enterprise. There is no proxy or third party provider. I don't see that in Section 2.1.4. It says: ... a client supporting TLS 1.3 MUST NOT send its username in cleartext in the Identity Response. It is RECOMMENDED to use anonymous NAIs, but other solutions where the username is encrypted MAY be used. So username *hiding* his mandatory. But the method is left to the implementation. > Seeing "[email protected]" across all network infrastructure is not going to be acceptable. In what context will you "see" that across all network infrastructure? Since this is the enterprise, you control your own RADIUS server. You can associate the *inner* identity with the users session. There is no requirement that you only look at the outer identity for tracking user sessions. This tying of inner / outer identities is common in ISP and enterprise environments. In the absence of specific reasons behind this statement, I just don't see how anonymous identities are a problem for anyone, anywhere. If I had to guess, I'd say that the problem comes from *other* devices on the network. Devices that snoop EAP, but aren't involved in the actual authentication. The solution there would be to have the local RADIUS server talk to the local snooping device. Or, the local snooping device looks at MAC addresses instead of EAP identities. And then uses the RADIUS DB to correlate MAC address to EAP inner identity. > Why not provide a flag that can be passed in the EAP exchange from the supplicant that enables this behavior so users with full control of their device can use this while enterprise or other use cases that require real identity can configure the supplicant to provide a different flag? Given the horrific nature of implementations and inter-operability, I would oppose yet another point of negotiation. It does not add anything IMHO. And, it makes implementations and inter-operability more complex. Alan DeKok.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
