This message had my response in the wrong place. I was responding to Tim's comments and not to Alan's comments. I completely agree with Alan that this information needs to be fed back to the NAS and not rely on what the client starts out saying.
> -----Original Message----- > From: Emu <emu-boun...@ietf.org> On Behalf Of Jim Schaad > Sent: Wednesday, November 14, 2018 10:35 AM > To: 'Cappalli, Tim (Aruba Security)' <t...@hpe.com>; '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 > > > > > -----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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
