eap Mailing List: Re: Issue 404: Peer-Id & Server-Id in Tunneled Methods

[Bernard Aboba (bernard_aboba]

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 [at] 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 [at] 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 [at] 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?