IP-Address

[Nick Lowe]

>   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!