http://tools.ietf.org/html/draft-aboba-radext-wlan
I am considering removing these attributes in the next revision of the document, and would like to get the WG's
opinion on this. The question is whether these attributes are needed, and whether they would be used if provided.
The primary use of the EAP-Peer-Id attribute would be to enable a NAS to determine the identity of the user where
the EAP method-specific identity differed from the identity provided in the EAP-Response/Identity. For example,
in EAP-TTLSv0, the outer identity could be anonymous, while the inner identity could provide the authenticated
identity of the user.
Today, a mechanism for providing the user identity to the NAS is to send the EAP Peer-Id
within a User-Name attribute in an Access-Accept. This will provide the NAS with the inner identity,
and will also cause Accounting-Requests to include the inner-identity within the User-Name attribute. However,
this does have the side effect of potentially causing authentication and accounting messages to take different paths
in the situation where NAI re-writing occurs within proxies. For example, if the NAI
example.com!anonymous@roamingpartner.com were used in the Access-Request, and the NAI fred@example.com
were sent back in the Access-Accept, this would result in Accounting-Requests that were sent with a User-Name
attribute of fred@example.com, bypassing roamingpartner.com. This concern was articulated in RFC 4372 as well.
Providing an EAP-Peer-Id attribute would address concerns about overloading of the User-Name attribute.
One concern that has been raised about the EAP-Peer-Id attribute is privacy.
As noted in the CUI RFC (RFC 4372), there are situations where it is undesirable for the NAS to obtain
knowledge of the user identity. Where a CUI attribute containing a NUL is sent in an Access-Request,
the home server should assume that privacy is desired, and neither a User-Name nor an EAP-Peer-Id
attribute should be sent in an Access-Accept, only a CUI attribute.
However, there are situations in which privacy might be desired, but the NAS does not support the
CUI attribute. Therefore the document currently states that the EAP-Peer-Id is only sent in an
Access-Accept if the EAP-Peer-Id attribute is included in an Access-Request. To address the concerns
expressed by Alfred Hoenes (see http://ops.ietf.org/lists/radiusext/2008/msg00822.html),
it would be possible to include a single NUL character in EAP-Peer-Id and EAP-Server-Id attributes sent within
an Access-Request, rather than sending empty attributes.
In EDUROAM, an attack has been identified that involves use of two distinct realms within an EAP method
supporting privacy (such as EAP-TTLSv0):
http://www.cesnet.cz/doc/techzpravy/2008/incorrect-eap-termination-in-eduroam/
It would appear that this attack can be addressed by adding a check on the part of a home
RADIUS server in order to require that the inner and outer identities share a realm. If the
realms are allowed to differ, then it would appear to be necessary for at least the inner realm
to be provided to the NAS somehow. This could be within a CUI attribute or a User-Name
attribute. The question is whether an EAP-Peer-Id attribute might also be useful.
Join me |