Re: Inner identities, privacy, and roaming termination

[Stefan Winter <stefan.winter@restena.lu>]

Hello,

> 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.

Some eduroam participants do this. NAS behaviour in Accounting-Requests
is apparently not homogenous. Some apparently continue to use the
User-Name from the authentication phase. In a roaming context, where the
home AAA server has no information on the NAS equipment being used, this
indeterminism makes the "feature" of using User-Name for EAP Peer-Id
mostly useless.
>    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.

That's true. Getting rid of this overloading would in itself be a
justification for keeping EAP-Peer-Id in the 80211 attributes draft.

> 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. 

IMHO, there is little a NAS can do if a home AAA wants to send this
information. The home AAA could also send it in an arbitrary VSA. So,
while it may be undesirable, it is also not deterministically possible
for the NAS to disable getting this information. Providing or not
providing a defined semantics/attribute for the piece of information
doesn't magically make the possibility for transmission go away. So, I
wouldn't use this argument against the definition of an EAP-Peer-Id.

> 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. 

Since empty attributes are forbidden, a 0x00 seems like a good workaround.

> 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.

While we were concerned over this redirection possibility, I wouldn't
call it an "attack", but much rather an "unexpected feature". It can be
mitigated by the AAA server which terminates the EAP session. It is in
possession of both the outer identity and the EAP Peer-Id, and can do
the sanity checks. This reduces the problem to one of a correct local
configuration at the side of the EAP peer. I wonder if it really makes
sense to do additional checks on the visited AAA or NAS side. If so, an
EAP-Peer-Id attribute might make sense here.
Also, I could imagine some configurations where a home AAA server serves
multiple realms, a user uses a combination with differing realms but
which are both handled by the same AAA server, in which case it might be
unexpected that a NAS somewhere decides that this is an unjust action.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>