eap Mailing List: Re: Proposed Resolution to Issue 365: Ambiguous UseofIdentifier

[Bernard Aboba (bernard_aboba]

To improve the clarity of the sections on Authenticator, Peer and Server 
Identification, I've done some rewriting.  How about this?

"2.2.1.  Authenticator and Peer Identification

  The EAP method conversation is between the EAP peer and server. The
  authenticator identity, if considered at all by the EAP method, is
  treated as an opaque blob for the purposes of Channel Bindings (see
  Section 5.12).  However, the authenticator identity is important in
  two other exchanges - the AAA protocol exchange and the Secure
  Association Protocol conversation.

  The AAA conversation is between the EAP authenticator and the backend
  authentication server. From the point of view of the backend
  authentication server, EAP keying material and parameters are
  transported to the EAP authenticator identified by the NAS-Identifier
  attribute.  Since an EAP authenticator MUST NOT share EAP keying
  material or parameters with another party, if the EAP peer or backend
  authentication server detects use of EAP keying material and
  parameters outside the scope defined by the NAS-Identifier, the
  keying material MUST be considered compromised.

                              +-+-+-+-+
                              | EAP   |
                              | Peer  |
                              +-+-+-+-+
                                | | |  Peer Ports
                               /  |  \
                              /   |   \
                             /    |    \
                            /     |     \
                           /      |      \
                          /       |       \
                         /        |        \
                        /         |         \     Authenticator
                     | | |      | | |      | | |   Ports
                   +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                   |       |  |       |  |       |
                   | Auth1 |  | Auth2 |  | Auth3 |
                   |       |  |       |  |       |
                   +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                        \        | \         |
                         \       |  \        |
                          \      |   \       |
            EAP over AAA   \     |    \      |
              (optional)    \    |     \     |
                             \   |      \    |
                              \  |       \   |
                               \ |        \  |
                            +-+-+-+-+-+  +-+-+-+-+-+  Backend
                            |  EAP    |  |  EAP    |  Authentication
                            | Server1 |  | Server2 |  Servers
                            +-+-+-+-+-+  +-+-+-+-+-+

  Figure 3: Relationship between EAP peer, authenticator and server

  The Secure Association Protocol conversation is between the peer and
  the authenticator.  For lower layers which support key caching it is
  particularly important for the EAP peer, authenticator and backend
  server to have a consistent view of the usage scope of the
  transported EAP keying material.  In order to enable this, it is
  RECOMMENDED that the Secure Association Protocol explicitly
  communicate the usage scope of the EAP keying material passed down to
  the lower layer, rather than implicitly assuming that this is defined
  by the authenticator and peer endpoint addresses.

  Since an authenticator may have multiple ports, the scope of the
  authenticator key cache may not be described by a single endpoint
  address.  Similarly, where a peer may have multiple ports and sharing
  of EAP keying material and parameters between peer ports of the same
  link type is allowed, the extent of the peer key cache cannot be
  communicated by using a single endpoint address.  Instead, it is
  RECOMMENDED that the EAP peer and authenticator consistently identify
  themselves utilizing explicit identifiers, rather than endpoint
  addresses or port identifiers.

  AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
  a mechanism for the identification of AAA clients; since the EAP
  authenticator and AAA client are always co-resident, this mechanism
  is applicable to the identification of EAP authenticators.

  RADIUS [RFC2865] requires that an Access-Request packet contain one
  or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
  attributes. Since a NAS may have more than one IP address, the NAS-
  Identifier attribute is RECOMMENDED for explicit identification of
  the authenticator, both within the AAA protocol exchange and the
  Secure Association Protocol conversation.

  Problems which may arise where the peer and authenticator implicitly
  identify themselves using endpoint addresses include the following:

[a]  It may not be obvious to the peer which authenticator ports are
    associated with which authenticators.  The EAP peer will be unable
    to determine whether EAP keying material has been shared outside
    its authorized scope, and needs to be considered compromised.  The
    EAP peer may also be unable to utilize the authenticator key cache
    in an efficient way.

[b]  It may not be obvious to the authenticator which peer ports are
    associated with which peers.  As a result, the authenticator may
    not be able to enable a peer to communicate with it utilizing
    multiple peer ports.

[c]  It may not be obvious to the peer which "virtual authenticator" it
    is communicating with.  For example, multiple "virtual
    authenticators" may share a MAC address, but utilize different NAS-
    Identifiers.

[d]  It may not be obvious to the authenticator which "virtual peer" it
    is communicating with.  Multiple "virtual peers" may share a MAC
    address, but utilize different Peer-Ids.

[e]  It may not be possible for the EAP peer and server to verify the
    authenticator identity via channel bindings.

  For example, problems [a], [c] and [e] occur in [IEEE-802.11i], which
  utilizes peer and authenticator MAC addresses within the 4-way
  handshake.  Problems [b] and [d] do not occur since [IEEE-802.11i]
  only allows a peer to utilize a single port.

  The following steps enable lower layer identities to be securely
  verified by all parties:

[f]  Specifying the lower layer parameters used to identify the
    authenticator and peer.  As noted earlier, endpoint or port
    identifiers are not recommended for identification of the
    authenticator or peer when it is possible for them to have multiple
    ports.

[g]  Communicating the lower layer identities between the peer and
    authenticator within phase 0.  This allows the peer and
    authenticator to determine the key scope if a key cache is
    utilized.

[h]  Communicating the lower layer authenticator identity between the
    authenticator and backend server within the NAS-Identifier
    attribute.

[i]  Including the lower layer identities within Channel Bindings (if
    supported) in phase 1a, ensuring that they are communicated between
    the EAP peer and server.

[j]  Supporting the integrity-protected exchange of identities within
    phase 2a.

[k]  Utilizing the advertised lower layer identities to enable the peer
    and authenticator to verify that keys are maintained within the
    advertised scope.

2.2.2.  Virtual Authenticators

  When a single physical authenticator advertises itself as multiple
  "virtual authenticators", if the virtual authenticators do not
  maintain logically separate key caches, then by authenticating  to
  one virtual authenticator, the peer can gain access to the other
  virtual authenticators sharing a key cache.

  For example, where a physical authenticator implements "Guest" and
  "Corporate Intranet" virtual authenticators,  an attacker acting as a
  peer could authenticate with the "Guest" "virtual authenticator" and
  derive EAP keying material.  If the "Guest" and "Corporate Intranet"
  virtual authenticators share a key cache, then the peer can utilize
  the EAP keying material derived for the "Guest" network to obtain
  access to the "Corporate Intranet" network.

  In order to address this vulnerability:

[a]  Authenticators are REQUIRED to cache associated authorizations
    along with EAP keying material and parameters and to apply
    authorizations consistently.  This ensures that an attacker cannot
    obtain elevated privileges even where the key cache is shared
    between "virtual authenticators".

[b]  It is RECOMMENDED that physical authenticators maintain separate
    key caches for each "virtual authenticator".

[c]  It is RECOMMENDED that each "virtual authenticator" identify itself
    consistently to the peer and to the backend authentication server,
    so as to enable the peer to verify the authenticator identity via
    Channel Bindings (see Section 5.11).

[d]  It is RECOMMENDED that each "virtual authenticator" identify itself
    distinctly, in order to enable the peer and backend server to tell
    them apart.  For example, this can be accomplished by utilizing a
    distinct NAS-Identifier attribute or BSSID.

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 enables 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."