[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: RADIUS User-Name versus EAP Identity



> 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.

  This is causing problems in real-world pre-deployment systems.

  Maybe a solution would be to require that implementations ignore the
contents of the EAP-Response/Identity field.

[BA] Yes, in most cases the implementation should use the RADIUS
User-Name Attribute instead.  There might be a few cases where the
EAP method calculations depend on the EAP-Response/Identity
(RFC 3748-defined methods such as EAP-MD5).  Are you seeing problems
only with those methods, or with other ones as well?

BTW, RFC 5113 Section 2.3 does talk a bit about this issue:

   As noted in [RFC4284], it is also possible to utilize an NAI for the
   purposes of source routing.  In this case, the client provides
   guidance to the AAA infrastructure as to how it would like the access
   request to be routed.  An NAI including source-routing information is
   said to be "decorated"; the decoration format is defined in
   [RFC4282].

   When decoration is utilized, the EAP peer provides the decorated NAI
   within the EAP-Response/Identity, and as described in [RFC3579], the
   NAS copies the decorated NAI included in the EAP-Response/Identity
   into the User-Name attribute included within the access request.  As
   the access request transits the roaming relationship path, AAA
   proxies determine the next hop based on the realm included within the
   User-Name attribute, in the process, successively removing decoration
   from the NAI included in the User-Name attribute.  In contrast, the
   decorated NAI included within the EAP-Response/Identity encapsulated
   in the access request remains untouched.  As a result, when the
   access request arrives at the AAA home server, the decorated NAI
   included in the EAP-Response/Identity may differ from the NAI
   included in the User-Name attribute (which may have some or all of
   the decoration removed).  For the purpose of identity verification,
   the EAP server utilizes the NAI in the User-Name attribute, rather
   than the NAI in the EAP-Response/Identity.

   Over the long term, it is expected that the need for NAI "decoration"
   and source routing will disappear.  This is somewhat analogous to the
   evolution of email delivery.  Prior to the widespread proliferation
   of the Internet, it was necessary to gateway between SMTP-based mail
   systems and alternative delivery technologies, such as Unix-to-Unix
   CoPy Protocol (UUCP) and FidoNet.  Prior to the implementation of
   email gateways utilizing MX RR routing, email address-based source-
   routing was used extensively.  However, over time the need for email
   source-routing disappeared.




--
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/>