eap Mailing List: Proposed Resolution to Issue 274: Naming of AMSKs

[Bernard Aboba (aboba]

The EAP Issue list is available for inspection at:
http://www.drizzle.com/~aboba/EAP/eapissues.html

The proposed resolution of Issue 274: Naming of AMSKs is as
follows:

Replace Section 2.4 with the following:

"2.4.  Key Names and Scopes

   Each key created within the EAP key management framework has a name
   (the identifier by which the key can be identified), as well as a
   scope (the parties to whom the key is available).  This section
   describes how keys are named, and the scope within which that name
   applies.

Session-Id

   EAP methods supporting key naming MUST specify a temporally unique
   method identifier known as the EAP Method-Id, which is typically
   constructed from nonces or counters used within the exchange.  Since
   multiple EAP sessions may exist between an EAP peer and EAP server,
   the Method-Id allows MSKs to be differentiated.

   The combination of the EAP Type and the Method-Id is known as the EAP
   Session-Id.  The inclusion of the Type in the EAP Session-Id ensures
   that each EAP method has a distinct name space.

   The EAP Session-Id uniquely identifies the EAP session to the EAP
   peer and server terminating the EAP conversation.  However, suitable
   EAP peer and server names may not always be available.  As described
   in [RFC3748] Section 7.3, the identity provided in the EAP-
   Response/Identity, may be different from the identity authenticated
   by the EAP method, and as a result the EAP-Response/Identity is
   unsuitable for determination of the peer identity.  As a result, the
   Session-Id scope is defined by the EAP peer name (if securely
   exchanged within the method) concatenated with the EAP server name
   (also only if securely exchanged).  Where a peer or server name is
   missing the null string is used.  Since an EAP session is not bound
   to a particular authentication or specific ports on the peer and
   authenticator, the authenticator port or identity are not included in
   the Session-Id scope.

   The EAP Session-Id is exported by the EAP method along with the
   Session-Id scope, if available, and is used to construct names for
   other EAP keys.  Note that the EAP Session-Id and scope are only
   known by the EAP method.  As a result, the format of the EAP Session-
   Id and the definition of the Session-Id scope needs to be specified
   within the method.  Appendix E defines the EAP Session-Id and scope
   provided by existing methods.

MSK Name

   This key is created between the EAP peer and EAP server, and can be
   referred to using the string "MSK" and the EAP Session-Id.  As with
   the EAP Session-Id, the MSK scope is defined by the EAP peer name (if
   securely exchanged within the method) and the EAP server name (also
   only if securely exchanged).  Where a peer or server name is missing
   the null string is used.

EMSK Name

   The EMSK can be referred to using the string "EMSK" and the EAP
   Session-Id.

   As with the EAP Session-Id, the EMSK scope is defined by the EAP peer
   name (if securely exchanged within the method) and the EAP server
   name (also only if securely exchanged).  Where a peer or server name
   is missing the null string is used.

AMSK Name

   AMSKs, if any, can be referred to using the string "AMSK", the key
   label, application data (see Section 2.6) and the EAP Session-Id.

   As with the EAP Session-Id, the AMSK scope is defined by the EAP peer
   name (if securely exchanged within the method) and the EAP server
   name (also only if securely exchanged).  Where a peer or server name
   is missing the null string is used.

AAA-Key Name

   The AAA-Key is derived from either the MSK or AMSK and so can be
   referred to using the MSK or AMSK names.

   The AAA-Key scope is provided by the concatenation of the EAP peer
   name (if securely provided to the authenticator), and the
   authenticator name (if securely provided to the peer).

   For the purpose of identifying the authenticator to the peer, the
   value of the NAS-Identifier attribute is recommended.  The
   authenticator may include the NAS-Identifier attribute to the AAA
   server in an Access-Request, and the authenticator may provide the
   NAS-Identifier (unsecured) to the EAP peer in the EAP-
   Request/Identity or via a lower layer mechanism (such as the 802.11
   Beacon/Probe Response).  Where the NAS-Identifier is provided by the
   authenticator to the peer a secure mechanism is RECOMMENDED.

   For the purpose of identifying the peer to the authenticator, the EAP
   peer identifier provided within the EAP method is recommended.  It
   cannot be assumed that the authenticator is aware of the EAP peer
   name used within the method.  Therefore alternatives mechanisms need
   to be used to provide the EAP peer name to the authenticator.  For
   example, the AAA server may include the EAP peer name in the User-
   Name attribute of the Access-Accept or the peer may provide the
   authenticator with its name via a lower layer mechanism.

   Absent an explicit binding step within the Secure Association
   Protocol, the AAA-Key is not bound to a specific peer or
   authenticator port.  As a result, the peer or authenticator port over
   which the EAP conversation takes place is not included in the AAA-Key
   scope.

PMK Name

   This document does not specify a naming scheme for the PMK.  The PMK
   is only identified by the AAA-Key from which it is derived.
   Similarly, the PMK scope is the same as the AAA-Key scope.

   Note: IEEE 802.11i names the PMKID for the purposes of being able to
   refer to it in the Secure Association protocol; this naming is based
   on a hash of the PMK itself as well as some other parameters (see
   Section 8.5.1.2 [IEEE80211i]).

TEKs

   The TEKs may or may not be named. Their naming is specified in the
   EAP method.  Since the TEKs are only known by the EAP peer and
   server, the TEK scope is the same as the Session-Id scope.

TSKs

   The TSKs are typically named. Their naming is specified in the Secure
   Association (phase 2) protocol, so that the correct set of transient
   session keys can be identified for processing a given packet.  The
   scope of the TSKs is negotiated within the Secure Association
   Protocol.

   TSK creation and deletion operations are typically supported so that
   establishment and re-establishment of TSKs can be synchronized
   between the parties.

   In order to avoid confusion in the case where an EAP peer has more
   than one AAA-Key (phase 1b) applicable to establishment of a phase 2
   security association, the secure Association protocol needs to
   utilize the AAA-Key name so that the appropriate phase 1b keying
   material can be identified for use in the Secure Association Protocol
   exchange."