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

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 21 Oct 2007 07:12:01 -0700

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: 
[email-masked]

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:  [email-masked].

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: [email-masked]
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

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 21 Oct 2007 08:40:53 -0700

Here is some revised text on the Peer-Id and Server-Id:

For Section 1.4:

   Peer-Id

      If an EAP method that generates keys authenticates one or more
      method-specific peer identities, those identities are exported by
      the method as the Peer-Id(s).  It is possible for more than one
      Peer-Id to be exported by an EAP method.  Not all EAP methods
      provide a method-specific peer identity; where this is not
      defined, the Peer-Id is the null string.  In EAP methods that do
      not support key generation, the Peer-Id MUST be the null string.
      Where an EAP method that derives keys does not provide a Peer-Id,
      the EAP server will not authenticate the identity of the EAP peer
      with which it derived keying material.

   Server-Id

      If an EAP method that generates keys authenticates one or more
      method-specific server identities, those identities are exported
      by the method as the Server-Id(s).  It is possible for more than
      one Server-Id to be exported by an EAP method.  Not all EAP
      methods provide a method-specific server identity; where this is
      not defined, the Server-Id is the null string.  If the EAP method
      not generate keying material, the Server-Id MUST be the null
      string.  Where an EAP method that derives keys does not provide a
      Server-Id, the EAP peer will not authenticate the identity of the
      EAP server with which it derived EAP keying material.

For Sections 2.4 and 2.5:

2.4.  Peer Identification

   As described in [RFC3748] Section 7.3, the peer identity provided in
   the EAP-Response/Identity can be different from the peer identities
   authenticated by the EAP method.  For example, the identity provided
   in the EAP-Response/Identity can be a privacy identifier as described
   in "The Network Access Identifier" [RFC4282] Section 2.  As noted in
   [RFC4284], it is also possible to utilize a Network Access Identifier
   (NAI) for the purposes of source routing; an NAI utilized for source
   routing is said to be "decorated" as described in [RFC4282] Section
   2.7.

   When EAP peer provides the Network Access Identity (NAI) within the
   EAP-Response/Identity, as described in [RFC3579], the authenticator
   copies the NAI included in the EAP-Response/Identity into the User-
   Name attribute included within the Access-Request.  As the Access-
   Request is forwarded toward the backend authentication server, AAA
   proxies remove decoration from the NAI included in the User-Name
   Attribute; the NAI included within the EAP-Response/Identity
   encapsulated in the Access-Request remains unchanged.  As a result,
   when the Access-Request arrives at the backend authentication server,
   the EAP-Response/Identity can differ from the User-Name Attribute
   (which can have some or all of the decoration removed).  In the
   absence of a Peer-Id, the backend authentication server SHOULD use
   the contents of the User-Name Attribute, rather than the EAP-
   Response/Identity as the peer identity.

   It is possible for more than one Peer-Id to be exported by an EAP
   method.  For example, a peer certificate can contain more than one
   peer identity; in a tunnel method peer identities can be
   authenticated both within an outer and inner exchange and these
   identities could be different in type and contents.  For example, an
   outer exchange could provide a Peer-Id in the form of an RDN, whereas
   an inner exchange could identify the peer via its NAI or MAC address.
   Where EAP keying material is determined solely from the outer
   exchange, only the outer Peer-Id(s) are exported; where the EAP
   keying material is determined from both the inner and outer
   exchanges, then both the inner and outer Peer-Id(s) are exported by
   the tunnel method.

2.5.  Server Identification

   It is possible for more than one Server-Id to be exported by an EAP
   method.  For example, a server certificate can contain more than one
   server identity; in a tunnel method server identities could be
   authenticated both within an outer and inner exchange and these
   identities could be different in type and contents.  For example, an
   outer exchange could provide a Server-Id in the form of an IP
   address, whereas an inner exchange could identify the server via its
   FQDN or hostname.  Where EAP keying material is determined solely
   from the outer exchange, only the outer Server-Id(s) are exported by
   the EAP method; where the EAP keying material is determined from both
   the inner and outer exchanges, then both the inner and outer Server-
   Id(s) are exported by the EAP method.

   As shown in Figure 3, an authenticator can be configured to
   communicate with multiple EAP servers; the EAP server that an
   authenticator communicates with can vary according to configuration
   and network and server availability.  While the EAP peer can assume
   that all EAP servers within a realm have access to the credentials
   necessary to validate an authentication attempt, it cannot assume
   that all EAP servers share persistent state.

   Authenticators can be configured with different primary or secondary
   EAP servers, in order to balance the load.  Also, the authenticator
   can dynamically determine the EAP server to which requests will be
   sent; in event of a communication failure, the authenticator can fail
   over to another EAP server.  For example, in Figure 3, Authenticator2
   can be initially configured with EAP server1 as its primary backend
   authentication server, and EAP server2 as the backup, but if EAP
   server1 becomes unavailable, EAP server2 can become the primary
   server.

   In general, the EAP peer cannot direct an authentication attempt to a
   particular EAP server within a realm; this decision is made by AAA
   clients.  Nor can the peer determine which EAP server it will be
   communicating with, prior to the start of the EAP method
   conversation.  The Server-Id is not included in the EAP-
   Request/Identity, and since the EAP server may be determined
   dynamically, it typically is not possible for the authenticator to
   advertise the Server-Id during the discovery phase.  Some EAP methods
   do not export the Server-Id so that is is possible that the EAP peer
   will not learn which server it was conversing with after the EAP
   conversation completes successfully.

   As a result, an EAP peer, on connecting to a new authenticator or
   reconnecting to the same authenticator, can find itself communicating
   with a different EAP server.  Fast reconnect, defined in [RFC3748]
   Section 7.2, can fail if the EAP server that the peer communicates
   with is not the same one with which it initially established a
   security association.  For example, an EAP peer attempting an EAP-TLS
   session resume can find that the new EAP-TLS server will not have
   access to the TLS Master Key identified by the TLS Session-Id, and
   therefore the session resumption attempt will fail, requiring
   completion of a full EAP-TLS exchange.

   EAP methods that export the Server-Id MUST authenticate the server.
   However, not all EAP methods supporting mutual authentication provide
   a non-null Server-Id; some methods only enable the EAP peer to verify
   that the EAP server possesses a long-term secret, but do not provide
   the identity of the EAP server.  In this case the EAP peer will know
   that an authenticator has been authorized by an EAP server, but will
   not confirm the identity of the EAP server.  Where the EAP method
   does not provide a Server-Id, the peer cannot identify the EAP server
   with which it generated keying material.  This can make it difficult
   for the EAP peer to identity the location of a key possessed by that
   EAP server.

   As noted in [I-D.simon-emu-rfc2716bis] Section 5.2,  EAP methods
   supporting authentication using server certificates can determine the
   Server-Id from the subject or subjectAltName fields in the server
   certificate.  Validating the EAP server identity can help the EAP
   peer to decide whether a specific EAP server is authorized.  In some
   cases, such as where the certificate extensions defined in [RFC4334]
   are included in the server certificate, it can even be possible for
   the peer to verify some Channel Binding parameters from the server
   certificate.

   It is possible for problems to arise in situations where the EAP
   server identifies itself differently to the EAP peer and
   authenticator.  For example, it is possible that the Server-Id
   exported by EAP methods will not be identical to the Fully Qualified
   Domain Name (FQDN) of the backend authentication server.  Where
   certificate-based authentication is used within RADIUS or Diameter,
   it is possible that the subjectAltName used in the backend
   authentication server certificate will not be identical to the
   Server-Id or backend authentication server FQDN.

   Where the backend authentication server FQDN differs from the
   subjectAltName in the backend authentication server certificate, it
   is possible that the AAA client will not be able to determine whether
   it is talking to the correct backend authentication server.  Where
   the Server-Id and backend server FQDN differ, it is possible that the
   combination of the key scope (Peer-Id(s), Server- Id(s)) and EAP
   conversation identifier (Session-Id) will not be sufficient to
   determine where the key resides.  For example, the authenticator can
   identify backend servers by their IP address (as occurs in RADIUS),
   or using a Fully Qualified Domain Name (as in Diameter).  If the
   Server-Id does not correspond to the IP address or FQDN of a known
   backend authentication server, then it may not be possible to locate
   which backend authentication server possesses the key.