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 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.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|