On 18/04/13 16:06, Nick Lowe wrote:

Thanks, Alan!

I have got a feature request with Aerohive, our wireless vendor, to support treating the User-Name AVP as being authoritative which they are being pretty receptive and responsive to.

(I think RADIUS clients need to stop treating the outer identity as being authoritative if and where a User-Name is returned in the Access-Accept now that TLS based EAPs are the norm and we should have far more of an aggressive push to get vendors to implement this.)

IME it's fairly widely supported (but not exclusively, of course)

It would be great if, rather than manually having to create mappings and rewrite the identity, having successfully performed authentication FreeRADIUS were able to inherently spit out the identity in a normalised form knowing the username and the realm. (Perhaps I am not thinking things through here properly though for the general case though...)

I think the problem is that there's no generally "right" answer. For example: if you are part of a roaming federation and your users use anonymous outer ID, you want to preserve that anonymity (or possibly fall foul of data protection legislation, depending on whether a username is "personal data").

Nick Lowe wrote: I would have thought that it is perfectly reasonable to return the identity back in the case you have roaming federations as long as it was an agreed requirement beforehand. I am of the opinion that this -should- be mandated as part of Eduroam, for example.

I'd have to disagree. We don't want to know anything about eduroam guest users other than an ID which to hand authorities which they can use to investigate with the home institution. The less we know, the less work we have to do when we get a subpoena.

On 18/04/13 16:59, Nick Lowe wrote:

That's a very fair point. A problem with anonymous identities though also comes where you have features at the edge that 'do things' based on the identity. Often you will just want an anonymised unique identity for each discrete user, but not necessarily their real identity.

Food for thought... Would there be a way to achieve this with federations that maintains anonymity?

Yes. This is what Charged-User-Identity is for. The server comes with examples for CUI. Sadly it's not widely supported :o(

So which id are you talking about? if its the outer and the user has configured the machine correctly, all you're going to see is @realm - not much use other than "it's that institution" if its the inner then o.k. you've got a realm from the outer user-name and a userid from the inner but any accounting will be dumped locally. if its the inner and you've got a realm then you've got your userid to hand over and all the accounting should go back to the home institution

… or have I got that wrong? Rgds A

I am primarily interested in returning the inner identity normalised as username@realm in the User-Name AVP in Access-Accepts for authentication performed internally so that the Aerohive APs we have are able to work with the real identity rather than the anonymous outer. This is important for us to get the new L7 application visibility features in HiveOS 6.0 working properly and have some value. Additionally, for internal authentication, users can get away with simply using username, realm\username or username@realm in the inner and, at present, the Aerohive APs treat the same user as being discrete users where the identity is supplied in a different format. I want to sort this somehow... (I am, however, loathed to mandate that the identity be supplied as username@realm to begin with as it will break existing configuration. This for authentication not on an eduroam SSID.) For eduroam in general, it would be far less of an issue as users are always forced to use the fully qualified username@realm (often anonymous@realm) but I would be interested in a method to get an anonymised unique id for the user from the home institution. (Is that personal data at that point? In the case of abuse, you would still have to go back to the home institution and know nothing about the user as you do not have their real identity.) Thinking about things, I think an appropriate compromise for Eduroam, therefore, would be to mandate the return an anonymised unique id with realm for each user in the User-Name AVP in the Access-Accept. Thoughts? Nick

I honestly don't see what the problem is with writing it yourself - it's not rocket science - but OTOH a set of examples in the default config would be a good thing too.

No problem at all, rather, I would have simply thought that it lowers the barrier to entry, requiring less concious thought on behalf of the person configuring the RADIUS server if it is an option that can just be toggled on and hey presto, it works. It also makes it more discoverable as desirable behaviour. In my limited scope testing, many NASes will ignore the User-Name attribute and making more of a first class, default behaviour in the most popular RADIUS server might start to change that...

I would default the behaviour to not send the User-Name attribute in the Access-Accept but give the ability to have it trivially enabled with a toggle. And where it is enabled, by default, send it in the normalised user@realm format unless configured otherwise. (That would be the general case as far as I can see.)

Hi, in latest 2.x and 3.x code check out the canonicalisation policy - this sorts out the MAC format. you could do the same for the User-Name. note that there are data protection issues in play - for example, if a user has chosen (and is allowed) to use anonymous outerid, then why are you suddenly releasing their ID to the remote site after the 'soft innards' of the innerID are known to you? might the user have an issue with that? also note that the main issue that has been at play here is accounting packets - the innerID is not realmed so accounting becomes local. well, thats okay too as accounting traffic in eduroam is going bye bye in the not too distant future so you wont be proxying accounting through the national proxies anyway...so either take it locally or drop it. alan

As an aside to the mechanics of this, if you do this, test your NAS under simulated user load. We found that our Cisco WLC equipment didn't like that and leaked internal resources, which eventually ran out. We were adding some additional information to the username, so we had many more differences between the outer and inner IDs, and even so it took a few days for the problem to come to a head.

Interesting! Thanks for the heads up.

This should be fixed in latest software, but we haven't re-tested that yet.

It also wouldn't hurt to sniff the resulting EAPOL and any associated packets to ensure the NAS hasn't figured out some vendor-specific way to leak that inner identity to the wire/wifi, and of course review your security expectations between the AS and NAS.

Agreed, the main concern for me would be leakage via wireless. I see the main purpose of identity privacy with PKI EAPs being to protect the identity from being trivially snooped by an outsider. With federations, I think it would be perfectly reasonable to expect and require the real identity be returned back to the host institution. (I expect others will, perhaps, disagree here though!? :P) Nick

Eduroam visited ORPS and home server ORPS should support CUI. Where the NAS at the visited site lacks support for CUI, and the NAS supports setting values for attributes associated with a session, a globally and temporarily unique identifier should be set (via Access-Accept/COA/SNMP) and then associated with the CUI provided by the home server.

Some NAS include the Acct-Session-ID in Access-Requests, in which case the Acct-Session-ID can be associated with the CUI instead.

For support calls the ID on the NAS can be mapped to the CUI, which can in turn be provided to the home institution.

https://community.ja.net/blogs/scotts-eduroam-blog/article/eduroam-and-cui Aha, thanks! (Feels stupid...)