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@lists.freeradius.org [mailto:freeradius-users-bounces+davidp=wirelessconnections.net@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@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@freeradius.org> FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

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@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@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@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=diamond.ac.uk@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@lists.freeradius freeradius-users-bounces+.org [mailto:freeradius-users-bounces+davidp=wirelessconnections.net@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@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@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