eap Mailing List: Issue 347: Key Scope Cleanup

[Bernard Aboba (bernard_aboba]

Issue 347: Key Scope Cleanup
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date Submitted: April 3, 2006
Reference:
Document: Keying-10
Comment type: E
Priority: S
Section:
Rationale/Explanation of issue:

Material relating to Key Scope is included in Sections 2.2, 2.3, 3.1.  The 
material appears redundant.

The resolution is to delete Section 2.3, and split the material between 
Section 2.2.1 and a new Section 3.2, and delete the following material from 
Section 3.1 [h], since it is already gone over in considerable depth in 
Section 2.2:

"Since the Discovery phase is handled
out-of-band, EAP does not provide a mechanism by which the peer can
determine the authenticator identity.  As a result, where the
authenticator has multiple ports and key caching is supported, the
EAP peer may not be able to determine the scope of validity of the
exported EAP keying material.  Similarly, where the EAP peer has
multiple ports, the authenticator may not be able to determine
whether a peer has authorization to use a particular key."

Section 2.2.1 now reads as follows:

"2.2.1.  Authenticator Identification

  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.

  Where the EAP peer and authenticator cannot unambiguously identify
  each other they may not be able to determine the scope of transported
  EAP keying material.  This is particularly problematic for lower
  layers where key caching is supported.

  For example, if the EAP peer cannot identify the EAP authenticator,
  it will be unable to determine whether transported EAP keying
  material has been shared outside of its authorized scope, and
  therefore needs to be considered compromised.  There is also a
  practical problem because the EAP peer will be unable to utilize the
  EAP authenticator key cache in an efficient way.  Where the peer and
  authenticator identify themselves within the lower layer using a port
  identifier such as a link layer address, this creates a number of
  problems:

[1]  It may not be obvious to the peer which authenticator ports are
    associated with which authenticators.

[2]  It may not be obvious to the authenticator which peer ports are
    associated with which peers.

[3]  It may not be obvious to the peer which "virtual authenticator" it
    is communicating with.

[4]  It may not be obvious to the authenticator which "virtual peer" it
    is communicating with.

    Since an authenticator may have multiple 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.

    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.

    In order to ensure that lower layer identifies are securely
    verified by all parties, it is recommended that lower layers:

[a]  Specify the lower layer parameters used to identify the
    authenticator and peer;

[b]  Communicate the lower layer identities between the peer and
    authenticator within phase 0;

[c]  Communicate the lower layer authenticator identity between the
    authenticator and backend server within the NAS-Identifier
    attribute;

[d]  Include the lower layer identities within channel bindings (if
    supported) in phase 1a, ensuring that they are communicated between
    the EAP peer and server;

[e]  Securely verify the lower layer identities within phase 2a;

[f]  Utilize the advertised lower layer identities to enable the peer
    and authenticator to verify that keys are maintained within the
    advertised scope;"

The newly inserted Section 3.2 reads as follows:

"3.2.  Key Scope

  Absent explicit specification within the lower layer, after the
  completion of phase 1b, EAP keying material and parameters are bound
  to the EAP peer and authenticator, but are not bound to a specific
  peer or authenticator port.

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

  In order to further limit the key scope the following measures are
  suggested:

[a]  The lower layer MAY specify additional restrictions on key usage,
    such as limiting the use of EAP keying material and parameters on
    the EAP peer to the port over which on the EAP conversation was
    conducted.

[b]  The backend authentication server and authenticator MAY implement
    additional attributes in order to further restrict the scope of EAP
    keying material.  For example, in 802.11, the backend
    authentication server may provide the authenticator with a list of
    authorized Called or Calling-Station-Ids and/or SSIDs for which EAP
    keying material is valid.

[c]  Where the backend authentication server provides attributes
    restricting the key scope, it is RECOMMENDED that restrictions be
    securely communicated by the authenticator to the peer.  This can
    be accomplished using the Secure Association Protocol,  but also
    can be accomplished via the EAP method or the lower layer."