Subject: Inner identities, privacy, and roaming termination

From: Bernard Aboba <[email-masked]>
Date: Thu, 18 Dec 2008 10:03:55 -0800

The current version of the IEEE 802 attributes draft includes support for EAP-Server-Id and EAP-Peer-Id attributes:
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  
[email-masked] were used in the Access-Request, and the NAI [email-masked] 
were sent back in the Access-Accept, this would result in Accounting-Requests that were sent with a User-Name
attribute of [email-masked], 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.  

 EMAILING FOR THE GREATER GOOD
Join me

---

From: Stefan Winter <[email-masked]>
Date: Fri, 19 Dec 2008 09:58:37 +0100

Hello,

> 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
> [email-masked] were used in the
> Access-Request, and the NAI [email-masked]
> were sent back in the Access-Accept, this would result in
> Accounting-Requests that were sent with a User-Name
> attribute of [email-masked], bypassing roamingpartner.com.  This
> concern was articulated in RFC 4372 as well.

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

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

> expressed by Alfred Hoenes (see
> http://ops.ietf.org/lists/radiusext/2008/msg00822.html),

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

> attribute.  The question is whether an EAP-Peer-Id attribute might

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 19 Dec 2008 11:08:03 +0100

> http://www.cesnet.cz/doc/techzpravy/2008/incorrect-eap-termination-in-eduroam/

  I will note that version 2.0 of FreeRADIUS doesn't have this issue.
The functionality was originally added to support separation of the TLS
side of EAP from traditional RADIUS.  i.e. Placing a modern server
upstream from a legacy server, to enable support for EAP, when the
legacy server doesn't support EAP.

> attribute.  The question is whether an EAP-Peer-Id attribute might also

  Some deployments *require* that the realms differ, IIRC.  e.g. outer
"anonymous" and inner "[email-masked]".

  Alan DeKok.

---

From: Klaas Wierenga <[email-masked]>
Date: Fri, 19 Dec 2008 11:50:39 +0100

> legacy server doesn't support EAP.

also, it is in general not a good idea to use the same credentials both 
inside and outside tunnels anyway (compound authentication binding 
problem), so the end IdP should refuse credentials that arrive 'in the 
clear'.

What remains is that this is an end IdP problem. The IdP of the user can 
after terminating the EAP tunnel do whatever it pleases with the 
credentials, but that is not a protocol problem as Stefan mentioned.

Klaas