IP-Address

[Alan DeKok]

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:
> 
> http://www.nicklowe.org/2013/08/nps-class-attribute-bug/

  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.