Email lists > Discussion list for EAP > Re: [eap] Issue 404: Peer-Id & Server-Id in Tunneled Methods > Re: [eap] Issue 404: Peer-Id & Server-Id in Tunneled Methods

Re: [eap] Issue 404: Peer-Id & Server-Id in Tunneled Methods




This post if a part of  this thread

2007-10-21 09:12:01
Re: Issue 404: Peer-Id & Server-Id in Tunneled Methods
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!pfunkbt.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:  pfunkjuniper.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: pfunkjuniper.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

about | contact  Other archives ( Real Estate discussion Medical topics )