Two Issues for Clarification in RFC3579
From: Oliver Tavakoli (radagastfunk.com)
Date: Wed, 4 Feb 2004 13:44:36 -0500 (EST)
After careful reading of RFC3579, I have a couple of issues which I hope can
be clarified through discussion in this list.

Issue 1
-------

What follows is an excerpt from section 2.1:

   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.  Since RADIUS proxies
   are assumed to act as a pass-through, they cannot be expected to
   parse an EAP-Response/Identity encapsulated within EAP-Message
   attribute(s).

Historically, some RADIUS proxies have (based on configuration options)
altered the contents of the User-Name attribute during their routing
operation. If, for example, the User-Name contained bob [at] ispA2ispB, the 
proxy
RADIUS server that represents realm ispB might strip off this realm
identifier and forward a request for bob [at] ispA.

If the RADIUS proxy is non-EAP aware and it modifies the User-Name
attribute, the contents of the EAP-Response/Identity will clearly not be
changed. This implies that EAP aware RADIUS servers should be willing to
accept requests in which the values of User-Name and EAP-Response/Identity
do not match. Does everyone agree with this assertion?

If, on the other hand, the RADIUS proxy is EAP aware, should it modify the
contents of EAP-Response/Identity whenever it modifies the contents of
User-Name? Or must EAP-Response/Identity be forwarded without change from
the peer to RADIUS server? EAP-SIM, for example, appears to assume that the
EAP-Response/Identity remains unchanged.

Issue 2
-------

What follows is an excerpt from section 3:

   The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS
   in Access-Request packets, and either NAS-Identifier, NAS-IP-Address
   or NAS-IPv6-Address attributes MUST be included.  In order to permit
   forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name
   attribute was included in an Access-Request, the RADIUS server MUST
   include the User-Name attribute in subsequent Access-Accept packets.
   Without the User-Name attribute, accounting and billing becomes
   difficult to manage.  The User-Name attribute within the Access-
   Accept packet need not be the same as the User-Name attribute in the
   Access-Request.

This section states that the Access-Accept MUST include a User-Name
attribute and that the value of this attribute could be a billing identifier
and need not match the value of the User-Name attribute sent in the
Access-Request. It does not clearly state that the NAS is obligated to echo
the value of this User-Name attribute in any accounting requests it
generates for the session, but that does appear to be the implication. Is
this in fact a new requirement being placed on NAS vendors? If so, does
anyone know if any NASes actually support this feature?

Oliver Tavakoli
Funk Software

Results generated by Tiger Technologies using MHonArc.