eap Mailing List: Re: Proposed Resolution to Issue 367: Key Scope andServerAuthorization

[Bernard Aboba (bernard_aboba]

> Suggested edit: s/This enables the EAP peer to decide/This may help
> the EAP peer to decide/

Here is a revised version of the text proposed for Section 2.3:

"2.3.  Server Identification

  The EAP method conversation is between the EAP peer and server, as
  identified by the Peer-Id and Server-Id.  As shown in Figure 3, an
  authenticator may be configured to communicate with multiple EAP
  servers; the EAP server that an authenticator communicates with may
  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 may 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 may fail
  over to another EAP server.  For example, in Figure 3, Authenticator2
  may 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 may 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 solely by
  the authenticator.  Nor can it 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 authenticator determines the EAP
  server dynamically, it typically is not possible for the
  authenticator to advertise the Server-Id during the discovery phase.
  EAP methods may or may not export the Server-Id, and as a result, the
  EAP peer may not even 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, may find itself communicating
  with a different EAP server.  Fast reconnect, defined in [RFC3748]
  Section 7.2, may 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 may 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 support mutual authentication may not allow the EAP
  peer to verify the EAP server identity.  For example, the EAP peer
  may only verify that the EAP server possesses a long-term secret; in
  this case the EAP peer will only know that an authenticator has been
  authorized by an EAP server, but will not confirm the identity of the
  EAP server.

  EAP methods that export the Server-Id MUST verify the server
  identity.  As noted in Appendix A, existing EAP methods exporting the
  Server-Id determine this from the altSubjectName in the server
  certificate, and as a result, the peer determines the identity of the
  server (expressed as a Fully Qualified Domain Name (FQDN)) by
  validating the server certificate.

  Validating the EAP server identity may help the EAP peer to decide
  whether a specific EAP server is authorized, and to determine whether
  the EAP server is sharing keying material outside the intended scope.
  In some cases, such as where the certificate extensions defined in
  [RFC4334] are included in the server certificate, it may even be
  possible for the peer to verify some Channel Binding parameters from
  the server certificate.  Where the EAP peer does not verify the EAP
  server identity, it is not possible for the peer to determine whether
  the EAP server has shared keying material outside its authorized
  scope.

  It is possible for problems to arise in situations where the EAP
  server identifies itself differently to the EAP peer and
  authenticator.  For example, the Server-Id exported by EAP methods
  may 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, the altSubjectName
  used in the backend server certificate may not be identical to the
  Server-Id or backend server FQDN.

  Where the backend server FQDN differs from the altSubjectName in the
  certificate, the AAA client may not be able to successfully determine
  whether it is talking to the correct backend authentication server.
  Where the Server-Id and backend server FQDN differ, the combination
  of the key scope (Peer-Id, Server-Id) and EAP conversation identifier
  (Session-Id) may not be sufficient for the authenticator to determine
  where the key resides.  For example, the authenticator may 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 the authenticator will not know which
  backend authentication server possesses the key."