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 example.com and the inner EAP-Response/Identity is
decorated (e.g.
example1.com!fredexample2.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.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
