eap Mailing List: RE: Two Issues for Clarification in RFC3579

[Joseph Salowey (jsalowey]

eap-admin [at] frascone.com 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
> -------
> 
> 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?
> 
[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. 

> 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?
> 
[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).  

> Oliver Tavakoli
> Funk Software
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap