Hi all,in other environment we had to add the attribute about which ID was actually authenticated in the final messages because of additional operations that some network equipment needs to perform that requires the identity of the supplicant to be disclosed (exactly to avoid the use of an external identity and different credentials when authenticating).
I just want to point out the obvious - this is a sub-case of the anonymous NAI format. If there is any consensus in mandating for that format/identity then we need to mandate that the authenticated identity is carried in the accept/success message (which could still be the anonymous NAI format if the system allows that to be a valid identity value).
Does that make sense ? Cheers, Max On 11/14/18 2:29 PM, Jim Schaad wrote:
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 theEAP 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. Jimtim 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 adifferent 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
-- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
