OK... some comments on that web page.
Thanks very much for the comments Alan!
The format of the Class attribute that is generated by NPS is documented by Microsoft as follows:
That format is ridiculously complex, and serves no purpose. The Class should be just an opaque token. Any state should be maintained in a database. Having Class a complex structure means NPS is leaking private information to parties who have no business seeing it.
(Poor aspects of this format is that it is a predictable construction and is neither Base64 or UTF-8 encoded so therefore cannot be handled as text.
The Class attribute is an opaque binary blob. It is NOT text, and SHOULD NOT be treated as text by anyone.
Agreed, I am wrong here. I have revised the text in the blog post. I had meant purely from an ease of logging perspective, but then thinking about it, it should be the responsibility of whatever is logging to be able to handle it appropriately.
It is also not possible to reliably and securely correlate Authentication/Authorization to Accounting based on the value of the Calling-Station-Id in an Access-Request,
You don't correlate auth/acct based on Calling-Station-Id. You do it on Class, or on Acct-Session-Id.
I know, correlation of this nature was explored and dismissed only as a potential workaround in the full knowledge that it would be a hack, it was not viable. I have removed this from the text, however, as it serves no real purpose. Pragmatically, you cannot treat the Acct-Session-Id as being unique for a session in real world vendor heterogeneous environments, it is guaranteed to be unique only on a per-NAS basis and there is a theoretical risk of collision between vendors where they use a similar method of construction. I could not see any advice on its construction in the RADIUS RFCs? The Acct-Multi-Session-Id was meant to, and does, solve this surely? As some NASes will perform a fresh authentication and authorization exchange yet conceptually the user still has the same 'connection', I have supported roaming only where an Acct-Multi-Session-Id value is present and shouted at vendors where one has been missing and not used the Class attribute for this purpose.
It is possible for roaming to occur after a session has started from an Access-Accept sent by the RADIUS server yet before the first Accounting-Start has been received, which would change the key and make correlation impossible.
If the APs allow roaming from one AP to another without re-authentication, then the APs are responsible for ensuring that the Acct-Session-Id is constant across all APs for one session, OR that the Class attribute is constant across all APs for one session.
You CANNOT fix a broken AP in RADIUS. You can put band-aids on it, but nothing more.
I actually think use of the Acct-Multi-Session-Id is the correct solution here and there should be no requirement to persist the Acct-Session-Id.
Secondly, the User-Name attribute is sometimes rewritten in RADIUS proxying scenarios. This adds fragility where the authentication path is not fully controlled.
The User-Name attribute should not be re-written in proxying. This has historically been done, but it's a terrible idea. The new RFC (coming soon) which updates RFC 4282 says this.
Thirdly, not all NASes support processing the User-Name attribute where one is present in an Access-Accept packet so will continue to account with the EAP outer-identity.
Such NASes are unfortunately broken. They don't implement the RADIUS specs correctly. Sadly... there are many, many, NASes which don't implement RADIUS.
Should we make more of a concerted effort to call them out and open support cases over this?
it is necessary either that:
1. The EAP terminating RADIUS server returns the User-Name attribute with the client's real identity AND that the NASes support processing this attribute.
Which is a good idea. But as Arran pointed out, CUI is arguably the better choice.
Sure! Which NASes are you aware of that support the CUI attribute?
2. The EAP terminating RADIUS server else mandates that the EAP outer-identity and EAP inner-identity resolve to the same discrete user, prohibiting the use of anonymous EAP outer-identities.
That will NEVER happen. Never, never, never. It's a terrible idea.
Actually, I would have thought it can be a the better compromise choice in some deployment scenarios where experiencing identity spoofing in the dependent systems would be worse than breaking privacy. This happens where you have integrations that are not privy to anything but the User-Name attribute in RADIUS accounting packets.
From a defense in depth perspective, it would also be beneficial to have the ability on the EAP terminating RADIUS server to constrain the EAP outer-identity so that the user portion of the User-Name must have the value "anonymous" where it does not resolve to the same discrete user represented by the EAP inner-identity.
That is a good idea.
Add functionality to allow NPS to be configured to mandate that the EAP outer-identity and inner-identity must resolve to the same discrete user. (Disabled by default.)
I don't think that will ever happen. It's a very bad idea.
As above, it can be the best compromise choice when faced with identity spoofing vs privacy. I have updated the text to further push the idea that it is generally a bad idea.
I'll poke my contacts at Microsoft about this. I know the people in charge of NPS, which always helps. It won't help your support ticket, but getting it prioritized at a political layer may be good.
Thanks!