Unlang clarification

[Nick Lowe]

When you are using a traditional EAP type, the identity seen in the
EAPOL exchange is authoritative and can be trusted.
(Returning a User-Name AVP in an Access-Accept is unnecessary in this
case unless it needs to be normalised or customised, and is optional
as part of the RADIUS RFCs.)

When you are using a modern tunnelled, TLS protected EAP type, such as
PEAP or TTLS, the identity seen in EAPOL is not authoritative.
Returning a User-Name AVP in an Access-Accept is therefore
semantically mandatory if the NAS is to accurately know the identity
of a connected client. If this is not a concern, it need not return
this. Sadly many NASs do not use the User-Name AVP if it is returned.

Any decisions that a NAS takes directly based on an identity or an
administrator makes looking at the active or historical session
information that a NAS, or its associated management system, presents
is subject to identity spoofing attacks and its associated
implications. The scope of this depends on the use case, of course.

If you have to drop the User-Name attribute in the Access-Accept for a
NAS to work, it is a bug in the NAS. If the NAS does not use the
User-Name AVP, it is deficiency of the NAS.

RFC 2865 states in Section 5.1:

[The User-Name AVP] 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.

RFC 3579 states in Section 3:

The User-Name attribute within the Access-Accept packet need not be
the same as the User-Name attribute in the Access-Request.

Nick

On Mon, May 20, 2013 at 3:46 PM,  <stefan.paetow at diamond.ac.uk> wrote:
> The real username in an EAP conversation is inside the encrypted EAP packets, i.e. inside an EAP-TLS tunnel. The one in plain-text is a throw-away one (often just @realm or anonymous at realm).
>
> I can only surmise that the update reply in this case wants to ensure that no User-Name attribute exists in the reply (which is fair enough, the reply shouldn't need to ship a username around in plain-text).
>
> Stefan
>
>
> -----Original Message-----
> From: freeradius-users-bounces+stefan.paetow=diamond.ac.uk at lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=diamond.ac.uk at lists.freeradius.org] On Behalf Of David Peterson
> Sent: 20 May 2013 15:30
> To: FreeRadius users mailing list
> Subject: RE: Unlang clarification
>
> Hmmm...strange.  Actually that code was in the post-auth reject sections and this is in the post-auth section:
>
> update reply {
>                 User-Name !* 0x00     #removes the User-name from the
> Access-acc
> ept
>         }
>
> Any thoughts as to why they would add these?
>
> David
>
> -----Original Message-----
> From:
> freeradius-users-bounces+davidp=wirelessconnections.net at lists.freeradius
> freeradius-users-bounces+.org
> [mailto:freeradius-users-bounces+davidp=wirelessconnections.net at lists.freera
> dius.org] On Behalf Of Arran Cudbard-Bell
> Sent: Monday, May 20, 2013 9:59 AM
> To: FreeRadius users mailing list
> Subject: Re: Unlang clarification
>
>
> On 20 May 2013, at 09:34, "David Peterson" <davidp at wirelessconnections.net>
> wrote:
>
>> I am fighting a buggy NAS and was told to add to the
> /sites-enabled/default file in the post-auth section this code:
>>
>>                       EAP-Message = "0x04040004"
>>                          User-Name !* 0x00
>>                          Message-Authenticator =
> "%{Message-Authenticator}"
>>
>> Can someone clarify what this would actually do to the EAP response?
>
> You mean:
>
> update reply {
>         EAP-Message = "0x04040004"
>         ...
> }
>
> You'd be forcing the server to send an EAP-Failure message, with a static and probably incorrect ID. Removing any instances of User-Name from the reply, and setting an invalid value for the message authenticator which would be overwritten anyway.
>
> -Arran
>
> Arran Cudbard-Bell <a.cudbardb at freeradius.org> FreeRADIUS Development Team
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
> --
> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>
>
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html