eap Mailing List: Proposed Resolution to Issue 367: Key Scope and Server Authorization

[Bernard Aboba (bernard_aboba]

The text of Issue 367 is enclosed below.  The proposed resolution is to 
change Section 2.2 to the text enclosed below, as well as to add a new 
Section 2.2.1, as follows:

2.2.  Peer and Authenticator Architecture

  This specification does not impose constraints on the architecture of
  the EAP authenticator or peer. Any of the authenticator architectures
  described in [RFC4118] can be used. As a result, lower layers need to
  identify EAP peers and authenticators unambiguously, without
  incorporating implicit assumptions about peer and authenticator
  architectures.

  For example, it is possible for multiple base stations and a
  "controller" (e.g. WLAN switch) to comprise a single EAP
  authenticator.  In such a situation, the "base station identity" is
  irrelevant to the EAP method conversation, except perhaps as an
  opaque blob to be used in Channel Bindings. Many base stations can
  share the same authenticator identity.  It should be understood that
  an EAP authenticator or peer:

  [a] may contain one or more physical or logical ports;
  [b] may advertise itself as one or more "virtual"
      authenticators or peers;
  [c] may utilize multiple CPUs;
  [d] may support clustering services for load balancing or failover.

  Both the EAP peer and authenticator may have more than one physical
  or logical port.  A peer may simultaneously access the network via
  multiple authenticators, or via multiple physical or logical ports on
  a given authenticator.  Similarly, an authenticator may offer network
  access to multiple peers, each via a separate physical or logical
  port.  When a single physical authenticator advertises itself as
  multiple "virtual authenticators",  it is possible for a single
  physical port to belong to multiple "virtual authenticators".

  An authenticator may be configured to communicate with more than one
  EAP server, each of which is configured to communicate with a subset
  of the authenticators.  The situation is illustrated in Figure 3.

                              +-+-+-+-+
                              | 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

2.2.1.  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 within a realm, 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 Master Key identified by the TLS Session-Id, and
  therefore the session resumption attempt will fail, requiring
  completion of a full EAP-TLS exchange.


==========================================================
Issue 367: Key Scope and EAP Server Authorization
Submitter name: Joe Salowey
Submitter email address: jsalowey [at] cisco.com
Date Submitted: May 3, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04231.html
Document: KEYING-12
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 2.2.1 and 3.2
Rationale/Explanation of issue:

Section 1.4.1 correctly defines the scope of the EAP keying material as
being defined by the EAP Peer and EAP server, however this relationship
is not carried out in other key scope discussions as far as I can tell.
In order for channel binding, key mixing etc. to work the peer must make
sure that the key is used not just within the authorized parameters of
the lower layer, but of the authorized scope of the EAP server as well.

I'm not sure of all of all the places where this needs to be addressed,
but I think it needs to be addressed in section 2.2.1 perhaps by adding

"[g] Verifying that the advertised scope is within the scope that the
EAP server is allowed to authorize"

Section 3.2 should probably state somewhere that:

"The peer should verify that the key scope advertised by the
authenticator is within the scope that is allowed to be authorized by
the EAP Server."

[Bernard Aboba]

I think I see the point, which is that a given authenticator may be 
connected to
more than one EAP server, and that all authenticators in a realm
may not share the same EAP server. Also, EAP servers cannot necessarily
be assumed to share key state among each other. If the selcted EAP method 
does not
provide the Server-Id, then the peer cannot know the scope of the keys it
derives with the EAP server.

This can create a number of issues, such as a peer attempting (but failing) 
a
fast reconnect because the server that the authenticator is configured to
communicate with is not the same one with which the peer established the
previous session.

However, there are other situations in which the server identity is not 
material,
such as handoff in an 11r Mobility Domain (MD), where the STA only care 
whether
a candidate AP is in the same MD, not whether the new authenticator is 
configured
to talk to the same backend authentication server as the current or initial 
AP.

In practice, the peer determines whether an authenticator is within the 
scope
of authorization of the backend authentication server by attempting to 
complete
the SAP exchange with it. If the exchange succeeds, the authenticator is
authorized; if not, it isn't. It is possible for the peer to attempt a
fast reconnect exchange with the wrong server; unless the server were to
include its identity in the EAP-Request there is no way for the peer to
determine what server it is talking to before the EAP method conversation
gets underway. Even if the authenticator were to advertise the server(s)
that it is configured to talk to, and even if those servers were identified
by their Server-Ids, it would not be possible for the peer to know a-priori
which server it was going to talk to, since the primary server can change 
due
to changes in network or server availability.

Given this, I'm not sure how the peer can verify that an authenticator is
allowed to be authorized by an EAP server.