Subject: [radext] Basic question about user-name attribute

From: Fadi Bushnaq <[email-masked]>
Date: Sat, 10 Nov 2018 11:36:19 +0100

I hope this is the right place to post such questions

>From RFC 2865 section 5.1, user-name MUST be sent in access-request packets
and MAY be sent in access-accept.

The question is, in case it is decided to include this attribute in the
access-accept packet, does it have to be identical to the value received in
the access-request relative to the same session or can it be different?

Any reference to where this is documented would be highly appreciated.

Thanks.
Fadi

---

From: Alan DeKok <[email-masked]>
Date: Sat, 10 Nov 2018 14:07:02 -0500

> I hope this is the right place to post such questions

  Yes.

> From RFC 2865 section 5.1, user-name MUST be sent in access-request packets and MAY be sent in access-accept.
> 
> The question is, in case it is decided to include this attribute in the access-accept packet, does it have to be identical to the value received in the access-request relative to the same session or can it be different?

  I suspect that the intention was for the values to be identical.  Since the RFC doesn't say that, they're allowed to be different.

  In practice, people do send Access-Accepts where the User-Name is different than the one in the Access-Request.

> Any reference to where this is documented would be highly appreciated.

  If it's not in the RFCs, it's not documented anywhere.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 12 Nov 2018 13:19:55 +0100

Hello,

>   In practice, people do send Access-Accepts where the User-Name is different than the one in the Access-Request.

This is especially relevant for EAP authentications. The User-Name in
the request could be an identifier supporting identity privacy
("anonymous@realm", "@realm", etc.), while the actual username inside
the EAP method is different from that.

It sometimes happens that RADIUS administrators are rude to their users
in that they send back the actual username in the Accept while the user
was trying to maintain his privacy when connecting.

>From what I've seen in the field, this is sometimes used in interplay
with Accounting-Request: if the session that was being authenticated
contains a User-Name in the Accept, that User-Name is sometimes used as
the User-Name for subsequent Accounting-Requests for the same session.

Nothing in the RFCs forbids either of these practices.

Greetings,

Stefan Winter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 12 Nov 2018 07:30:51 -0500

> was trying to maintain his privacy when connecting.

  That happens a lot, unfortunately.  The reality is that it's just too useful in most situations to have a "real" name for the users session.

  The Chargeable-User-Identifier was created to address that issue.  But most NASes don't support it.

> the User-Name for subsequent Accounting-Requests for the same session.

  That is the behaviour suggested by RFC 2865 Section 5.1, about User-Name

      It MAY be sent in an Access-Accept packet, in which case the
      client SHOULD use the name returned in the Access-Accept packet in
      all Accounting-Request packets for this session.

  Without that practice, EAP would have users log in with anonymized User-Names, and then all of the Accounting-Request packets would contain the same anonymized User-Name.  Since most wireless NASes set "NAS-Port = 0", it becomes difficult to distinguish user sessions from one another.

  In hindsight, what RADIUS *should* have supported was the ability for the server to send an Acct-Session-Id in the Access-Accept.  The NAS could then use that in subsequent accounting packets.  Anonymity would be preserved, *and* servers wouldn't have to deal with broken NASes that re-use Acct-Session-Id after a reboot.

  I suppose a similar approach could be taken with the User-Name attribute.  But doing so would take not changing not only the server software, but changing databases and business practices by the administrators.  That's a difficult proposition.

> Nothing in the RFCs forbids either of these practices.

  The text in RFC 2865 *could* be interpreted to mean that the User-Name in Access-Accept can be anything.  i.e. unrelated to the User-Name in the Access-Request.

  Alan DeKok.