> -----Original Message----- > From: Emu <emu-boun...@ietf.org> On Behalf Of Cappalli, Tim (Aruba > Security) > Sent: Wednesday, November 14, 2018 6:49 AM > To: Alan DeKok <al...@deployingradius.com> > Cc: emu@ietf.org; John Mattsson <john.matts...@ericsson.com> > Subject: Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap- > tls13-03.txt > > 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 "anonym...@enterprise.co" 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.
My first response to this would be - what happens as an attacker I supply one name in the outer and validate using a different (and correct) inner name. This is going to make the administrator's life miserable since they are going to be looking at the wrong name and not have any ability to recognize that that is the problem. Jim > > tim > > On 11/14/18, 8:38 AM, "Alan DeKok" <al...@deployingradius.com> wrote: > > > > 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
