Nick Lowe wrote:
I have been having fun implementing a SSO framework for Microsoft's NPS (when used as the EAP terminating RADIUS server)... but the project is on hold while I pester Microsoft for hotfixes:
OK... some comments on that web page.
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.
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.
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.
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.
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.
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.
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. 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. Alan DeKok.