tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5247

 Errata 
Proposed STD
Pages: 79
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: EAP

Extensible Authentication Protocol (EAP) Key Management Framework

Part 1 of 4, p. 1 to 20
None       Next RFC Part

Updates:    3748


Top       ToC       Page 1 
Network Working Group                                           B. Aboba
Request for Comments: 5247                                      D. Simon
Updates: 3748                                      Microsoft Corporation
Category: Standards Track                                      P. Eronen
                                                                   Nokia
                                                             August 2008


   Extensible Authentication Protocol (EAP) Key Management Framework

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   The Extensible Authentication Protocol (EAP), defined in RFC 3748,
   enables extensible network access authentication.  This document
   specifies the EAP key hierarchy and provides a framework for the
   transport and usage of keying material and parameters generated by
   EAP authentication algorithms, known as "methods".  It also provides
   a detailed system-level security analysis, describing the conditions
   under which the key management guidelines described in RFC 4962 can
   be satisfied.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................3
      1.1. Requirements Language ......................................3
      1.2. Terminology ................................................3
      1.3. Overview ...................................................7
      1.4. EAP Key Hierarchy .........................................10
      1.5. Security Goals ............................................15
      1.6. EAP Invariants ............................................16
   2. Lower-Layer Operation ..........................................20
      2.1. Transient Session Keys ....................................20
      2.2. Authenticator and Peer Architecture .......................22
      2.3. Authenticator Identification ..............................23
      2.4. Peer Identification .......................................27
      2.5. Server Identification .....................................29
   3. Security Association Management ................................31
      3.1. Secure Association Protocol ...............................32
      3.2. Key Scope .................................................35
      3.3. Parent-Child Relationships ................................35
      3.4. Local Key Lifetimes .......................................37
      3.5. Exported and Calculated Key Lifetimes .....................37
      3.6. Key Cache Synchronization .................................40
      3.7. Key Strength ..............................................40
      3.8. Key Wrap ..................................................41
   4. Handoff Vulnerabilities ........................................41
      4.1. EAP Pre-Authentication ....................................43
      4.2. Proactive Key Distribution ................................44
      4.3. AAA Bypass ................................................46
   5. Security Considerations ........................................50
      5.1. Peer and Authenticator Compromise .........................51
      5.2. Cryptographic Negotiation .................................53
      5.3. Confidentiality and Authentication ........................54
      5.4. Key Binding ...............................................59
      5.5. Authorization .............................................60
      5.6. Replay Protection .........................................63
      5.7. Key Freshness .............................................64
      5.8. Key Scope Limitation ......................................66
      5.9. Key Naming ................................................66
      5.10. Denial-of-Service Attacks ................................67
   6. References .....................................................68
      6.1. Normative References ......................................68
      6.2. Informative References ....................................68
   Acknowledgments ...................................................74
   Appendix A - Exported Parameters in Existing Methods ..............75

Top      ToC       Page 3 
1.  Introduction

   The Extensible Authentication Protocol (EAP), defined in [RFC3748],
   was designed to enable extensible authentication for network access
   in situations in which the Internet Protocol (IP) protocol is not
   available.  Originally developed for use with Point-to-Point Protocol
   (PPP) [RFC1661], it has subsequently also been applied to IEEE 802
   wired networks [IEEE-802.1X], Internet Key Exchange Protocol version
   2 (IKEv2) [RFC4306], and wireless networks such as [IEEE-802.11] and
   [IEEE-802.16e].

   EAP is a two-party protocol spoken between the EAP peer and server.
   Within EAP, keying material is generated by EAP authentication
   algorithms, known as "methods".  Part of this keying material can be
   used by EAP methods themselves, and part of this material can be
   exported.  In addition to the export of keying material, EAP methods
   can also export associated parameters such as authenticated peer and
   server identities and a unique EAP conversation identifier, and can
   import and export lower-layer parameters known as "channel binding
   parameters", or simply "channel bindings".

   This document specifies the EAP key hierarchy and provides a
   framework for the transport and usage of keying material and
   parameters generated by EAP methods.  It also provides a detailed
   security analysis, describing the conditions under which the
   requirements described in "Guidance for Authentication,
   Authorization, and Accounting (AAA) Key Management" [RFC4962] can be
   satisfied.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Terminology

   The terms "Cryptographic binding", "Cryptographic separation", "Key
   strength" and "Mutual authentication" are defined in [RFC3748] and
   are used with the same meaning in this document, which also
   frequently uses the following terms:

   4-Way Handshake
      A pairwise Authentication and Key Management Protocol (AKMP)
      defined in [IEEE-802.11], which confirms mutual possession of a
      Pairwise Master Key by two parties and distributes a Group Key.

Top      ToC       Page 4 
   AAA  Authentication, Authorization, and Accounting
      AAA protocols with EAP support include "RADIUS Support for EAP"
      [RFC3579] and "Diameter EAP Application" [RFC4072].  In this
      document, the terms "AAA server" and "backend authentication
      server" are used interchangeably.

   AAA-Key
      The term AAA-Key is synonymous with Master Session Key (MSK).
      Since multiple keys can be transported by AAA, the term is
      potentially confusing and is not used in this document.

   Authenticator
      The entity initiating EAP authentication.

   Backend Authentication Server
      A backend authentication server is an entity that provides an
      authentication service to an authenticator.  When used, this
      server typically executes EAP methods for the authenticator.  This
      terminology is also used in [IEEE-802.1X].

   Channel Binding
      A secure mechanism for ensuring that a subset of the parameters
      transmitted by the authenticator (such as authenticator
      identifiers and properties) are agreed upon by the EAP peer and
      server.  It is expected that the parameters are also securely
      agreed upon by the EAP peer and authenticator via the lower layer
      if the authenticator advertised the parameters.

   Derived Keying Material
      Keys derived from EAP keying material, such as Transient Session
      Keys (TSKs).

   EAP Keying Material
      Keys derived by an EAP method; this includes exported keying
      material (MSK, Extended MSK (EMSK), Initialization Vector (IV)) as
      well as local keying material such as Transient EAP Keys (TEKs).

   EAP Pre-Authentication
      The use of EAP to pre-establish EAP keying material on an
      authenticator prior to arrival of the peer at the access network
      managed by that authenticator.

   EAP Re-Authentication
      EAP authentication between an EAP peer and a server with whom the
      EAP peer shares valid unexpired EAP keying material.

Top      ToC       Page 5 
   EAP Server
      The entity that terminates the EAP authentication method with the
      peer.  In the case where no backend authentication server is used,
      the EAP server is part of the authenticator.  In the case where
      the authenticator operates in pass-through mode, the EAP server is
      located on the backend authentication server.

   Exported Keying Material
      The EAP Master Session Key (MSK), Extended Master Session Key
      (EMSK), and Initialization Vector (IV).

   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.  The EMSK
      MUST be at least as long as the MSK in size.

   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 (Transport Layer Security) [RFC5216], 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 it is
      OPTIONAL for EAP methods to generate it.  However, when it is
      generated, it MUST be unpredictable.

   Keying Material
      Unless otherwise qualified, the term "keying material" refers to
      EAP keying material as well as derived keying material.

   Key Scope
      The parties to whom a key is available.

   Key Wrap
      The encryption of one symmetric cryptographic key in another.  The
      algorithm used for the encryption is called a key wrap algorithm
      or a key encryption algorithm.  The key used in the encryption
      process is called a key-encryption key (KEK).

   Long-Term Credential
      EAP methods frequently make use of long-term secrets in order to
      enable authentication between the peer and server.  In the case of
      a method based on pre-shared key authentication, the long-term
      credential is the pre-shared key.  In the case of a
      public-key-based method, the long-term credential is the
      corresponding private key.

Top      ToC       Page 6 
   Lower Layer
      The lower layer is responsible for carrying EAP frames between the
      peer and authenticator.

   Lower-Layer Identity
      A name used to identify the EAP peer and authenticator within the
      lower layer.

   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.

   Network Access Server (NAS)
      A device that provides an access service for a user to a network.

   Pairwise Master Key (PMK)
      Lower layers use the MSK in a lower-layer dependent manner.  For
      instance, in IEEE 802.11 [IEEE-802.11], Octets 0-31 of the MSK are
      known as the Pairwise Master Key (PMK); the Temporal Key Integrity
      Protocol (TKIP) and Advanced Encryption Standard Counter Mode with
      CBC-MAC Protocol (AES CCMP) ciphersuites derive their Transient
      Session Keys (TSKs) solely from the PMK, whereas the Wired
      Equivalent Privacy (WEP) ciphersuite, as noted in "IEEE 802.1X
      RADIUS Usage Guidelines" [RFC3580], derives its TSKs from both
      halves of the MSK.  In [IEEE-802.16e], the MSK is truncated to 20
      octets for PMK and 20 octets for PMK2.

   Peer
      The entity that responds to the authenticator.  In [IEEE-802.1X],
      this entity is known as the Supplicant.

   Security Association
      A set of policies and cryptographic state used to protect
      information.  Elements of a security association include
      cryptographic keys, negotiated ciphersuites and other parameters,
      counters, sequence spaces, authorization attributes, etc.

   Secure Association Protocol
      An exchange that occurs between the EAP peer and authenticator in
      order to manage security associations derived from EAP exchanges.
      The protocol establishes unicast and (optionally) multicast
      security associations, which include symmetric keys and a context
      for the use of the keys.  An example of a Secure Association
      Protocol is the 4-way handshake defined within [IEEE-802.11].

Top      ToC       Page 7 
   Session-Id
      The EAP Session-Id uniquely identifies an EAP authentication
      exchange between an EAP peer (as identified by the Peer-Id(s)) and
      server (as identified by the Server-Id(s)).  For more information,
      see Section 1.4.

   Transient EAP Keys (TEKs)
      Session keys that 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.  The TEKs are stored locally by the EAP method
      and are not exported.  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.

   Transient Session Keys (TSKs)
      Keys used to protect data exchanged after EAP authentication has
      successfully completed using the ciphersuite negotiated between
      the EAP peer and authenticator.

1.3.  Overview

   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 Protocol
               2a: Unicast Secure Association
               2b: Multicast Secure Association (optional)

   Of these phases, phase 0, 1b, and 2 are handled external to EAP.
   phases 0 and 2 are handled by the lower-layer protocol, and phase 1b
   is typically handled by a AAA protocol.

   In the discovery phase (phase 0), peers locate authenticators and
   discover their capabilities.  A peer can locate an authenticator
   providing access to a particular network, or a peer can locate an
   authenticator behind a bridge with which it desires to establish a
   Secure Association.  Discovery can occur manually or automatically,
   depending on the lower layer over which EAP runs.

Top      ToC       Page 8 
   The authentication phase (phase 1) can begin once the peer and
   authenticator discover each other.  This phase, if it occurs, 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.

   An additional step (phase 1b) is needed in deployments that 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 (see Section 1.6.1),
   where a backend authentication server is present, all keying material
   needed by the lower layer is transported from the EAP server to the
   authenticator.  Since existing TSK derivation and transport
   techniques depend solely on the MSK, in existing implementations,
   this is the only keying material replicated in the AAA key transport
   phase 1b.

   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).  The Secure Association
   Protocol exchange (phase 2) 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 1.

   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)      |                               |
    |                               |                               |

Top      ToC       Page 9 
                  Figure 1: Conversation Overview

1.3.1.  Examples

   Existing EAP lower layers implement phase 0, 2a, and 2b in different
   ways:

   PPP
      The Point-to-Point Protocol (PPP), defined in [RFC1661], does not
      support discovery, nor does it include a Secure Association
      Protocol.

   PPPoE
      PPP over Ethernet (PPPoE), defined in [RFC2516], includes support
      for a Discovery stage (phase 0).  In this step, the EAP peer sends
      a PPPoE Active Discovery Initiation (PADI) packet to the broadcast
      address, indicating the service it is requesting.  The Access
      Concentrator replies with a PPPoE Active Discovery Offer (PADO)
      packet containing its name, the service name, and an indication of
      the services offered by the concentrator.  The discovery phase is
      not secured.  PPPoE, like PPP, does not include a Secure
      Association Protocol.

   IKEv2
      Internet Key Exchange v2 (IKEv2), defined in [RFC4306], includes
      support for EAP and handles the establishment of unicast security
      associations (phase 2a).  However, the establishment of multicast
      security associations (phase 2b) typically does not involve EAP
      and needs to be handled by a group key management protocol such as
      Group Domain of Interpretation (GDOI) [RFC3547], Group Secure
      Association Key Management Protocol (GSAKMP) [RFC4535], Multimedia
      Internet KEYing  (MIKEY) [RFC3830], or Group Key Distribution
      Protocol (GKDP) [GKDP].  Several mechanisms have been proposed for
      the discovery of IPsec security gateways.  [RFC2230] discusses the
      use of Key eXchange (KX) Resource Records (RRs) for IPsec gateway
      discovery; while KX RRs are supported by many Domain Name Service
      (DNS) server implementations, they have not yet been widely
      deployed.  Alternatively, DNS SRV RRs [RFC2782] can be used for
      this purpose.  Where DNS is used for gateway location, DNS
      security mechanisms such as DNS Security (DNSSEC) ([RFC4033],
      [RFC4035]), TSIG [RFC2845], and Simple Secure Dynamic Update
      [RFC3007] are available.

   IEEE 802.11
      IEEE 802.11, defined in [IEEE-802.11], handles discovery via the
      Beacon and Probe Request/Response mechanisms.  IEEE 802.11 Access
      Points (APs) periodically announce their Service Set Identifiers
      (SSIDs) as well as capabilities using Beacon frames.  Stations can

Top      ToC       Page 10 
      query for APs by sending a Probe Request.  Neither Beacon nor
      Probe Request/Response frames are secured.  The 4-way handshake
      defined in [IEEE-802.11] enables the derivation of unicast (phase
      2a) and multicast/broadcast (phase 2b) secure associations.  Since
      the group key exchange transports a group key from the AP to the
      station, two 4-way handshakes can be needed in order to support
      peer-to-peer communications.  A proof of the security of the IEEE
      802.11 4-way handshake, when used with EAP-TLS, is provided in
      [He].

   IEEE 802.1X
      IEEE 802.1X-2004, defined in [IEEE-802.1X], does not support
      discovery (phase 0), nor does it provide for derivation of unicast
      or multicast secure associations.

1.4.  EAP Key Hierarchy

   As illustrated in Figure 2, the EAP method key derivation has, at the
   root, the long-term credential utilized by the selected EAP method.
   If authentication is based on a pre-shared key, the parties store the
   EAP method to be used and the pre-shared key.  The EAP server also
   stores the peer's identity as well as additional information.  This
   information is typically used outside of the EAP method to determine
   whether to grant access to a service.  The peer stores information
   necessary to choose which secret to use for which service.

   If authentication is based on proof of possession of the private key
   corresponding to the public key contained within a certificate, the
   parties store the EAP method to be used and the trust anchors used to
   validate the certificates.  The EAP server also stores the peer's
   identity, and the peer stores information necessary to choose which
   certificate to use for which service.  Based on the long-term
   credential established between the peer and the server, methods
   derive two types of EAP keying material:

      (a) Keying material calculated locally by the EAP method but not
          exported, such as the Transient EAP Keys (TEKs).

      (b) Keying material exported by the EAP method: Master Session Key
          (MSK), Extended Master Session Key (EMSK), Initialization
          Vector (IV).

   As noted in [RFC3748] Section 7.10:

      In order to provide keying material for use in a subsequently
      negotiated ciphersuite, an EAP method supporting key derivation
      MUST export a Master Session Key (MSK) of at least 64 octets, and
      an Extended Master Session Key (EMSK) of at least 64 octets.

Top      ToC       Page 11 
   EAP methods also MAY export the IV; however, the use of the IV is
   deprecated.  The EMSK MUST NOT be provided to an entity outside the
   EAP server or peer, nor is it permitted to pass any quantity to an
   entity outside the EAP server or peer from which the EMSK could be
   computed without breaking some cryptographic assumption, such as
   inverting a one-way function.

   EAP methods supporting key derivation and mutual authentication
   SHOULD export a method-specific EAP conversation identifier known as
   the Session-Id, as well as one or more method-specific peer
   identifiers (Peer-Id(s)) and MAY export one or more method-specific
   server identifiers (Server-Id(s)).  EAP methods MAY also support the
   import and export of channel binding parameters.  EAP method
   specifications developed after the publication of this document MUST
   define the Peer-Id, Server-Id, and Session-Id.  The Peer-Id(s) and
   Server-Id(s), when provided, identify the entities involved in
   generating EAP keying material.  For existing EAP methods, the
   Peer-Id, Server-Id, and Session-Id are defined in Appendix A.

Top      ToC       Page 12 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
|                                                         |            ^
|                EAP Method                               |            |
|                                                         |            |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+   |            |
| |                                 |   |             |   |            |
| |       EAP Method Key            |<->| Long-Term   |   |            |
| |         Derivation              |   | Credential  |   |            |
| |                                 |   |             |   |            |
| |                                 |   +-+-+-+-+-+-+-+   |  Local to  |
| |                                 |                     |       EAP  |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     |     Method |
|   |             |               |                       |            |
|   |             |               |                       |            |
|   |             |               |                       |            |
|   |             |               |                       |            |
|   |         +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ |            |
|   |         | TEK       | |MSK, EMSK  | |IV           | |            |
|   |         |Derivation | |Derivation | |Derivation   | |            |
|   |         |           | |           | |(Deprecated) | |            |
|   |         +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ |            |
|   |               ^             |               |       |            |
|   |               |             |               |       |            V
+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+         ---+
    |               |             |               |                    ^
    |               |             |               |           Exported |
    | Peer-Id(s),   | channel     | MSK (64+B)    | IV (64B)      by   |
    | Server-Id(s), | bindings    | EMSK (64+B)   | (Optional)    EAP  |
    | Session-Id    | & Result    |               |             Method |
    V               V             V               V                    V

     Figure 2:  EAP Method Parameter Import/Export

   Peer-Id

      If an EAP method that generates keys authenticates one or more
      method-specific peer identities, those identities are exported by
      the method as the Peer-Id(s).  It is possible for more than one
      Peer-Id to be exported by an EAP method.  Not all EAP methods
      provide a method-specific peer identity; where this is not
      defined, the Peer-Id is the null string.  In EAP methods that do
      not support key generation, the Peer-Id MUST be the null string.
      Where an EAP method that derives keys does not provide a Peer-Id,
      the EAP server will not authenticate the identity of the EAP peer
      with which it derived keying material.

Top      ToC       Page 13 
   Server-Id

      If an EAP method that generates keys authenticates one or more
      method-specific server identities, those identities are exported
      by the method as the Server-Id(s).  It is possible for more than
      one Server-Id to be exported by an EAP method.  Not all EAP
      methods provide a method-specific server identity; where this is
      not defined, the Server-Id is the null string.  If the EAP method
      does not generate keying material, the Server-Id MUST be the null
      string.  Where an EAP method that derives keys does not provide a
      Server-Id, the EAP peer will not authenticate the identity of the
      EAP server with which it derived EAP keying material.

   Session-Id

      The Session-Id uniquely identifies an EAP session between an EAP
      peer (as identified by the Peer-Id) and server (as identified by
      the Server-Id).  Where non-expanded EAP Type Codes are used (EAP
      Type Code not equal to 254), the EAP Session-Id is the
      concatenation of the single octet EAP Type Code and a temporally
      unique identifier obtained from the method (known as the
      Method-Id):


      Session-Id = Type-Code || Method-Id

      Where expanded EAP Type Codes are used, the EAP Session-Id
      consists of the Expanded Type Code (including the Type, Vendor-Id
      (in network byte order) and Vendor-Type fields (in network byte
      order) defined in [RFC3748] Section 5.7), concatenated with a
      temporally unique identifier obtained from the method (Method-Id):

      Session-Id = 0xFE || Vendor-Id || Vendor-Type || Method-Id

      The Method-Id is typically constructed from nonces or counters
      used within the EAP method exchange.  The inclusion of the Type
      Code or Expanded Type Code in the EAP Session-Id ensures that each
      EAP method has a distinct Session-Id space.  Since an EAP session
      is not bound to a particular authenticator or specific ports on
      the peer and authenticator, the authenticator port or identity are
      not included in the Session-Id.

Top      ToC       Page 14 
   Channel Binding

      Channel binding is the process by which lower-layer parameters are
      verified for consistency between the EAP peer and server.  In
      order to avoid introducing media dependencies, EAP methods that
      transport channel binding parameters MUST treat this data as
      opaque octets.  See Section 5.3.3 for further discussion.

1.4.1.  Key Naming

   Each key created within the EAP key management framework has a name
   (a unique identifier), as well as a scope (the parties to whom the
   key is available).  The scope of exported keying material and TEKs is
   defined by the authenticated method-specific peer identities
   (Peer-Id(s)) and the authenticated server identities (Server-Id(s)),
   where available.

   MSK and EMSK Names
        The MSK and EMSK are exported by the EAP peer and EAP server,
        and MUST be named using the EAP Session-Id and a binary or
        textual indication of the EAP keying material being referred to.

   PMK Name
        This document does not specify a naming scheme for the Pairwise
        Master Key (PMK).  The PMK is only identified by the name of the
        key from which it is derived.

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

   TEK Name
        Transient EAP Keys (TEKs) MAY be named; their naming is
        specified in the EAP method specification.

   TSK Name
        Transient Session Keys (TSKs) are typically named.  Their naming
        is specified in the lower layer so that the correct set of TSKs
        can be identified for processing a given packet.

Top      ToC       Page 15 
1.5.  Security Goals

   The goal of the EAP conversation is to derive fresh session keys
   between the EAP peer and authenticator that are known only to those
   parties, and for both the EAP peer and authenticator to demonstrate
   that they are authorized to perform their roles either by each other
   or by a trusted third party (the backend authentication server).

   Completion of an EAP method exchange (phase 1a) supporting key
   derivation results in the derivation of EAP keying material (MSK,
   EMSK, TEKs) known only to the EAP peer (identified by the Peer-Id(s))
   and EAP server (identified by the Server-Id(s)).  Both the EAP peer
   and EAP server know this keying material to be fresh.  The Peer-Id
   and Server-Id are discussed in Sections 1.4, 2.4, and 2.5 as well as
   in Appendix A.  Key freshness is discussed in Sections 3.4, 3.5, and
   5.7.

   Completion of the AAA exchange (phase 1b) results in the transport of
   keying material from the EAP server (identified by the Server-Id(s))
   to the EAP authenticator (identified by the NAS-Identifier) without
   disclosure to any other party.  Both the EAP server and EAP
   authenticator know this keying material to be fresh.  Disclosure
   issues are discussed in Sections 3.8 and 5.3; security properties of
   AAA protocols are discussed in Sections 5.1 - 5.9.

   The backend authentication server is trusted to transport keying
   material only to the authenticator that was established with the
   peer, and it is trusted to transport that keying material to no other
   parties.  In many systems, EAP keying material established by the EAP
   peer and EAP server are combined with publicly available data to
   derive other keys.  The backend authentication server is trusted to
   refrain from deriving these same keys or acting as a
   man-in-the-middle even though it has access to the keying material
   that is needed to do so.

   The authenticator is also a trusted party.  The authenticator is
   trusted not to distribute keying material provided by the backend
   authentication server to any other parties.  If the authenticator
   uses a key derivation function to derive additional keying material,
   the authenticator is trusted to distribute the derived keying
   material only to the appropriate party that is known to the peer, and
   no other party.  When this approach is used, care must be taken to
   ensure that the resulting key management system meets all of the
   principles in [RFC4962], confirming that keys used to protect data
   are to be known only by the peer and authenticator.

Top      ToC       Page 16 
   Completion of the Secure Association Protocol (phase 2) results in
   the derivation or transport of Transient Session Keys (TSKs) known
   only to the EAP peer (identified by the Peer-Id(s)) and authenticator
   (identified by the NAS-Identifier).  Both the EAP peer and
   authenticator know the TSKs to be fresh.  Both the EAP peer and
   authenticator demonstrate that they are authorized to perform their
   roles.  Authorization issues are discussed in Sections 4.3.2 and 5.5;
   security properties of Secure Association Protocols are discussed in
   Section 3.1.

1.6.  EAP Invariants

   Certain basic characteristics, known as "EAP Invariants", hold true
   for EAP implementations:

      Mode independence
      Media independence
      Method independence
      Ciphersuite independence

1.6.1.  Mode Independence

   EAP is typically deployed to support extensible network access
   authentication in situations where a peer desires network access via
   one or more authenticators.  Where authenticators are deployed
   standalone, the EAP conversation occurs between the peer and
   authenticator, and the authenticator locally implements one or more
   EAP methods.  However, when utilized in "pass-through" mode, EAP
   enables the deployment of new authentication methods without
   requiring the development of new code on the authenticator.

   While the authenticator can implement some EAP methods locally and
   use those methods to authenticate local users, it can at the same
   time act as a pass-through for other users and methods, forwarding
   EAP packets back and forth between the backend authentication server
   and the peer.  This is accomplished by encapsulating EAP packets
   within the Authentication, Authorization, and Accounting (AAA)
   protocol spoken between the authenticator and backend authentication
   server.  AAA protocols supporting EAP include RADIUS [RFC3579] and
   Diameter [RFC4072].

   It is a fundamental property of EAP that at the EAP method layer, the
   conversation between the EAP peer and server is unaffected by whether
   the EAP authenticator is operating in "pass-through" mode.  EAP
   methods operate identically in all aspects, including key derivation
   and parameter import/export, regardless of whether or not the
   authenticator is operating as a pass-through.

Top      ToC       Page 17 
   The successful completion of an EAP method that supports key
   derivation results in the export of EAP keying material and
   parameters on the EAP peer and server.  Even though the EAP peer or
   server can import channel binding parameters that can include the
   identity of the EAP authenticator, this information is treated as
   opaque octets.  As a result, within EAP, the only relevant identities
   are the Peer-Id(s) and Server-Id(s).  Channel binding parameters are
   only interpreted by the lower layer.

   Within EAP, the primary function of the AAA protocol is to maintain
   the principle of mode independence.  As far as the EAP peer is
   concerned, its conversation with the EAP authenticator, and all
   consequences of that conversation, are identical, regardless of the
   authenticator mode of operation.

1.6.2.  Media Independence

   One of the goals of EAP is to allow EAP methods to function on any
   lower layer meeting the criteria outlined in [RFC3748] Section 3.1.
   For example, as described in [RFC3748], EAP authentication can be run
   over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and
   wireless networks such as 802.11 [IEEE-802.11] and 802.16
   [IEEE-802.16e].

   In order to maintain media independence, it is necessary for EAP to
   avoid consideration of media-specific elements.  For example, EAP
   methods cannot be assumed to have knowledge of the lower layer over
   which they are transported, and cannot be restricted to identifiers
   associated with a particular usage environment (e.g., Medium Access
   Control (MAC) addresses).

   Note that media independence can be retained within EAP methods that
   support channel binding or method-specific identification.  An EAP
   method need not be aware of the content of an identifier in order to
   use it.  This enables an EAP method to use media-specific identifiers
   such as MAC addresses without compromising media independence.
   Channel binding parameters are treated as opaque octets by EAP
   methods so that handling them does not require media-specific
   knowledge.

Top      ToC       Page 18 
1.6.3.  Method Independence

   By enabling pass-through, authenticators can support any method
   implemented on the peer and server, not just locally implemented
   methods.  This allows the authenticator to avoid having to implement
   the EAP methods configured for use by peers.  In fact, since a
   pass-through authenticator need not implement any EAP methods at all,
   it cannot be assumed to support any EAP method-specific code.  As
   noted in [RFC3748] Section 2.3:

      Compliant pass-through authenticator implementations MUST by
      default forward EAP packets of any Type.

   This is useful where there is no single EAP method that is both
   mandatory to implement and offers acceptable security for the media
   in use.  For example, the [RFC3748] mandatory-to-implement EAP method
   (MD5-Challenge) does not provide dictionary attack resistance, mutual
   authentication, or key derivation, and as a result, is not
   appropriate for use in Wireless Local Area Network (WLAN)
   authentication [RFC4017].  However, despite this, it is possible for
   the peer and authenticator to interoperate as long as a suitable EAP
   method is supported both on the EAP peer and server.

1.6.4.  Ciphersuite Independence

   Ciphersuite Independence is a requirement for media independence.
   Since lower-layer ciphersuites vary between media, media independence
   requires that exported EAP keying material be large enough (with
   sufficient entropy) to handle any ciphersuite.

   While EAP methods can negotiate the ciphersuite used in protection of
   the EAP conversation, the ciphersuite used for the protection of the
   data exchanged after EAP authentication has completed is negotiated
   between the peer and authenticator within the lower layer, outside of
   EAP.

   For example, within PPP, the ciphersuite is negotiated within the
   Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
   authentication is completed.  Within [IEEE-802.11], the AP
   ciphersuites are advertised in the Beacon and Probe Responses prior
   to EAP authentication and are securely verified during a 4-way
   handshake exchange.

Top      ToC       Page 19 
   Since the ciphersuites used to protect data depend on the lower
   layer, requiring that EAP methods have knowledge of lower-layer
   ciphersuites would compromise the principle of media independence.
   As a result, methods export EAP keying material that is ciphersuite
   independent.  Since ciphersuite negotiation occurs in the lower
   layer, there is no need for lower-layer ciphersuite negotiation
   within EAP.

   In order to allow a ciphersuite to be usable within the EAP keying
   framework, the ciphersuite specification needs to describe how TSKs
   suitable for use with the ciphersuite are derived from exported EAP
   keying material.  To maintain method independence, algorithms for
   deriving TSKs MUST NOT depend on the EAP method, although algorithms
   for TEK derivation MAY be specific to the EAP method.

   Advantages of ciphersuite-independence include:

   Reduced update requirements
        Ciphersuite independence enables EAP methods to be used with new
        ciphersuites without requiring the methods to be updated.  If
        EAP methods were to specify how to derive transient session keys
        for each ciphersuite, they would need to be updated each time a
        new ciphersuite is developed.  In addition, backend
        authentication servers might not be usable with all EAP-capable
        authenticators, since the backend authentication server would
        also need to be updated each time support for a new ciphersuite
        is added to the authenticator.

   Reduced EAP method complexity
        Ciphersuite independence enables EAP methods to avoid having to
        include ciphersuite-specific code.  Requiring each EAP method to
        include ciphersuite-specific code for transient session key
        derivation would increase method complexity and result in
        duplicated effort.

   Simplified configuration
        Ciphersuite independence enables EAP method implementations on
        the peer and server to avoid having to configure
        ciphersuite-specific parameters.  The ciphersuite is negotiated
        between the peer and authenticator outside of EAP.  Where the
        authenticator operates in "pass-through" mode, the EAP server is
        not a party to this negotiation, nor is it involved in the data
        flow between the EAP peer and authenticator.  As a result, the
        EAP server does not have knowledge of the ciphersuites and
        negotiation policies implemented by the peer and authenticator,
        nor is it aware of the ciphersuite negotiated between them.  For
        example, since Encryption Control Protocol (ECP) negotiation
        occurs after authentication, when run over PPP, the EAP peer and

Top      ToC       Page 20 
        server cannot anticipate the negotiated ciphersuite, and
        therefore, this information cannot be provided to the EAP
        method.



(page 20 continued on part 2)

Next RFC Part