On Nov 21, 2018, at 10:36 AM, Dr. Pala <direc...@openca.org> wrote: > > 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).
Which attribute was that? > 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). I would suggest the following requirements: * it is useful to track the authenticated user * it would be good to keep user privacy while doing this (i.e. *not* exposing the inner identity) * using anything *other* than the NAI format for tracking will break many things For example, we have a user who logs with anonymous identity as "@example.com", and real identity as "b...@example.com". We then require that any anonymised "tracking" identity MUST be within the domain of example.com. The reason is that the User-Name sent in Access-Accept will be used for subsequent accounting packets. In a roaming environment, these accounting packets MUST be routable to the same destination as was used for authentication. We are then left with making recommendations for NAIs that are within the namespace of a particular domain. i.e. telling "example.com" what they should or should not use for these anonymous identities. RFC 7542 was *very* careful in not making such recommendations. It's just too hard to make recommendations that everyone can accept, much less use. To throw out an idea, IMHO the only safe recommendation is to use the MAC address of the device as the users anonymized "identity". The MAC address is already public to participants in EAP / RADIUS (via Calling-Station-Id). It's already globally unique (via IEEE requirements). So it would seem to not only work, but satisfy the requirements I noted above. Using the MAC address doesn't help in the situation that Tim Cappalli noted. But we care less about privacy within an enterprise environment. Those situations can just expose the inner identity, and be done with it. So we're left with recommending "MAC-ADDRESS@realm". Maybe also recommending "MAC-ADDRESS@anonymous.realm". in order to separate the namespaces of "real" identities, and "anonymized" identities. Comments? Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
