On Nov 14, 2018, at 8:16 AM, Cappalli, Tim (Aruba Security) <t...@hpe.com> 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 "anonym...@enterprise.com" 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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
