RE: RADIUS User-Name versus EAP Identity

["Bernard Aboba" <Bernard_Aboba@hotmail.com>]

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 deployingradius.com!aland@example.com; by the time
this arrives at the RADIUS server, the example.com proxy will have
transformed it into aland@deployingradius.com within the User-Name
Attribute, although the contents of the EAP-Message/EAP-Response/Identity
Attribute will have remained deployingradius.com!aland@example.com. 

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. 


-----Original Message-----
From: Alan DeKok [mailto:aland@deployingradius.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
specifications.

  Comments?

  Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>