Subject: [eap] Two Issues for Clarification in RFC3579

From: Oliver Tavakoli <[email-masked]>
Date: Wed, 4 Feb 2004 13:56:05 -0500

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@ispA2ispB, the proxy
RADIUS server that represents realm ispB might strip off this realm
identifier and forward a request for bob@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
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 4 Feb 2004 11:17:13 -0800

[email-masked] wrote:
> After careful reading of RFC3579, I have a couple of issues
> which I hope can be clarified through discussion in this list.
> 
> Issue 1
> -------
> 
> 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@ispA2ispB, the proxy RADIUS
> server that represents realm ispB might strip off this realm
> 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?
> 
[Joe] I 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.
> 
[Joe] Yes this would cause a problem for EAP-SIM.  I don't think a proxy
should not modify the EAP-Message attribute in any way. 

>    in Access-Request packets, and either NAS-Identifier,
>    NAS-IP-Address or NAS-IPv6-Address attributes MUST be included. 
> In order 
> to permit
> 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?
> 
[Joe] This is a good question.  I believe there are NASes and stateful
proxies that support this (I've seen the username from the Access-Accept
in accounting packets, but I'm not sure who put it there).