eap Mailing List: Proposed Resolution of Issue 313: Distributed Authenticators

[Bernard Aboba (bernard_aboba]

The text of Issue 313 is available here:
http://www.drizzle.com/~aboba/EAP/eapissues3.html#Issue%20313

The proposed resolution is as follows:

In Section 1.2, change the definition of Transient Session Keys to the 
following:

Transient Session Keys (TSKs)
   Session keys used to protect data exchanged after EAP authentication
has successfully completed, using the ciphersuite negotiated
between the EAP peer and authenticator.

In Section 2.4.1, delete the following text:

"  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
  can be applied to the identification of EAP authenticators.

  RADIUS 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 associated with it, the
  NAS-Identifier attribute is RECOMMENDED for the unambiguous
  identification of the EAP authenticator.

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

Insert a new Section prior to Section 2.4.2, including the following text:

2.4.2  Authenticator Architecture

"The EAP method conversation is between the EAP peer and server, as
identified by the Peer-ID and Server-ID. The authenticator identity,
if considered at all by the EAP method, is treated as
an opaque blob for the purposes of Channel bindings.
However, the Secure Association Protocol conversation is between the
peer and the authenticator, and therefore the authenticator and peer
identities are relevant to that exchange, and define the scope of use of the
EAP keying material passed down to the lower layer.

Since an authenticator may have many ports,
the authenticator identifier used within the Secure Association Protocol 
exchange
SHOULD be distinct from any port identifier (e.g. MAC 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 peer
identifier used within the Secure Association Protocol exchange
SHOULD also be distinct from any port identifier.

While EAP Keying Material passed down to the lower layer is not
intrinsically bound to particular authenticator and peer ports,
Transient Session Keys MAY be bound to particular authenticator
and peer ports by the Secure Association Protocol. However,
a lower layer MAY also permit TSKs to be used on multiple peer
and/or authenticator ports, providing that TSK freshness is
guaranteed (such as by keeping replay counter state within
the authenticator).

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

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 the unambiguous
identification of the EAP authenticator.

> From the point of view of the AAA 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 AAA server detects use of EAP keying material and
parameters outside the scope defined by the NAS-Identifier, the
keying material MUST be considered compromised."

Add to the Informative References:

[RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy for
Control and Provisioning of Wireless Access Points (CAPWAP)",
RFC 4118, June 2005