Subject: [eap] Issue 236: (Key Framework) Rewrite of Section 2

From: Bernard Aboba <[email-masked]>
Date: Sat, 3 Apr 2004 15:55:33 -0800 (PST)

Issue 236: Rewrite of Section 2
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: 4/3/2004
Reference:
Document: Keying-01
Comment type: T/E
Priority: S
Section: 2
Rationale/Explanation of issue:

I've gone and rewritten Section 2 to improve the organization and
readability.

Change Section 2 to the following:

"2.  EAP Key Hierarchy

2.1.  Key Terminology

   The EAP Key Hierarchy makes use of the following types of keys:

Master Session Key (MSK)
     Keying material that is derived between the EAP peer and server and
     exported by the EAP method.  The MSK is at least 64 octets in
     length.

Extended Master Session Key (EMSK)
     Additional keying material derived between the peer and server that
     is exported by the EAP method.  The EMSK is at least 64 octets in
     length, and is never shared with a third party.

AAA-Key
     A key derived by the peer and EAP server, used by the peer and
     authenticator in the derivation of Transient Session Keys (TSKs).
     Where a backend authentication server is present, the AAA-Key is
     transported from the backend authentication server to the
     authenticator, wrapped within the AAA-Token; it is therefore known
     by the peer, authenticator and backend authentication server.
     However, despite the name, the AAA-Key is computed regardless of
     whether a backend authentication server is present.  AAA-Key
     derivation is discussed in Appendix E; in existing implementations
     the MSK is used as the AAA-Key.

AAA-Token
     Where a backend server is present, the AAA-Key and one or more
     attributes is transported between the backend authentication server
     and the authenticator within a package known as the AAA-Token.  The
     format and wrapping of the AAA-Token, which is intended to be
     accessible only to the backend authentication server and
     authenticator, is defined by the AAA protocol.  Examples include
     RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap].

Initialization Vector (IV)
     A quantity of at least 64 octets, suitable for use in an
     initialization vector field, that is derived between the peer and
     EAP server.  Since the IV is a known value in methods such as EAP-
     TLS [RFC2716], it cannot be used by itself for computation of any
     quantity that needs to remain secret.  As a result, its use has
     been deprecated and EAP methods are not required to generate it.
     However, when it is generated it MUST be unpredictable.

Pairwise Master Key (PMK)
     The AAA-Key is divided into two halves, the "Peer to Authenticator
     Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer
     Encryption Key" (Enc-SEND-Key) (reception is defined from the point
     of view of the authenticator).  Within [IEEE80211i] Octets 0-31 of
     the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key
     (PMK).  In [IEEE80211i] the TKIP and AES CCMP ciphersuites derive
     their Transient Session Keys (TSKs) solely from the PMK, whereas
     the WEP ciphersuite as noted in [RFC3580], derives its TSKs from
     both halves of the AAA-Key.

Transient EAP Keys (TEKs)
     Session keys which are used to establish a protected channel
     between the EAP peer and server during the EAP authentication
     exchange. The TEKs are appropriate for use with the ciphersuite
     negotiated between EAP peer and server for use in protecting the
     EAP conversation.  Note that the ciphersuite used to set up the
     protected channel between the EAP peer and server during EAP
     authentication is unrelated to the ciphersuite used to subsequently
     protect data sent between the EAP peer and authenticator. An
     example TEK key hierarchy is described in Appendix C.

Transient Session Keys (TSKs)
     Session keys used to protect data which are appropriate for the
     ciphersuite negotiated between the EAP peer and authenticator.  The
     TSKs are derived from AAA-Key during the Secure Association
     Protocol.  In the case of [IEEE80211i] the Secure Association
     Protocol consists of the 4-way handshake and group key derivation.
     An example TSK derivation is provided in Appendix D.

2.2.  Key Hierarchy

   The EAP Key Hierarchy, illustrated in Figure 3 below, includes three
   types of keys:

    [1] Keys calculated locally by the EAP method but not exported,
        such as the TEKs.
    [2] Keys exported by the EAP method: MSK, EMSK, IV and
        keys calculated from exported quantities: AAA-Key.
    [3] Keys calculated by the Secure Association Protocol: TSKs.

   In order to protect some or all of the EAP conversation, EAP methods
   supporting key derivation typically negotiate a ciphersuite and
   derive Transient EAP Keys (TEKs) to provide keys for that
   ciphersuite.  However, the TEKs are stored locally within the EAP
   method and are not exported.

   As noted in [RFC3748] Section 7.10, EAP methods generating keys are
   required to calculate and export the MSK and EMSK, which must be at
   least 64 octets in length.  EAP methods also may export the IV;
   however, the use of the IV is deprecated.

   On both the peer and EAP server, the exported MSK and EMSK are
   utilized in order to calculate the AAA-Key.  Where a backend
   authentication server is present, the AAA-Key is transported from the
   backend authentication server to the authenticator within the AAA-
   Token, using the AAA protocol.

   Once EAP authentication completes and is successful, the peer and
   authenticator obtain the AAA-Key and the Secure Association Protocol
   is run between the peer and authenticator in order to securely
   negotiate the ciphersuite, derive fresh TSKs used to protect data,
   and provide mutual proof of possession of the AAA-Key.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
   |                                                         |            ^
   |                EAP Method                               |            |
   |                                                         |            |
   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |            |
   | |                                       |               |            |
   | |           EAP Method Key              |               |            |
   | |             Derivation                |               |            |
   | |                                       |               |  Local to  |
   | |                                       |               |       EAP  |
   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |     Method |
   |   |             |               |                       |            |
   |                                                         |            |
   |   |             |               |                       |            |
   |                                                         |            |
   |   V             |               |                       |            |
   | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |            |
   | |  TEK      | | MSK       | |EMSK       | |IV         | |            |
   | |Derivation | |Derivation | |Derivation | |Derivation | |            |
   | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |            |
   |                 |               |                 |     |            |
   |                 |               |                 |     |            V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
                     |               |                 |                  ^
                     |               |                 |                  |
                     | MSK (64B)     | EMSK (64B)      | IV (64B)         |
                     |               |                 |          Exported|
                     |               |                 |              by  |
                     V               V                 V              EAP |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+  Method|
             |          AAA  Key Derivation,     | | Known       |        |
             |          Naming & Binding         | |(Not Secret) |        |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+        V
                     |                                                 ---+
                     |                                        Transported |
                     | AAA-Key                                     by AAA |
                     |                                           Protocol |
                     V                                                    V
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    ---+
      |                           |                                       ^
      |            TSK            |                           Ciphersuite |
      |        Derivation         |                              Specific |
      |                           |                                       V
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    ---+

                             Figure 3: EAP Key Hierarchy

   When the authenticator acts as an endpoint of the EAP conversation
   rather than a pass-through, EAP methods are implemented on the
   authenticator as well as the peer.  If the EAP method negotiated
   between the EAP peer and authenticator supports mutual authentication
   and key derivation, the EAP Master Session Key (MSK) and Extended
   Master Session Key (EMSK) are derived on the EAP peer and
   authenticator and exported by the EAP method.  In this case, the MSK
   and EMSK are known only to the peer and authenticator and no other
   parties.  The TEKs and TSKs also reside solely on the peer and
   authenticator.  This is illustrated in Figure 4.  As demonstrated in
   [I-D.ietf-roamops-cert], in this case it is still possible to support
   roaming between providers, using certificate-based authentication.

   Where a backend authentication server is utilized, the situation is
   illustrated in Figure 5.   Here the authenticator acts as a pass-
   through between the EAP peer and a backend authentication server. In
   this model, the authenticator delegates the access control decision
   to the backend authentication server, which acts as a Key
   Distribution Center (KDC).  In this case, the authenticator
   encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579]
   or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the
   backend authentication server, which acts as the EAP server.  Since
   the authenticator acts as a pass-through, EAP methods reside only on
   the peer and EAP server As a result, the TEKs, MSK and EMSK are
   derived on the peer and EAP server.

   On completion of EAP authentication, EAP methods on the peer and EAP
   server export the Master Session Key (MSK) and Extended Master
   Session Key (EMSK).  The peer and EAP server then calculate the AAA-
   Key from the MSK and EMSK, and the backend authentication server
   sends an Access-Accept to the authenticator, providing the AAA-Key
   within a protected package known as the AAA-Token.

   The AAA-Key is then used by the peer and authenticator within the
   Secure Association Protocol to derive Transient Session Keys (TSKs)
   required for the negotiated ciphersuite.  The TSKs are known only to
   the peer and authenticator.

   +-+-+-+-+-+               +-+-+-+-+-+
   |         |               |         |
   |         |               |         |
   | Cipher- |               | Cipher- |
   | Suite   |               | Suite   |
   |         |               |         |
   +-+-+-+-+-+               +-+-+-+-+-+
       ^                         ^
       |                         |
       |                         |
       |                         |
       V                         V
   +-+-+-+-+-+               +-+-+-+-+-+
   |         |               |         |
   |         |===============|         |
   |         |EAP, TEK Deriv.|Authenti-|
   |         |<------------->| cator   |
   |         |               |         |
   |         | Secure Assoc. |         |
   | peer    |<------------->| (EAP    |
   |         |===============| server) |
   |         | Link layer    |         |
   |         | (PPP,IEEE802) |         |
   |         |               |         |
   |MSK,EMSK |               |MSK,EMSK |
   | AAA-Key |               | AAA-Key |
   | (TSKs)  |               |  (TSKs) |
   |         |               |         |
   +-+-+-+-+-+               +-+-+-+-+-+
       ^                         ^
       |                         |
       | MSK, EMSK               | MSK, EMSK
       |                         |
       |                         |
   +-+-+-+-+-+               +-+-+-+-+-+
   |         |               |         |
   |  EAP    |               |  EAP    |
   |  Method |               |  Method |
   |         |               |         |
   | (TEKs)  |               | (TEKs)  |
   |         |               |         |
   +-+-+-+-+-+               +-+-+-+-+-+

   Figure 4:  Relationship between EAP peer and authenticator (acting as
   an EAP server), where no backend authentication server is present.

   +-+-+-+-+-+               +-+-+-+-+-+
   |         |               |         |
   |         |               |         |
   | Cipher- |               | Cipher- |
   | Suite   |               | Suite   |
   |         |               |         |
   +-+-+-+-+-+               +-+-+-+-+-+
       ^                         ^
       |                         |
       |                         |
       |                         |
       V                         V
   +-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
   |         |===============|         |========|         |
   |         |EAP, TEK Deriv.|         |        |         |
   |         |<-------------------------------->| backend |
   |         |               |         |        |         |
   |         | Secure Assoc. |         | AAA-Key|         |
   | peer    |<------------->|Authenti-|<-------|  auth   |
   |         |===============| cator   |========| server  |
   |         |  Link Layer   |         |  AAA   | (EAP    |
   |         | (PPP,IEEE 802)|         |Protocol| server) |
   |         |               |         |        |         |
   |MSK,EMSK |               | AAA-Key |        |MSK,EMSK,|
   | (TSKs)  |               |  (TSKs) |        | AAA-Key |
   |         |               |         |        |         |
   +-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
       ^                                            ^
       |                                            |
       | MSK, EMSK                                  | MSK, EMSK
       |                                            |
       |                                            |
   +-+-+-+-+-+                                  +-+-+-+-+-+
   |         |                                  |         |
   |  EAP    |                                  |  EAP    |
   |  Method |                                  |  Method |
   |         |                                  |         |
   |  (TEKs) |                                  |  (TEKs) |
   |         |                                  |         |
   +-+-+-+-+-+                                  +-+-+-+-+-+

   Figure 5: Pass-through relationship between EAP peer, authenticator
   and backend authentication server.

2.3.  Requirements for EMSK Usage

   EAP reserves a portion of keying material, called the EMSK, for
   extended uses.  Keys derived from this key material may be used to
   key applications on different devices and different processes
   separate from the entity that receives the MSK.

   If the keying material is used to provide keys for multiple
   Applications or devices, it is desired that the keys will be
   cryptographically separate. Cryptographic separation means that
   knowledge of one key does not provide an easy way to determine
   another key derived from the same key material.  This is also known
   as computationally independent.

   This section provides guidelines for a mechanism which can be used
   with existing and new EAP methods and applications to provide
   cryptographic separation between keys derived for different
   applications and devices.  These derived keys are referred to in this
   section as Application Master Session Keys or AMSK.

   The EAP EMSK usage guidelines provide a means for generating multiple
   application-specific master keys (AMSKs).  These AMSKs are then used
   to derive transient session keys (TSKs), which are used as actual
   ciphering keys.  This allows multiple applications to use keys
   independently derived from the EAP method.

   AMSK Key Derivation is discussed in Appendix F."
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Florent Bersani <[email-masked]>
Date: Thu, 08 Apr 2004 14:41:50 +0200

Hi Bernard,

Some (minor) comments in-line.

Florent

Bernard Aboba wrote:

>...
Well, I see four types of keys

>    [2] Keys exported by the EAP method: MSK, EMSK, IV 
>

>and
Shouldn't this be a (logically) separated type?

>   method and are not exported.
Does this preclude TEK caching? My answer is no. Is clarification 
required to specify what does "be exported" and "not be exported" mean?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap