Subject: [eap] Rewrite of Section 2 of the EAP Key Management Framework

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 Sep 2005 23:59:04 -0700 (PDT)

Here is a proposed rewrite of Section 2 of the EAP Key Management 
Framework document to improve clarity and clarify issues relating to lower 
layer key usage.   Comments/edits welcome. 

--------------------------------------------------------------------
2.  Lower Layer Operation

   Where EAP key derivation is supported, the conversation typically
   takes place in three phases:

      Phase 0: Discovery
      Phase 1: Authentication
               1a: EAP authentication
               1b: AAA Key Transport (optional)
      Phase 2: Secure Association Establishment
               2a: Unicast Secure Association
               2b: Multicast Secure Association (optional)

   Of these phases, Phase 0, 1b and Phase 2 are handled by a lower
   layer.  In the discovery phase (phase 0),  peers locate
   authenticators and discover their capabilities.  For example, a peer
   may locate an authenticator providing access to a particular network,
   or a peer may locate an authenticator behind a bridge with which it
   desires to establish a Secure Association.

   The authentication phase (phase 1) may begin once the peer and
   authenticator discover each other.  This phase always includes EAP
   authentication (phase 1a).  Where the chosen EAP method supports key
   derivation, in phase 1a EAP keying material is derived on both the
   peer and the EAP server.  This keying material may be used for
   multiple purposes, including protection of the EAP conversation and
   subsequent data exchanges.

   An additional step (phase 1b) is required in deployments which
   include a backend authentication server, in order to transport keying
   material from the backend authentication server to the authenticator.
   In order to obey the principle of Mode Independence, where a backend
   server is present AAA Key transport needs to replicate the exported
   EAP keying material and/or derived keys required for derivation of
   the TSKs.  Since existing TSK derivation techniques depend solely on
   the MSK, in existing AAA implementations, this is the only keying
   material replicated in the AAA key transport phase 1b.

   A Secure Association exchange (phase 2) then occurs between the peer
   and authenticator in order to manage the creation and deletion of
   unicast (phase 2a) and multicast (phase 2b) security associations
   between the peer and authenticator.  The conversation between the
   parties is shown in Figure 4.

   EAP peer                   Authenticator               Auth. Server
   --------                   -------------               ------------
    |<----------------------------->|                               |
    |     Discovery (phase 0)       |                               |
    |<----------------------------->|<----------------------------->|
    |   EAP auth (phase 1a)         |  AAA pass-through (optional)  |
    |                               |                               |
    |                               |<----------------------------->|
    |                               |       AAA Key transport       |
    |                               |      (optional; phase 1b)     |
    |<----------------------------->|                               |
    |  Unicast Secure association   |                               |
    |          (phase 2a)           |                               |
    |                               |                               |
    |<----------------------------->|                               |
    | Multicast Secure association  |                               |
    |     (optional; phase 2b)      |                               |
    |                               |                               |

                  Figure 4: Conversation Overview

2.1.  Discovery Phase

   In the discovery phase (phase 0), the EAP peer and authenticator
   locate each other and discover each other's capabilities. Discovery
   can occur manually or automatically, depending on the lower layer
   over which EAP runs.  Since authenticator discovery is handled
   outside of EAP, there is no need to provide this functionality within
   EAP.

   For example, where EAP runs over PPP, the EAP peer might be
   configured with a phone book providing phone numbers of
   authenticators and associated capabilities such as supported rates,
   authentication protocols or ciphersuites.  In contrast, PPPoE
   [RFC2516] provides support for a Discovery Stage to allow a peer to
   identify the Ethernet MAC address of one or more authenticators and
   establish a PPPoE SESSION_ID.

   IEEE 802.11 [IEEE-802.11] also provides integrated discovery support
   utilizing Beacon and/or Probe Request/Response frames, allowing the
   peer (known as the station or STA) to determine the MAC address and
   capabilities of one or more authenticators (known as Access Point or
   APs).

2.2.  Authentication Phase

   Once the peer and authenticator discover each other, they exchange
   EAP packets.  Typically, the peer desires access to the network, and
   the authenticators provide that access.  In such a situation, access
   to the network can be provided by any authenticator attaching to the
   desired network, and the EAP peer is typically willing to send data
   traffic through any authenticator that can demonstrate that it is
   authorized to provide access to the desired network.

   An EAP authenticator may handle the authentication locally, or it may
   act as a pass-through to a backend authentication server.  In the
   latter case the EAP exchange occurs between the EAP peer and a
   backend authenticator server, with the authenticator forwarding EAP
   packets between the two.  The entity which terminates EAP
   authentication with the peer is known as the EAP server.  Where pass-
   through is supported, the backend authentication server functions as
   the EAP server; where authentication occurs locally, the EAP server
   is the authenticator.  Where a backend authentication server is
   present, at the successful completion of an authentication exchange,
   EAP keying material is transported to the authenticator (phase 1b).

   EAP may also be used when it is desired for two network devices (e.g.
   two switches or routers) to authenticate each other, or where two
   peers desire to authenticate each other and set up a secure
   association suitable for protecting data traffic.

   Some EAP methods exist which only support one-way authentication;
   however, EAP methods deriving keys are required to support mutual
   authentication.  In either case, it can be assumed that the parties
   do not utilize the link to exchange data traffic unless their
   authentication requirements have been met.  For example, a peer
   completing mutual authentication with an EAP server will not send
   data traffic over the link until the EAP server has authenticated
   successfully to the peer, and a Secure Association has been
   negotiated.

   Since EAP is a peer-to-peer protocol, an independent and simultaneous
   authentication may take place in the reverse direction.  Both peers
   may act as authenticators and authenticatees at the same time.

   Successful completion of EAP authentication and key derivation by a
   peer and EAP server does not necessarily imply that the peer is
   committed to joining the network associated with an EAP server.
   Rather, this commitment is implied by the creation of a security
   association between the EAP peer and authenticator, as part of the
   Secure Association Protocol (phase 2).  As a result, EAP may be used
   for "pre-authentication" in situations where it is necessary to pre-
   establish EAP security associations in order to decrease handoff or
   roaming latency.

2.3.  Secure Association Phase

   The Secure Association phase (phase 2), if it occurs, begins after
   the completion of EAP authentication (phase 1a) and key transport
   (phase 1b).

   Secure Association Protocols typically include the following
   features:

[1]  Generation of fresh unicast and multicast transient session keys.

[2]  Integrity and replay protection.  This ensures that the Secure
     Association Protocol messages cannot be forged, modified or
     replayed.

[3]  Secure capabilities negotiation.  This enables security-relevant
     parameters such as cryptographic algorithms to be securely
     negotiated.

[4]  Key naming.  In order to avoid confusion in the case where an EAP
     peer has more than one set of exported EAP parameters applicable to
     establishment of a phase 2 security association with an
     authenticator, the secure Association protocol needs to identify
     the keying material for use in the Secure Association Protocol
     exchange.

[5]  Key management.  This enables security associations to be created
     and deleted, and for key state to be kept synchronized between the
     peer and authenticator.

[6]  Mutual proof of possession of EAP keying material between the peer
     and authenticator.  This enables the EAP peer and authenticator to
     confirm authorization.

   Aspects of the Secure Association Protocol are discussed in more
   detail in Section 4.

2.4.  Lower Layer Key Hierarchy

   On completion of EAP authentication, EAP methods on the peer and EAP
   server export the Master Session Key (MSK), Extended Master Session
   Key (EMSK), Initialization Vector (IV), Peer-ID, Server-ID, Session-
   ID and Key-Lifetime.  From these exported parameters two other types
   of keys may be derived:

    [3] Keying material calculated from exported quantities
    [4] Session keys calculated or transported by the Secure Association
        Protocol: TSKs.

   In order to satisfy the principle of Mode Independence, a lower layer
   may only base the derivation of sesson keys on exported EAP
   parameters guaranteed to be present on the peer and authenticator.
   This implies that the Transient Sesion Keys (TSKs), known only to the
   peer and authenticator, may only depend on exported EAP parameters
   replicated by AAA from the EAP server to the authenticator.

   TSKs MUST be cryptographically separate from each other.  Similarly,
   TEKs MUST be cryptographically separate from each other.  In
   addition, the TSKs MUST be cryptographically separate from the TEKs.

   In existing usage, the only exported EAP parameter that is replicated
   by AAA as the result of a successful EAP authentication is the MSK.
   In existing usage, the AAA-Key is always derived from the MSK and so
   can be referred to using the MSK name.  AAA-Key = MSK(0,63).

   The exported EAP parameters replicated from the EAP server to the
   peer have a scope defined by the EAP peer name (if securely provided
   to the authenticator), and the authenticator name (if securely
   provided to the peer).

   In order to avoid confusion in the case where an EAP peer has more
   than one set of exported EAP parameters applicable to establishment
   of a phase 2 security association with an authenticator, the secure
   Association protocol needs to identify the keying material for use in
   the Secure Association Protocol exchange.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
|                                                         |            ^
|                EAP Method                               |  Local to  |
|                                                         |       EAP  |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |            |
| |  TEK      | | MSK       | |EMSK       | |IV         | |            |
| |Derivation | |Derivation | |Derivation | |Derivation | |            |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |            |
|                 |               |                 |     |            V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
                  |               |                 |                  ^
                  | MSK (64B)     | EMSK (64B)      | IV (64B) Exported|
                  |               |                 |              by  |
                  |               |                 |              EAP |
                  |               V                 V                  v
                  |                                                 ---+
                  | AAA-Key                                Transported |
                  |                                             by AAA |
                  |                                           Protocol |
                  V                                                    V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    ---+
   |                           |                                       ^
   |     TSK  Derivation       |                           Lower layer |
   |     [AAA-Key Cache]       |                              Specific |
   |                           |                                       V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    ---+

         Figure 5: Complete Key Hierarchy

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

   Figure 6:  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 |
   |         |               |         |AAA-Key/|         |
   |         | Secure Assoc. |         | Name   |         |
   | peer    |<------------->|Authenti-|<-------|  auth   |
   |         |===============| cator   |========| server  |
   |         |  Link Layer   |         |  AAA   | (EAP    |
   |         | (PPP,IEEE 802)|         |Protocol| server) |
   |         |               |         |        |         |
   |MSK,EMSK |               |  MSK    |        |MSK,EMSK |
   | (TSKs)  |               |  (TSKs) |        |         |
   +-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
       ^                                            ^
       |                                            |
       | MSK, EMSK                                  | MSK, EMSK
       |                                            |
       |                                            |
   +-+-+-+-+-+                                  +-+-+-+-+-+
   |         |                                  |         |
   |  EAP    |                                  |  EAP    |
   |  Method |                                  |  Method |
   |         |                                  |         |
   |  (TEKs) |                                  |  (TEKs) |
   |         |                                  |         |
   +-+-+-+-+-+                                  +-+-+-+-+-+

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

2.5.  Authenticator and Peer Naming

   The exported EAP parameters replicated from the EAP server to the
   peer have a scope defined by the EAP peer name (if securely provided
   to the authenticator), and the authenticator name (if securely
   provided to the peer).  Absent an explicit binding step within the
   Secure Association Protocol, the replicated exported EAP parameters
   are not bound to a specific peer or authenticator port.

   Within the lower layer, EAP peer and authenticator identification
   enables the lower layer to define the scope of the exported EAP
   parameters passed down to the lower layer.  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 to the EAP peer.
   Mechanisms for this include use of the EAP-Request/Identity
   (unsecured) or 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 replicated exported EAP parameters are not bound to a
   specific peer or authenticator port.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 21 Sep 2005 11:57:12 -0700 (PDT)

Oops... sent an old version.  Here is the proposed rewrite:

-------------------------------------------------------------------------
2.  Lower Layer Operation

2.1.  Overview

      Phase 0: Discovery
      Phase 1: Authentication
               1a: EAP authentication

   parties is shown in Figure 3.

                  Figure 3: Conversation Overview

2.2.  Discovery Phase

2.3.  Authentication Phase

2.4.  Secure Association Phase

2.5.  Layering

   In completion of EAP authentication, EAP methods on the peer and EAP
   server export the Master Session Key (MSK), Extended Master Session
   Key (EMSK), Initialization Vector (IV), Peer-ID, Server-ID, Session-
   ID and Key-Lifetime.  As illustrated in Figure 4, keying material and
   parameters exported by EAP methods are passed down to the EAP peer or
   authenticator layers, which passes them to the EAP layer.  Keying
   material and related parameters (including Channel Bindings) MUST NOT
   be cached by the EAP peer or authenticator layers, or the EAP layer.

   Based on the Method-ID exported by the EAP method, the EAP layer
   forms the EAP Session-ID by concatenating the EAP Expanded Type with
   the Method-ID.  Together with the MSK, EMSK, IV, Peer-ID, Server-ID,
   and Key-Lifetime, the EAP layer passes the Session-ID down to the
   lower layer.

   The Method-ID is exported by EAP methods rather than the Session-ID
   so as to prevent EAP methods from writing into each other's Session-
   ID space.

2.6.  Key Usage

   In order to preserve the security of keys derived within EAP methods,
   lower layers other than AAA MUST NOT export keys passed down by EAP
   methods.  This implies that EAP keying material or parameters passed
   down to a lower layer are for the exclusive use of that lower and
   MUST NOT be used within another lower layer.

   The exception to this rule is AAA.  As illustrated in Figure 5, the
   AAA client provides transported EAP keying material and parameters to
   the EAP authenticator lower layer.  In order to prevent the
   compromise of transported EAP keying material and parameters, the AAA
   client and EAP authenticator MUST be co-resident.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                             |
   |                                             |
   |          EAP method                         |
   |                                             |
   | MSK, EMSK, IV,             Channel          |
   | Peer-ID, Server-ID,        Bindings         |
   | Method-ID,                                  |
   | Key-Lifetime                                |
   |                                             |
   |       V                       ^         ^   |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
   |       !                       !         !   |
   |  EAP  ! Peer or Authenticator !         !   |
   |       ! layer                 !         !   |
   |       !                       !         !   |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
   |       !                       !         !   |
   |  EAP  ! layer                 !         !   |
   |       !                       !         !   |
   |       ! Session-ID =          !         !   |
   |       ! Expanded-Type ||      !         !   |
   |       ! Method-ID             !         !   |
   |       !                       !         !   |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
   |       !                       !         !   |
   | Lower ! layer                 !         !   |
   |       !                       !         !   |
   |       V                       V         ^   |
   | MSK, EMSK, IV,             Channel   Result |
   | Peer-ID, Server-ID,        Bindings         |
   | Session-ID,                                 |
   | Key-Lifetime                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 4:  Flow of EAP parameters

        Peer         Pass-through Authenticator   Authentication
                                                      Server

   +-+-+-+-+-+-+                                   +-+-+-+-+-+-+
   |           |                                   |           |
   |EAP method |                                   |EAP method |
   |     V     |                                   |     V     |
   +-+-+-!-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-!-+-+-+
   |     !     |   |EAP  |  EAP  |             |   |     !     |
   |     !     |   |Peer |  Auth.| EAP Auth.   |   |     !     |
   |EAP  ! peer|   |     |       |             |   |EAP  !Auth.|
   |     !     |   |     |       |             |   |     !     |
   +-+-+-!-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-!-+-+-+
   |     !     |   |             |             |   |     !     |
   |EAP  !layer|   |   EAP  layer| EAP  layer  |   |EAP  !layer|
   |     !     |   |             |             |   |     !     |
   +-+-+-!-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-!-+-+-+
   |     !     |   |             |             |   |     !     |
   |     !     |   |       +-----------+       |   |     !     |
   |     !     |   |       !     |     !       |   |     !     |
   |Lower!layer|   |  Lower!layer| AAA ^ /IP   |   | AAA ! /IP |
   |     !     |   |       !     |     !       |   |     !     |
   |     V     |   |       V     |     !       |   |     !     |
   +-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
                                       !                 !
                                       !                 !
                                       +---------<-------+
                                           AAA Protocol

    Figure 5:  Flow of EAP Keying Material and Parameters

2.6.1.  Caching

   If explicitly permitted within the lower layer specification, lower
   layers MAY cache exported EAP keying material and related parameters,
   including Channel Bindings.   So as to enable  interoperability, new
   EAP lower layer specifications MUST describe EAP key caching
   behavior.  The caching behavior of existing EAP lower layers is as
   follows:

PPP  PPP, defined in [RFC1661] does not support caching of EAP key
     material or parameters.  Therefore EAP keying material passed down
     to the lower layer is assumed to be lost and cannot be recovered.

IKEv2
     IKEv2, defined in [IKEv2] only uses EAP keying material for
     authentication purposes and not key derivation.  As a result, IKEv2
     does not cache EAP keying material or parameters, nor does it
     utilize the Key-Lifetime to determine the lifetime of IPsec SAs.
     As  result, once IKEv2 authentication completes it is assumed that
     EAP keying material and parameters are discarded.

IEEE 802.11i
     IEEE 802.11i enables caching of the MSK, but not the EMSK, IV,
     Peer-ID, Server-ID, Session-ID, or Key-Lifetime.  More details are
     about the structure of the cache are available in [IEEE-802.11i].

IEEE 802.1X-2004
     IEEE 802.1X, defined in [IEEE-802.1X] does not support caching of
     EAP keying material or parameters.

AAA  Existing AAA servers supporting RADIUS/EAP [RFC3579] or Diameter
     EAP [RFC4207] do not support caching of EAP keying material or
     parameters.  Regardless of whether a given AAA implementation
     supports caching, keying material transported by AAA MUST be
     discarded by the AAA server once it is sent.

2.7.  Lower Layer Naming

   Within the lower layer, the EAP peer and authenticator typically
   utilize lower layer names to identify each other and define the scope
   of cached keying material.  However EAP methods treat lower layer
   peer and authenticator identities as opaque blobs and do not
   interpret them.  For example, EAP peers cannot compare the lower
   layer authenticator identifier with the Server-ID provided by the EAP
   method, since these two identifiers will not be the same where pass-
   through authentication is implemented.

   For the purpose of identifying the authenticator to the peer, it is
   RECOMMENDED that the NAS-Identifier attribute be provided by the
   authenticator to the peer, and that if AAA is enabled, that the
   authenticator/AAA client include the NAS-Identifer attribute within
   the Access-Request sent to the AAA server.  In order to ensure
   against forgery, it is RECOMMENDED that the peer and authenticator
   securely verify the authenticator identity, such as via the Secure
   Association Protocol.

   For the purpose of identifying the peer to the authenticator, the EAP
   Peer-ID provided within the EAP method is recommended.  Where the
   authenticator acts as a pass-through, the AAA server may include the
   Peer-ID in an Access-Accept if requested to do so by the
   authenticator/AAA client.  Alternatively, the peer may provide the
   authenticator with the Peer-ID via the lower layer, such as within
   the Secure Association Protocol.

2.8.  Lower Layer Key Hierarchy

   Based on the EAP keying material and parameters provided to it, the
   lower layer may derive two other types of keys:

    [3] Keying material calculated from exported EAP keying material
    [4] Session keys calculated or transported by the Secure Association
        Protocol: TSKs.

   MUST only base the derivation of sesson keys on exported EAP

   authenticator.  This is illustrated in Figure 7.  As demonstrated in

   Where a backend authentication server is utilized, the situation is
   illustrated in Figure 8.  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 [RFC4072], 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.

         Figure 6: Complete Key Hierarchy

   +-+-+-+-+-+               +-+-+-+-+-+
   |         |               |         |
   |         |               |         |
   | Cipher- |               | Cipher- |
   | Suite   |               | Suite   |
   |         |               |         |
   +-+-+-+-+-+               +-+-+-+-+-+
       ^                         ^
       |                         |
       |                         |
       |                         |
       V                         V
   +-+-+-+-+-+               +-+-+-+-+-+
   |         |               |         |
   |         |===============|         |

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

   +-+-+-+-+-+               +-+-+-+-+-+
   |         |               |         |
   |         |               |         |
   | Cipher- |               | Cipher- |
   | Suite   |               | Suite   |
   |         |               |         |
   +-+-+-+-+-+               +-+-+-+-+-+
       ^                         ^
       |                         |
       |                         |
       |                         |
       V                         V

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