Subject: [eap] Issue 347: Key Scope Cleanup

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 03 Apr 2006 11:02:48 -0700

Issue 347: Key Scope Cleanup
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
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

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 03 Apr 2006 12:54:52 -0700

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" <[email-masked]>
>To: [email-masked]
>Subject: [eap] Issue 347: Key Scope Cleanup
>Date: Mon, 03 Apr 2006 11:02:48 -0700
>