[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADIUS User-Name versus EAP Identity
RFC 3579 Section 2.1 states:
In order to permit non-EAP aware RADIUS proxies to forward the
Access-Request packet, if the NAS initially sends an
EAP-Request/Identity message to the peer, the NAS MUST copy the
contents of the Type-Data field of the EAP-Response/Identity received
from the peer into the User-Name attribute and MUST include the
Type-Data field of the EAP-Response/Identity in the User-Name
attribute in every subsequent Access-Request.
So RFC 3579 does require the User-Name field and EAP-Response/Identity
fields to be identical at the NAS originating the Access-Request.
However, after that it is possible that RADIUS proxies will modify the
User-Name attribute, so that by the time the RADIUS Access-Request
arrives at the RADIUS server, the EAP-Response/Identity and User-Name
Attribute will no longer match. For example, the initial
EAP-Response/Identity could have included NAI source-routing which was
subsequently stripped off. For example, the EAP-Response/Identity
might have been firstname.lastname@example.org; by the time
this arrives at the RADIUS server, the example.com proxy will have
transformed it into email@example.com within the User-Name
Attribute, although the contents of the EAP-Message/EAP-Response/Identity
Attribute will have remained firstname.lastname@example.org.
The RADIUS server determines how to proceed with the authentication
based on the User-Name attribute, rather than the EAP-Response/Identity.
Unless the EAP method somehow incorporates the EAP-Response/Identity into
its calculations, there might not even be reason for the EAP method to
examine it (as opposed to say, the method-specific Peer-Id). For
example, RFC 3748 Section 5.1 states:
It is RECOMMENDED that the Identity Response be used primarily for
routing purposes and selecting which EAP method to use. EAP
Methods SHOULD include a method-specific mechanism for obtaining
the identity, so that they do not have to rely on the Identity
Response. Identity Requests and Responses are sent in cleartext,
so an attacker may snoop on the identity, or even modify or spoof
identity exchanges. To address these threats, it is preferable
for an EAP method to include an identity exchange that supports
per-packet authentication, integrity and replay protection, and
confidentiality. The Identity Response may not be the appropriate
identity for the method; it may have been truncated or obfuscated
so as to provide privacy, or it may have been decorated for
routing purposes. Where the peer is configured to only accept
authentication methods supporting protected identity exchanges,
the peer MAY provide an abbreviated Identity Response (such as
omitting the peer-name portion of the NAI [RFC2486]). For further
discussion of identity protection, see Section 7.3.
My understanding is that the WMF v1.0 specification does include some
unique (e.g. non RFC 4282) User-Name mangling. However, I don't recall
any mangling of the EAP-Response/Identity.
From: Alan DeKok [mailto:email@example.com]
Sent: Monday, October 13, 2008 8:44 AM
To: Bernard Aboba
Subject: RADIUS User-Name versus EAP Identity
RFC 3579 doesn't require these two fields to be the same, so far as I
can tell. Yet every AAA server I've checked (tested and/or asked
around) requires that these fields *are* the same.
Does this make sense? Is it an issue with existing implementations?
The question has come up because of issues with RADIUS routing &&
proxying. The traditional dial-up prefix/suffix mangling && editing
doesn't work for EAP. It defines edits for the User-Name, not for EAP
identity. And then the fields differ...
Some people I've talked to say that the WiMAX NWG requires User-Name
mangling, *and* that it also requires similar edits to be done to the
EAP Identity. But I can't find that in the 400+ pages of NWG
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.