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

[Bernard Aboba (bernard_aboba]

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.