eap Mailing List: Re: issue 367: Key Scope and EAP Server Authorization

[Bernard Aboba (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 single 
administrative
domain 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.

The proposed resolution is as follows:

Change Section 2.2 to the following:

"2.2 Peer, Authenticator and Server Architecture

This specification does not impose constraints on the architecture of the
EAP authenticator, peer or server. 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, peers or servers;
[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
backend authentication 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"

Add a new section 2.2.1 entitled "Server Identification":

"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 server that 
a peer communicates
with may vary according to network and server availability.  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.

As a result, prior to initiation of the EAP conversation, the peer may not 
be able to predict which
EAP server it will be communicating with.  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. The peer may not be able to 
determine
the Server-Id prior to the start of the EAP method conversation, since the
Server-Id is not included in the EAP-Request/Identity, and may not be
advertised by the authenticator during the discovery phase."

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