| Two Issues for Clarification in RFC3579 | <– Date –> <– Thread –> |
|
From: Oliver Tavakoli (radagast |
|
| 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
-
Two Issues for Clarification in RFC3579 Oliver Tavakoli, February 4 2004
- RE: Two Issues for Clarification in RFC3579 Joseph Salowey, February 4 2004
- RE: Two Issues for Clarification in RFC3579 Adrangi, Farid, February 16 2004
Results generated by Tiger Technologies using MHonArc.