The text of Issue 404 is enclosed below. The suggested
resolution is based
on the following assumption:
"The purpose of the Peer-Id and Server-Id is to
identify the entities that
were involved in the creation of EAP keying material. Within
a tunnel method
the
EAP keying material could be derived solely from the outer
authentication
(as in EAP-TTLSv0), or it could be derived from a
combination of the outer
and inner exchanges.
Where the EAP keying material is derived solely from the
outer
exchange, the Peer-Id and Server-Id is determined based on
the
identities authenticated in the outer exchange. If the EAP
keying
material is derived from both the outer and inner exchanges,
then
the Peer-Id and Server-Id are determined based on the
identities
authenticated in both exchanges."
It has been asked how this relates to RFC 4718 Section 3.5,
which states:
"3.5. Identity for Policy Lookups When Using EAP
When the initiator authentication uses EAP, it is
possible that the
contents of the IDi payload is used only for AAA routing
purposes and
selecting which EAP method to use. This value may be
different from
the identity authenticated by the EAP method (see [EAP],
Sections 5.1
and 7.3).
It is important that policy lookups and access control
decisions use
the actual authenticated identity. Often the EAP server
is
implemented in a separate AAA server that communicates
with the IKEv2
responder using, e.g., RADIUS [RADEAP]. In this case,
the
authenticated identity has to be sent from the AAA server
to the
IKEv2 responder.
(References: Pasi Eronen's mail "RE:
Reauthentication in IKEv2",
2004-10-28. "Policy lookups" thread, Oct/Nov
2004. RFC 3748,
Section 7.3.)"
The question is whether the "authenticated
identity" referred to here is the
Peer-Id or not, and if it is the Peer-Id, whether this
creates any issues
for use of tunneled methods such as EAP-TTLSv0 within
IKEv2.
There are three user identities involved in an EAP/AAA
conversation:
1. The EAP-Response/Identity (or in the case of IKEv2, IDi).
This identity
is typically not modified by AAA proxies along the
authentication path, so
that original decorations if present, remain. Example:
juniper.net!pfunk bt.com
2. The User-Name. The EAP-Response/Identity is placed in
the User-Name
attribute by the NAS, but may be processed by AAA proxies in
order to remove
decoration, so that by the time it arrives at the AAA server
it is different
from the EAP-Response/Identity. Example: pfunk juniper.net.
3. The Peer-Id.
Note that identities #1 and #2 are present in *all* EAP
methods, regardless
of whether they generate keys. Identity #3 is only present
in
key-generating methods (at least according to the suggested
resolution of
this issue).
I believe that RFC 4718 Section 3.5 above is actually
talking about the
User-Name attribute, not the Peer-Id. Since the User-Name
attribute (or
CUI) can be included in an Access-Accept, no new
functionality is required
within the AAA protocol to satisfy the requirement.
However, EAP methods are not shown to export the User-Name
within the
figures, so perhaps this should be added.
------------------------------------------------------------
-------------------------
Issue 404: Peer-Id & Server-Id in Tunneled Methods
Submitter name: Paul Funk
Submitter email address: pfunk juniper.net
Date Submitted: April 7, 2007
Reference: http://lists.frascone.com/pipermail/eap/msg04709.html
Document: KEYING-18
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
Review of the 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?
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|