Subject: [eap] Proposed Resolution to Issue 367: Key Scope and Server Authorization

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 03 Jun 2006 18:16:16 -0700

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

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap