eap Mailing List: The Peer-Id and tunneled methods

[Bernard Aboba (bernard_aboba]

Review of the recently submitted EAP-TTLSv0 specification has raised some 
questions about how the Peer-Id is determined for tunneled methods:

1. What if multiple identities are being authenticated?  EAP-TTLSv0 can 
handle both mutual authentication in phase I (via certificates) as well as 
one or more inner methods.   Are multiple Peer-Ids returned in this case, or 
is there only one (or none)?

2. What if Phase I used only server authentication and the inner method 
doesn't export a Peer-Id (e.g. EAP-MD5).  Does the tunneled method return 
the null Peer-Id in this case?

3. Do Peer-Ids have a type?

Here are some thoughts on these questions.

1. A method may return multiple Peer-IDs.  In AAA, there is the assumption 
that a session can be tied to an account for billing purposes.  For example, 
even where anonymity is used, there is a need for the AAA server to know who 
the user is, so that they can be billed for the session.  For example, RFC 
4372 assumes that the AAA server can return a CUI based on an inner 
identity; it is also possible for the AAA server to return a User-Name 
attribute which will be carried in subsequent Accounting-Requests.  Where 
there are multiple Peer-Ids,  the AAA server may have to choose between them 
to decide which User-Name attribute to return, or how the Peer-Ids map to 
the CUI returned in the Access-Accept.

2. The EAP-Response/Identity is not really suitable as a Peer-Id, since it 
is primarily used for routing purposes, and may be "decorated". As a result, 
the RADIUS User-Name attribute (which is undecorated) is typically more 
appropriate for use in determining the identity claim than the 
EAP-Response/Identity.  This raises some interesting issues about how 
anonymity would function in the case where the inner method is say, EAP-MD5. 
 For example, what happens if the outer EAP-Response/Identity is 
anonymous [at] example.com and the inner EAP-Response/Identity is decorated (e.g. 
example1.com!fred [at] example2.com). In this case, the inner 
EAP-Response/Identity does not necessarily correspond to the user-id that is 
being authenticated; EAP-MD5 has a null Peer-Id (since it does not have a 
method-specific identity), so in this case the tunneled method would have to 
return the  null  Peer-Id.  However, where the inner method(s) did return 
Peer-Id(s), I think that these would be returned as the tunneled method 
Peer-Id(s).

3. Peer-Ids don't have a type; they are like the RADIUS User-Name attribute 
in that regard.