eap Mailing List

View Index by: Date - Thread - Author
RE: Issue 347: Key Scope Cleanup
From: Bernard Aboba (bernard_abobahotmail.com)
Date: Mon, 3 Apr 2006 12:54:59 -0700 (PDT)
Found some additional key scope redundancy in Section 5.5.

In Section 5.5, Change:

"  In order to enable key binding and authorization of all parties, it
  is RECOMMENDED that the parties use a set of identities that are
  consistent between the conversation phases.  RADIUS [RFC2865] and
  Diameter NASREQ [RFC4005] require that the NAS/EAP authenticator
  identify itself by including one or more identification attributes
  within an Access-Request packet (NAS-Identifier, NAS-IP-Address, NAS-
  IPv6-Address).

  Since the backend authentication server provides EAP keying material
  for use by the EAP authenticator as identified by these attributes,
  where an EAP authenticator may have multiple ports, it is RECOMMENDED
  for the EAP authenticator to identify itself using NAS identification
  attributes during the Secure Association Protocol exchange with the
  EAP peer.  This enables the EAP peer to determine whether EAP keying
  material has been shared between EAP authenticators as well as to
  confirm with the backend authentication server that an EAP
  authenticator proving possession of EAP keying material during the
  Secure Association Protocol was authorized to obtain it.  Typically,
  the NAS-Identifier attribute is most convenient for this purpose,
  since a NAS/authenticator may have multiple IP addresses.

  Similarly, the backend authentication server authorizes the EAP
  authenticator to provide access to the EAP peer identified by the
  Peer-ID, securely verified during the EAP authentication exchange.
  In order to determine whether EAP keying material has been shared
  between EAP peers, where the EAP peer has multiple ports it is
  RECOMMENDED for the EAP peer to identify itself using the Peer-ID
  during the Secure Association Protocol exchange with the EAP
  authenticator."


To:

"  In order to enable key binding and authorization of all parties, it
  is RECOMMENDED that the parties use a set of identities that are
  consistent between the conversation phases.  Consistently identifying
  the EAP authenticator enables the EAP peer to determine whether EAP
  keying material has been shared between EAP authenticators as well as
  to confirm with the backend authentication server that an EAP
  authenticator proving possession of EAP keying material during the
  Secure Association Protocol was authorized to obtain it.
  Identification issues are discussed in Section 2.2 and key scope
  issues are discussed in Section 3.2."


From: "Bernard Aboba" <bernard_aboba [at] hotmail.com>
To: eap [at] frascone.com
Subject: [eap] Issue 347: Key Scope Cleanup
Date: Mon, 03 Apr 2006 11:02:48 -0700

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


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

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



Results generated by Tiger Technologies using MHonArc.