GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc5247

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.

Aboba, et al. Standards Track [Page 1] RFC 5247 EAP Key Management Framework August 2008

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

Aboba, et al. Standards Track [Page 2] RFC 5247 EAP Key Management Framework August 2008

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.

Aboba, et al. Standards Track [Page 3] RFC 5247 EAP Key Management Framework August 2008

 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.

Aboba, et al. Standards Track [Page 4] RFC 5247 EAP Key Management Framework August 2008

 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.

Aboba, et al. Standards Track [Page 5] RFC 5247 EAP Key Management Framework August 2008

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

Aboba, et al. Standards Track [Page 6] RFC 5247 EAP Key Management Framework August 2008

 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.

Aboba, et al. Standards Track [Page 7] RFC 5247 EAP Key Management Framework August 2008

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

Aboba, et al. Standards Track [Page 8] RFC 5247 EAP Key Management Framework August 2008

                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

Aboba, et al. Standards Track [Page 9] RFC 5247 EAP Key Management Framework August 2008

    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.

Aboba, et al. Standards Track [Page 10] RFC 5247 EAP Key Management Framework August 2008

 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.

Aboba, et al. Standards Track [Page 11] RFC 5247 EAP Key Management Framework August 2008

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ —+

EAP Method
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
EAP Method Key Long-Term
Derivation Credential
+-+-+-+-+-+-+-+ Local to
EAP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Method
+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+
TEK MSK, EMSK IV
Derivation Derivation Derivation
(Deprecated)
+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+

+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ —+

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

Aboba, et al. Standards Track [Page 12] RFC 5247 EAP Key Management Framework August 2008

 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.

Aboba, et al. Standards Track [Page 13] RFC 5247 EAP Key Management Framework August 2008

 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.

Aboba, et al. Standards Track [Page 14] RFC 5247 EAP Key Management Framework August 2008

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.

Aboba, et al. Standards Track [Page 15] RFC 5247 EAP Key Management Framework August 2008

 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.

Aboba, et al. Standards Track [Page 16] RFC 5247 EAP Key Management Framework August 2008

 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.

Aboba, et al. Standards Track [Page 17] RFC 5247 EAP Key Management Framework August 2008

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.

Aboba, et al. Standards Track [Page 18] RFC 5247 EAP Key Management Framework August 2008

 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

Aboba, et al. Standards Track [Page 19] RFC 5247 EAP Key Management Framework August 2008

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

2. Lower-Layer Operation

 On completion of EAP authentication, EAP keying material and
 parameters exported by the EAP method are provided to the lower layer
 and AAA layer (if present).  These include the Master Session Key
 (MSK), Extended Master Session Key (EMSK), Peer-Id(s), Server-Id(s),
 and Session-Id.  The Initialization Vector (IV) is deprecated, but
 might be provided.
 In order to preserve the security of EAP keying material derived
 within methods, lower layers MUST NOT export keys passed down by EAP
 methods.  This implies that EAP keying material passed down to a
 lower layer is for the exclusive use of that lower layer and MUST NOT
 be used within another lower layer.  This prevents compromise of one
 lower layer from compromising other applications using EAP keying
 material.
 EAP keying material provided to a lower layer MUST NOT be transported
 to another entity.  For example, EAP keying material passed down to
 the EAP peer lower layer MUST NOT leave the peer;  EAP keying
 material passed down or transported to the EAP authenticator lower
 layer MUST NOT leave the authenticator.
 On the EAP server, keying material and parameters requested by and
 passed down to the AAA layer MAY be replicated to the AAA layer on
 the authenticator (with the exception of the EMSK).  On the
 authenticator, the AAA layer provides the replicated keying material
 and parameters to the lower layer over which the EAP authentication
 conversation took place.  This enables mode independence to be
 maintained.
 The EAP layer, as well as the peer and authenticator layers, MUST NOT
 modify or cache keying material or parameters (including channel
 bindings) passing in either direction between the EAP method layer
 and the lower layer or AAA layer.

2.1. Transient Session Keys

 Where explicitly supported by the lower layer, lower layers MAY cache
 keying material, including exported EAP keying material and/or TSKs;
 the structure of this key cache is defined by the lower layer.  So as
 to enable interoperability, new lower-layer specifications MUST
 describe key caching behavior.  Unless explicitly specified by the
 lower layer, the EAP peer, server, and authenticator MUST assume that

Aboba, et al. Standards Track [Page 20] RFC 5247 EAP Key Management Framework August 2008

 peers and authenticators do not cache keying material.  Existing EAP
 lower layers and AAA layers handle the generation of transient
 session keys and caching of EAP keying material in different ways:
 IEEE 802.1X-2004
      When used with wired networks, IEEE 802.1X-2004 [IEEE-802.1X]
      does not support link-layer ciphersuites, and as a result, it
      does not provide for the generation of TSKs or caching of EAP
      keying material and parameters.  Once EAP authentication
      completes, it is assumed that EAP keying material and parameters
      are discarded; on IEEE 802 wired networks, there is no
      subsequent Secure Association Protocol exchange.  Perfect
      Forward Secrecy (PFS) is only possible if the negotiated EAP
      method supports this.
 PPP
      PPP, defined in [RFC1661], does not include support for a Secure
      Association Protocol, nor does it support caching of EAP keying
      material or parameters.  PPP ciphersuites derive their TSKs
      directly from the MSK, as described in [RFC2716] Section 3.5.
      This is NOT RECOMMENDED, since if PPP were to support caching of
      EAP keying material, this could result in TSK reuse.  As a
      result, once the PPP session is terminated, EAP keying material
      and parameters MUST be discarded.  Since caching of EAP keying
      material is not permitted within PPP, there is no way to handle
      TSK re-key without EAP re-authentication.  Perfect Forward
      Secrecy (PFS) is only possible if the negotiated EAP method
      supports this.
 IKEv2
      IKEv2, defined in [RFC4306], only uses the MSK for
      authentication purposes and not key derivation.  The EMSK, IV,
      Peer-Id, Server-Id or Session-Id are not used.  As a result, the
      TSKs derived by IKEv2 are cryptographically independent of the
      EAP keying material and re-key of IPsec SAs can be handled
      without requiring EAP re-authentication.  Within IKEv2, it is
      possible to negotiate PFS, regardless of which EAP method is
      negotiated.  IKEv2 as specified in [RFC4306] does not cache EAP
      keying material or parameters; once IKEv2 authentication
      completes, it is assumed that EAP keying material and parameters
      are discarded.  The Session-Timeout Attribute is therefore
      interpreted as a limit on the VPN session time, rather than an
      indication of the MSK key lifetime.
 IEEE 802.11
      IEEE 802.11 enables caching of the MSK, but not the EMSK, IV,
      Peer-Id, Server-Id, or Session-Id.  More details about the
      structure of the cache are available in [IEEE-802.11].  In IEEE

Aboba, et al. Standards Track [Page 21] RFC 5247 EAP Key Management Framework August 2008

      802.11, TSKs are derived from the MSK using a Secure Association
      Protocol known as the 4-way handshake, which includes a nonce
      exchange.  This guarantees TSK freshness even if the MSK is
      reused.  The 4-way handshake also enables TSK re-key without EAP
      re-authentication.  PFS is only possible within IEEE 802.11 if
      caching is not enabled and the negotiated EAP method supports
      PFS.
 IEEE 802.16e
      IEEE 802.16e, defined in [IEEE-802.16e], supports caching of the
      MSK, but not the EMSK, IV, Peer-Id, Server-Id, or Session-Id.
      IEEE 802.16e supports a Secure Association Protocol in which
      TSKs are chosen by the authenticator without any contribution by
      the peer.  The TSKs are encrypted, authenticated, and integrity
      protected using the MSK and are transported from the
      authenticator to the peer.  TSK re-key is possible without EAP
      re-authentication.  PFS is not possible even if the negotiated
      EAP method supports it.
 AAA
      Existing implementations and specifications for RADIUS/EAP
      [RFC3579] or Diameter EAP [RFC4072] do not support caching of
      keying material or parameters.  In existing AAA clients, proxy
      and server implementations, exported EAP keying material (MSK,
      EMSK, and IV), as well as parameters and derived keys are not
      cached and MUST be presumed lost after the AAA exchange
      completes.
      In order to avoid key reuse, the AAA layer MUST delete
      transported keys once they are sent.  The AAA layer MUST NOT
      retain keys that it has previously sent.  For example, a AAA
      layer that has transported the MSK MUST delete it, and keys MUST
      NOT be derived from the MSK from that point forward.

2.2. Authenticator and Peer Architecture

 This specification does not impose constraints on the architecture of
 the EAP authenticator or peer.  For example, any of the authenticator
 architectures described in [RFC4118] can be used.  As a result, lower
 layers need to identify EAP peers and authenticators unambiguously,
 without incorporating implicit assumptions about peer and
 authenticator architectures.

Aboba, et al. Standards Track [Page 22] RFC 5247 EAP Key Management Framework August 2008

 For example, it is possible for multiple base stations and a
 "controller" (e.g., WLAN switch) to comprise a single EAP
 authenticator.  In such a situation, the "base station identity" is
 irrelevant to the EAP method conversation, except perhaps as an
 opaque blob to be used in channel binding.  Many base stations can
 share the same authenticator identity.  An EAP authenticator or peer:
    (a) can contain one or more physical or logical ports;
    (b) can advertise itself as one or more "virtual" authenticators
        or peers;
    (c) can utilize multiple CPUs;
    (d) can support clustering services for load balancing or
        failover.
 Both the EAP peer and authenticator can have more than one physical
 or logical port.  A peer can simultaneously access the network via
 multiple authenticators, or via multiple physical or logical ports on
 a given authenticator.  Similarly, an authenticator can offer network
 access to multiple peers, each via a separate physical or logical
 port.  When a single physical authenticator advertises itself as
 multiple virtual authenticators, it is possible for a single physical
 port to belong to multiple virtual authenticators.
 An authenticator can be configured to communicate with more than one
 EAP server, each of which is configured to communicate with a subset
 of the authenticators.  The situation is illustrated in Figure 3.

2.3. Authenticator Identification

 The EAP method conversation is between the EAP peer and server.  The
 authenticator identity, if considered at all by the EAP method, is
 treated as an opaque blob for the purpose of channel binding (see
 Section 5.3.3).  However, the authenticator identity is important in
 two other exchanges - the AAA protocol exchange and the Secure
 Association Protocol conversation.
 The AAA conversation is between the EAP authenticator and the backend
 authentication server.  From the point of view of the backend
 authentication server, keying material and parameters are transported
 to the EAP authenticator identified by the NAS-Identifier Attribute.
 Since an EAP authenticator MUST NOT share EAP keying material or
 parameters with another party, if the EAP peer or backend
 authentication server detects use of EAP keying material and
 parameters outside the scope defined by the NAS-Identifier, the
 keying material MUST be considered compromised.

Aboba, et al. Standards Track [Page 23] RFC 5247 EAP Key Management Framework August 2008

 The Secure Association Protocol conversation is between the peer and
 the authenticator.  For lower layers that support key caching, it is
 particularly important for the EAP peer, authenticator, and backend
 server to have a consistent view of the usage scope of the
 transported keying material.  In order to enable this, it is
 RECOMMENDED that the Secure Association Protocol explicitly
 communicate the usage scope of the EAP keying material passed down to
 the lower layer, rather than implicitly assuming that this is defined
 by the authenticator and peer endpoint addresses.
                   +-+-+-+-+
                   | EAP   |
                   | Peer  |
                   +-+-+-+-+
                     | | |  Peer Ports
                    /  |  \
                   /   |   \
                  /    |    \
                 /     |     \
                /      |      \
               /       |       \
              /        |        \
             /         |         \     Authenticator
          | | |      | | |      | | |   Ports
        +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
        |       |  |       |  |       |
        | Auth1 |  | Auth2 |  | Auth3 |
        |       |  |       |  |       |
        +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
             \        | \         |
              \       |  \        |
               \      |   \       |
 EAP over AAA   \     |    \      |
   (optional)    \    |     \     |
                  \   |      \    |
                   \  |       \   |
                    \ |        \  |
                 +-+-+-+-+-+  +-+-+-+-+-+  Backend
                 |  EAP    |  |  EAP    |  Authentication
                 | Server1 |  | Server2 |  Servers
                 +-+-+-+-+-+  +-+-+-+-+-+
 Figure 3: Relationship between EAP Peer, Authenticator, and Server
 Since an authenticator can have multiple ports, the scope of the
 authenticator key cache cannot be described by a single endpoint
 address.  Similarly, where a peer can have multiple ports and sharing
 of EAP keying material and parameters between peer ports of the same

Aboba, et al. Standards Track [Page 24] RFC 5247 EAP Key Management Framework August 2008

 link type is allowed, the extent of the peer key cache cannot be
 communicated by using a single endpoint address.  Instead, it is
 RECOMMENDED that the EAP peer and authenticator consistently identify
 themselves utilizing explicit identifiers, rather than endpoint
 addresses or port identifiers.
 AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
 a mechanism for the identification of AAA clients; since the EAP
 authenticator and AAA client MUST be co-resident, this mechanism is
 applicable to the identification of EAP authenticators.
 RADIUS [RFC2865] requires that an Access-Request packet contain one
 or more of the NAS-Identifier, NAS-IP-Address, and NAS-IPv6-Address
 attributes.  Since a NAS can have more than one IP address, the
 NAS-Identifier Attribute is RECOMMENDED for explicit identification
 of the authenticator, both within the AAA protocol exchange and the
 Secure Association Protocol conversation.
 Problems that can arise where the peer and authenticator implicitly
 identify themselves using endpoint addresses include the following:
 (a)  It is possible that the peer will not be able to determine which
      authenticator ports are associated with which authenticators.
      As a result, the EAP peer will be unable to utilize the
      authenticator key cache in an efficient way, and will also be
      unable to determine whether EAP keying material has been shared
      outside its authorized scope, and therefore needs to be
      considered compromised.
 (b)  It is possible that the authenticator will not be able to
      determine which peer ports are associated with which peers,
      preventing the peer from communicating with it utilizing
      multiple peer ports.
 (c)  It is possible that the peer will not be able to determine with
      which virtual authenticator it is communicating.  For example,
      multiple virtual authenticators can share a MAC address, but
      utilize different NAS-Identifiers.
 (d)  It is possible that the authenticator will not be able to
      determine with which virtual peer it is communicating.  Multiple
      virtual peers can share a MAC address, but utilize different
      Peer-Ids.
 (e)  It is possible that the EAP peer and server will not be able to
      verify the authenticator identity via channel binding.

Aboba, et al. Standards Track [Page 25] RFC 5247 EAP Key Management Framework August 2008

 For example, problems (a), (c), and (e) occur in [IEEE-802.11], which
 utilizes peer and authenticator MAC addresses within the 4-way
 handshake.  Problems (b) and (d) do not occur since [IEEE-802.11]
 only allows a virtual peer to utilize a single port.
 The following steps enable lower-layer identities to be securely
 verified by all parties:
 (f)  Specify the lower-layer parameters used to identify the
      authenticator and peer.  As noted earlier, endpoint or port
      identifiers are not recommended for identification of the
      authenticator or peer when it is possible for them to have
      multiple ports.
 (g)  Communicate the lower-layer identities between the peer and
      authenticator within phase 0.  This allows the peer and
      authenticator to determine the key scope if a key cache is
      utilized.
 (h)  Communicate the lower-layer authenticator identity between the
      authenticator and backend authentication server within the NAS-
      Identifier Attribute.
 (i)  Include the lower-layer identities within channel bindings (if
      supported) in phase 1a, ensuring that they are communicated
      between the EAP peer and server.
 (j)  Support the integrity-protected exchange of identities within
      phase 2a.
 (k)  Utilize the advertised lower-layer identities to enable the peer
      and authenticator to verify that keys are maintained within the
      advertised scope.

2.3.1. Virtual Authenticators

 When a single physical authenticator advertises itself as multiple
 virtual authenticators, if the virtual authenticators do not maintain
 logically separate key caches, then by authenticating to one virtual
 authenticator, the peer can gain access to the other virtual
 authenticators sharing a key cache.

Aboba, et al. Standards Track [Page 26] RFC 5247 EAP Key Management Framework August 2008

 For example, where a physical authenticator implements "Guest" and
 "Corporate Intranet" virtual authenticators, an attacker acting as a
 peer could authenticate with the "Guest" virtual authenticator and
 derive EAP keying material.  If the "Guest" and "Corporate Intranet"
 virtual authenticators share a key cache, then the peer can utilize
 the EAP keying material derived for the "Guest" network to obtain
 access to the "Corporate Intranet" network.
 The following steps can be taken to mitigate this vulnerability:
 (a)  Authenticators are REQUIRED to cache associated authorizations
      along with EAP keying material and parameters and to apply
      authorizations to the peer on each network access, regardless of
      which virtual authenticator is being accessed.  This ensures
      that an attacker cannot obtain elevated privileges even where
      the key cache is shared between virtual authenticators, and a
      peer obtains access to one virtual authenticator utilizing a key
      cache entry created for use with another virtual authenticator.
 (b)  It is RECOMMENDED that physical authenticators maintain separate
      key caches for each virtual authenticator.  This ensures that a
      cache entry created for use with one virtual authenticator
      cannot be used for access to another virtual authenticator.
      Since a key cache entry can no longer be shared between virtual
      authentications, this step provides protection beyond that
      offered in (a).  This is valuable in situations where
      authorizations are not used to enforce access limitations.  For
      example, where access is limited using a filter installed on a
      router rather than using authorizations provided to the
      authenticator, a peer can gain unauthorized access to resources
      by exploiting a shared key cache entry.
 (c)  It is RECOMMENDED that each virtual authenticator identify
      itself consistently to the peer and to the backend
      authentication server, so as to enable the peer to verify the
      authenticator identity via channel binding (see Section 5.3.3).
 (d)  It is RECOMMENDED that each virtual authenticator identify
      itself distinctly, in order to enable the peer and backend
      authentication server to tell them apart.  For example, this can
      be accomplished by utilizing a distinct value of the NAS-
      Identifier Attribute.

2.4. Peer Identification

 As described in [RFC3748] Section 7.3, the peer identity provided in
 the EAP-Response/Identity can be different from the peer identities
 authenticated by the EAP method.  For example, the identity provided

Aboba, et al. Standards Track [Page 27] RFC 5247 EAP Key Management Framework August 2008

 in the EAP-Response/Identity can be a privacy identifier as described
 in "The Network Access Identifier" [RFC4282] Section 2.  As noted in
 [RFC4284], it is also possible to utilize a Network Access Identifier
 (NAI) for the purposes of source routing; an NAI utilized for source
 routing is said to be "decorated" as described in [RFC4282] Section
 2.7.
 When the EAP peer provides the Network Access Identity (NAI) within
 the EAP-Response/Identity, as described in [RFC3579], the
 authenticator copies the NAI included in the EAP-Response/Identity
 into the User-Name Attribute included within the Access-Request.  As
 the Access-Request is forwarded toward the backend authentication
 server, AAA proxies remove decoration from the NAI included in the
 User-Name Attribute; the NAI included within the
 EAP-Response/Identity encapsulated in the Access-Request remains
 unchanged.  As a result, when the Access-Request arrives at the
 backend authentication server, the EAP-Response/Identity can differ
 from the User-Name Attribute (which can have some or all of the
 decoration removed).  In the absence of a Peer-Id, the backend
 authentication server SHOULD use the contents of the User-Name
 Attribute, rather than the EAP-Response/Identity, as the peer
 identity.
 It is possible for more than one Peer-Id to be exported by an EAP
 method.  For example, a peer certificate can contain more than one
 peer identity; in a tunnel method, peer identities can be
 authenticated within both an outer and inner exchange, and these
 identities could be different in type and contents.  For example, an
 outer exchange could provide a Peer-Id in the form of a Relative
 Distinguished Name (RDN), whereas an inner exchange could identify
 the peer via its NAI or MAC address.  Where EAP keying material is
 determined solely from the outer exchange, only the outer Peer-Id(s)
 are exported; where the EAP keying material is determined from both
 the inner and outer exchanges, then both the inner and outer
 Peer-Id(s) are exported by the tunnel method.

Aboba, et al. Standards Track [Page 28] RFC 5247 EAP Key Management Framework August 2008

2.5. Server Identification

 It is possible for more than one Server-Id to be exported by an EAP
 method.  For example, a server certificate can contain more than one
 server identity; in a tunnel method, server identities could be
 authenticated within both an outer and inner exchange, and these
 identities could be different in type and contents.  For example, an
 outer exchange could provide a Server-Id in the form of an IP
 address, whereas an inner exchange could identify the server via its
 Fully-Qualified Domain Name (FQDN) or hostname.  Where EAP keying
 material is determined solely from the outer exchange, only the outer
 Server-Id(s) are exported by the EAP method; where the EAP keying
 material is determined from both the inner and outer exchanges, then
 both the inner and outer Server-Id(s) are exported by the EAP method.
 As shown in Figure 3, an authenticator can be configured to
 communicate with multiple EAP servers; the EAP server that an
 authenticator communicates with can vary according to configuration
 and network and server availability.  While the EAP peer can assume
 that all EAP servers within a realm have access to the credentials
 necessary to validate an authentication attempt, it cannot assume
 that all EAP servers share persistent state.
 Authenticators can be configured with different primary or secondary
 EAP servers, in order to balance the load.  Also, the authenticator
 can dynamically determine the EAP server to which requests will be
 sent; in the event of a communication failure, the authenticator can
 fail over to another EAP server.  For example, in Figure 3,
 Authenticator2 can be initially configured with EAP server1 as its
 primary backend authentication server, and EAP server2 as the backup,
 but if EAP server1 becomes unavailable, EAP server2 can become the
 primary server.
 In general, the EAP peer cannot direct an authentication attempt to a
 particular EAP server within a realm, this decision is made by AAA
 clients, nor can the peer determine with which EAP server it will be
 communicating, prior to the start of the EAP method conversation.
 The Server-Id is not included in the EAP-Request/Identity, and since
 the EAP server may be determined dynamically, it typically is not
 possible for the authenticator to advertise the Server-Id during the
 discovery phase.  Some EAP methods do not export the Server-Id so
 that it is possible that the EAP peer will not learn with which
 server it was conversing after the EAP conversation completes
 successfully.
 As a result, an EAP peer, on connecting to a new authenticator or
 reconnecting to the same authenticator, can find itself communicating
 with a different EAP server.  Fast reconnect, defined in [RFC3748]

Aboba, et al. Standards Track [Page 29] RFC 5247 EAP Key Management Framework August 2008

 Section 7.2, can fail if the EAP server with which the peer
 communicates is not the same one with which it initially established
 a security association.  For example, an EAP peer attempting an
 EAP-TLS session resume can find that the new EAP-TLS server will not
 have access to the TLS Master Key identified by the TLS Session-Id,
 and therefore the session resumption attempt will fail, requiring
 completion of a full EAP-TLS exchange.
 EAP methods that export the Server-Id MUST authenticate the server.
 However, not all EAP methods supporting mutual authentication provide
 a non-null Server-Id; some methods only enable the EAP peer to verify
 that the EAP server possesses a long-term secret, but do not provide
 the identity of the EAP server.  In this case, the EAP peer will know
 that an authenticator has been authorized by an EAP server, but will
 not confirm the identity of the EAP server.  Where the EAP method
 does not provide a Server-Id, the peer cannot identify the EAP server
 with which it generated keying material.  This can make it difficult
 for the EAP peer to identify the location of a key possessed by that
 EAP server.
 As noted in [RFC5216] Section 5.2, EAP methods supporting
 authentication using server certificates can determine the Server-Id
 from the subject or subjectAltName fields in the server certificate.
 Validating the EAP server identity can help the EAP peer to decide
 whether a specific EAP server is authorized.  In some cases, such as
 where the certificate extensions defined in [RFC4334] are included in
 the server certificate, it can even be possible for the peer to
 verify some channel binding parameters from the server certificate.
 It is possible for problems to arise in situations where the EAP
 server identifies itself differently to the EAP peer and
 authenticator.  For example, it is possible that the Server-Id
 exported by EAP methods will not be identical to the Fully Qualified
 Domain Name (FQDN) of the backend authentication server.  Where
 certificate-based authentication is used within RADIUS or Diameter,
 it is possible that the subjectAltName used in the backend
 authentication server certificate will not be identical to the
 Server-Id or backend authentication server FQDN.  This is not
 normally an issue in EAP, as the authenticator will be unaware of the
 identities used between the EAP peer and server.  However, this can
 be an issue for key caching, if the authenticator is expected to
 locate a backend authentication server corresponding to a Server-Id
 provided by an EAP peer.
 Where the backend authentication server FQDN differs from the
 subjectAltName in the backend authentication server certificate, it
 is possible that the AAA client will not be able to determine whether
 it is talking to the correct backend authentication server.  Where

Aboba, et al. Standards Track [Page 30] RFC 5247 EAP Key Management Framework August 2008

 the Server-Id and backend authentication server FQDN differ, it is
 possible that the combination of the key scope (Peer-Id(s), Server-
 Id(s)) and EAP conversation identifier (Session-Id) will not be
 sufficient to determine where the key resides.  For example, the
 authenticator can identify backend authentication servers by their IP
 address (as occurs in RADIUS), or using a Fully Qualified Domain Name
 (as in Diameter).  If the Server-Id does not correspond to the IP
 address or FQDN of a known backend authentication server, then it may
 not be possible to locate which backend authentication server
 possesses the key.

3. Security Association Management

 EAP, as defined in [RFC3748], supports key derivation, but does not
 provide for the management of lower-layer security associations.
 Missing functionality includes:
 (a)  Security Association negotiation.  EAP does not negotiate
      lower-layer unicast or multicast security associations,
      including cryptographic algorithms or traffic profiles.  EAP
      methods only negotiate cryptographic algorithms for their own
      use, not for the underlying lower layers.  EAP also does not
      negotiate the traffic profiles to be protected with the
      negotiated ciphersuites; in some cases the traffic to be
      protected can have lower-layer source and destination addresses
      different from the lower-layer peer or authenticator addresses.
 (b)  Re-key.  EAP does not support the re-keying of exported EAP
      keying material without EAP re-authentication, although EAP
      methods can support "fast reconnect" as defined in [RFC3748]
      Section 7.2.1.
 (c)  Key delete/install semantics.  EAP does not synchronize
      installation or deletion of keying material on the EAP peer and
      authenticator.
 (d)  Lifetime negotiation.  EAP does not support lifetime negotiation
      for exported EAP keying material, and existing EAP methods also
      do not support key lifetime negotiation.
 (e)  Guaranteed TSK freshness.  Without a post-EAP handshake, TSKs
      can be reused if EAP keying material is cached.
 These deficiencies are typically addressed via a post-EAP handshake
 known as the Secure Association Protocol.

Aboba, et al. Standards Track [Page 31] RFC 5247 EAP Key Management Framework August 2008

3.1. Secure Association Protocol

 Since neither EAP nor EAP methods provide for establishment of
 lower-layer security associations, it is RECOMMENDED that these
 facilities be provided within the Secure Association Protocol,
 including:
 (a)  Entity Naming.  A basic feature of a Secure Association Protocol
      is the explicit naming of the parties engaged in the exchange.
      Without explicit identification, the parties engaged in the
      exchange are not identified and the scope of the EAP keying
      parameters negotiated during the EAP exchange is undefined.
 (b)  Mutual proof of possession of EAP keying material.  During the
      Secure Association Protocol, the EAP peer and authenticator MUST
      demonstrate possession of the keying material transported
      between the backend authentication server and authenticator
      (e.g., MSK), in order to demonstrate that the peer and
      authenticator have been authorized.  Since mutual proof of
      possession is not the same as mutual authentication, the peer
      cannot verify authenticator assertions (including the
      authenticator identity) as a result of this exchange.
      Authenticator identity verification is discussed in Section 2.3.
 (c)  Secure capabilities negotiation.  In order to protect against
      spoofing during the discovery phase, ensure selection of the
      "best" ciphersuite, and protect against forging of negotiated
      security parameters, the Secure Association Protocol MUST
      support secure capabilities negotiation.  This includes the
      secure negotiation of usage modes, session parameters (such as
      security association identifiers (SAIDs) and key lifetimes),
      ciphersuites and required filters, including confirmation of
      security-relevant capabilities discovered during phase 0.  The
      Secure Association Protocol MUST support integrity and replay
      protection of all capability negotiation messages.
 (d)  Key naming and selection.  Where key caching is supported, it is
      possible for the EAP peer and authenticator to share more than
      one key of a given type.  As a result, the Secure Association
      Protocol MUST explicitly name the keys used in the proof of
      possession exchange, so as to prevent confusion when more than
      one set of keying material could potentially be used as the
      basis for the exchange.  Use of the key naming mechanism
      described in Section 1.4.1 is RECOMMENDED.
      In order to support the correct processing of phase 2 security
      associations, the Secure Association (phase 2) protocol MUST
      support the naming of phase 2 security associations and

Aboba, et al. Standards Track [Page 32] RFC 5247 EAP Key Management Framework August 2008

      associated transient session keys so that the correct set of
      transient session keys can be identified for processing a given
      packet.  The phase 2 Secure Association Protocol also MUST
      support transient session key activation and SHOULD support
      deletion so that establishment and re-establishment of transient
      session keys can be synchronized between the parties.
 (e)  Generation of fresh transient session keys (TSKs).  Where the
      lower layer supports caching of keying material, the EAP peer
      lower layer can initiate a new session using keying material
      that was derived in a previous session.  Were the TSKs to be
      derived solely from a portion of the exported EAP keying
      material, this would result in reuse of the session keys that
      could expose the underlying ciphersuite to attack.
      In lower layers where caching of keying material is supported,
      the Secure Association Protocol phase is REQUIRED, and MUST
      support the derivation of fresh unicast and multicast TSKs, even
      when the transported keying material provided by the backend
      authentication server is not fresh.  This is typically supported
      via the exchange of nonces or counters, which are then mixed
      with the keying material in order to generate fresh unicast
      (phase 2a) and possibly multicast (phase 2b) session keys.  By
      not using exported EAP keying material directly to protect data,
      the Secure Association Protocol protects it against compromise.
 (f)  Key lifetime management.  This includes explicit key lifetime
      negotiation or seamless re-key.  EAP does not support the
      re-keying of EAP keying material without re-authentication, and
      existing EAP methods do not support key lifetime negotiation.
      As a result, the Secure Association Protocol MAY handle the
      re-key and determination of the key lifetime.  Where key caching
      is supported, secure negotiation of key lifetimes is
      RECOMMENDED.  Lower layers that support re-key, but not key
      caching, may not require key lifetime negotiation.  For example,
      a difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] is that
      in IKEv1 SA lifetimes were negotiated; in IKEv2, each end of the
      SA is responsible for enforcing its own lifetime policy on the
      SA and re-keying the SA when necessary.
 (g)  Key state resynchronization.  It is possible for the peer or
      authenticator to reboot or reclaim resources, clearing portions
      or all of the key cache.  Therefore, key lifetime negotiation
      cannot guarantee that the key cache will remain synchronized,
      and it may not be possible for the peer to determine before
      attempting to use a key whether it exists within the
      authenticator cache.  It is therefore RECOMMENDED for the EAP
      lower layer to provide a mechanism for key state

Aboba, et al. Standards Track [Page 33] RFC 5247 EAP Key Management Framework August 2008

      resynchronization, either via the SAP or using a lower layer
      indication (see [RFC3748] Section 3.4).  Where the peer and
      authenticator do not jointly possess a key with which to protect
      the resynchronization exchange, secure resynchronization is not
      possible, and alternatives (such as an initiation of EAP
      re-authentication after expiration of a timer) are needed to
      ensure timely resynchronization.
 (h)  Key scope synchronization.  To support key scope determination,
      the Secure Association Protocol SHOULD provide a mechanism by
      which the peer can determine the scope of the key cache on each
      authenticator and by which the authenticator can determine the
      scope of the key cache on a peer.  This includes negotiation of
      restrictions on key usage.
 (i)  Traffic profile negotiation.  The traffic to be protected by a
      lower-layer security association will not necessarily have the
      same lower-layer source or destination address as the EAP peer
      and authenticator, and it is possible for the peer and
      authenticator to negotiate multiple security associations, each
      with a different traffic profile.  Where this is the case, the
      profile of protected traffic SHOULD be explicitly negotiated.
      For example, in IKEv2 it is possible for an Initiator and
      Responder to utilize EAP for authentication, then negotiate a
      Tunnel Mode Security Association (SA), which permits passing of
      traffic originating from hosts other than the Initiator and
      Responder.  Similarly, in IEEE 802.16e, a Subscriber Station
      (SS) can forward traffic to the Base Station (BS), which
      originates from the Local Area Network (LAN) to which it is
      attached.  To enable this, Security Associations within IEEE
      802.16e are identified by the Connection Identifier (CID), not
      by the EAP peer and authenticator MAC addresses.  In both IKEv2
      and IEEE 802.16e, multiple security associations can exist
      between the EAP peer and authenticator, each with their own
      traffic profile and quality of service parameters.
 (j)  Direct operation.  Since the phase 2 Secure Association Protocol
      is concerned with the establishment of security associations
      between the EAP peer and authenticator, including the derivation
      of transient session keys, only those parties have "a need to
      know" the transient session keys.  The Secure Association
      Protocol MUST operate directly between the peer and
      authenticator and MUST NOT be passed-through to the backend
      authentication server or include additional parties.
 (k)  Bi-directional operation.  While some ciphersuites only require
      a single set of transient session keys to protect traffic in
      both directions, other ciphersuites require a unique set of

Aboba, et al. Standards Track [Page 34] RFC 5247 EAP Key Management Framework August 2008

      transient session keys in each direction.  The phase 2 Secure
      Association Protocol SHOULD provide for the derivation of
      unicast and multicast keys in each direction, so as not to
      require two separate phase 2 exchanges in order to create a
      bi-directional phase 2 security association.  See [RFC3748]
      Section 2.4 for more discussion.

3.2. Key Scope

 Absent explicit specification within the lower layer, after the
 completion of phase 1b, transported keying material, and parameters
 are bound to the EAP peer and authenticator, but are not bound to a
 specific peer or authenticator port.
 While EAP keying material passed down to the lower layer is not
 intrinsically bound to particular authenticator and peer ports, TSKs
 MAY be bound to particular authenticator and peer ports by the Secure
 Association Protocol.  However, a lower layer MAY also permit TSKs to
 be used on multiple peer and/or authenticator ports, provided that
 TSK freshness is guaranteed (such as by keeping replay counter state
 within the authenticator).
 In order to further limit the key scope, the following measures are
 suggested:
 (a)  The lower layer MAY specify additional restrictions on key
      usage, such as limiting the use of EAP keying material and
      parameters on the EAP peer to the port over which the EAP
      conversation was conducted.
 (b)  The backend authentication server and authenticator MAY
      implement additional attributes in order to further restrict the
      scope of keying material.  For example, in IEEE 802.11, the
      backend authentication server can provide the authenticator with
      a list of authorized Called or Calling-Station-Ids and/or SSIDs
      for which keying material is valid.
 (c)  Where the backend authentication server provides attributes
      restricting the key scope, it is RECOMMENDED that restrictions
      be securely communicated by the authenticator to the peer.  This
      can be accomplished using the Secure Association Protocol, but
      also can be accomplished via the EAP method or the lower layer.

3.3. Parent-Child Relationships

 When an EAP re-authentication takes place, new EAP keying material is
 exported by the EAP method.  In EAP lower layers where EAP
 re-authentication eventually results in TSK replacement, the maximum

Aboba, et al. Standards Track [Page 35] RFC 5247 EAP Key Management Framework August 2008

 lifetime of derived keying material (including TSKs) can be less than
 or equal to that of EAP keying material (MSK/EMSK), but it cannot be
 greater.
 Where TSKs are derived from or are wrapped by exported EAP keying
 material, compromise of that exported EAP keying material implies
 compromise of TSKs.  Therefore, if EAP keying material is considered
 stale, not only SHOULD EAP re-authentication be initiated, but also
 replacement of child keys, including TSKs.
 Where EAP keying material is used only for entity authentication but
 not for TSK derivation (as in IKEv2), compromise of exported EAP
 keying material does not imply compromise of the TSKs.  Nevertheless,
 the compromise of EAP keying material could enable an attacker to
 impersonate an authenticator, so that EAP re-authentication and TSK
 re-key are RECOMMENDED.
 With respect to IKEv2, Section 5.2 of [RFC4718], "IKEv2
 Clarifications and Implementation Guidelines", states:
    Rekeying the IKE_SA and reauthentication are different concepts in
    IKEv2.  Rekeying the IKE_SA establishes new keys for the IKE_SA
    and resets the Message ID counters, but it does not authenticate
    the parties again (no AUTH or EAP payloads are involved)...  This
    means that reauthentication also establishes new keys for the
    IKE_SA and CHILD_SAs.  Therefore while rekeying can be performed
    more often than reauthentication, the situation where
    "authentication lifetime" is shorter than "key lifetime" does not
    make sense.
 Child keys that are used frequently (such as TSKs that are used for
 traffic protection) can expire sooner than the exported EAP keying
 material on which they are dependent, so that it is advantageous to
 support re-key of child keys prior to EAP re-authentication.  Note
 that deletion of the MSK/EMSK does not necessarily imply deletion of
 TSKs or child keys.
 Failure to mutually prove possession of exported EAP keying material
 during the Secure Association Protocol exchange need not be grounds
 for deletion of keying material by both parties; rate-limiting Secure
 Association Protocol exchanges could be used to prevent a brute force
 attack.

Aboba, et al. Standards Track [Page 36] RFC 5247 EAP Key Management Framework August 2008

3.4. Local Key Lifetimes

 The Transient EAP Keys (TEKs) are session keys used to protect the
 EAP conversation.  The TEKs are internal to the EAP method and are
 not exported.  TEKs are typically created during an EAP conversation,
 used until the end of the conversation and then discarded.  However,
 methods can re-key TEKs during an EAP conversation.
 When using TEKs within an EAP conversation or across conversations,
 it is necessary to ensure that replay protection and key separation
 requirements are fulfilled.  For instance, if a replay counter is
 used, TEK re-key MUST occur prior to wrapping of the counter.
 Similarly, TSKs MUST remain cryptographically separate from TEKs
 despite TEK re-keying or caching.  This prevents TEK compromise from
 leading directly to compromise of the TSKs and vice versa.
 EAP methods MAY cache local EAP keying material (TEKs) that can
 persist for multiple EAP conversations when fast reconnect is used
 [RFC3748].  For example, EAP methods based on TLS (such as EAP-TLS
 [RFC5216]) derive and cache the TLS Master Secret, typically for
 substantial time periods.  The lifetime of other local EAP keying
 material calculated within the EAP method is defined by the method.
 Note that in general, when using fast reconnect, there is no
 guarantee that the original long-term credentials are still in the
 possession of the peer.  For instance, a smart-card holding the
 private key for EAP-TLS may have been removed.  EAP servers SHOULD
 also verify that the long-term credentials are still valid, such as
 by checking that certificate used in the original authentication has
 not yet expired.

3.5. Exported and Calculated Key Lifetimes

 The following mechanisms are available for communicating the lifetime
 of keying material between the EAP peer, server, and authenticator:
    AAA protocols  (backend authentication server and authenticator)
    Lower-layer mechanisms (authenticator and peer)
    EAP method-specific negotiation (peer and server)
 Where the EAP method does not support the negotiation of the lifetime
 of exported EAP keying material, and a key lifetime negotiation
 mechanism is not provided by the lower layer, it is possible that
 there will not be a way for the peer to learn the lifetime of keying
 material.  This can leave the peer uncertain of how long the
 authenticator will maintain keying material within the key cache.  In
 this case the lifetime of keying material can be managed as a system
 parameter on the peer and authenticator; a default lifetime of 8
 hours is RECOMMENDED.

Aboba, et al. Standards Track [Page 37] RFC 5247 EAP Key Management Framework August 2008

3.5.1. AAA Protocols

 AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be
 used to communicate the maximum key lifetime from the backend
 authentication server to the authenticator.
 The Session-Timeout Attribute is defined for RADIUS in [RFC2865] and
 for Diameter in [RFC4005].  Where EAP is used for authentication,
 [RFC3580] Section 3.17, indicates that a Session-Timeout Attribute
 sent in an Access-Accept along with a Termination-Action value of
 RADIUS-Request specifies the maximum number of seconds of service
 provided prior to EAP re-authentication.
 However, there is also a need to be able to specify the maximum
 lifetime of cached keying material.  Where EAP pre-authentication is
 supported, cached keying material can be pre-established on the
 authenticator prior to session start and will remain there until
 expiration.  EAP lower layers supporting caching of keying material
 MAY also persist that material after the end of a session, enabling
 the peer to subsequently resume communication utilizing the cached
 keying material.  In these situations it can be desirable for the
 backend authentication server to specify the maximum lifetime of
 cached keying material.
 To accomplish this, [IEEE-802.11] overloads the Session-Timeout
 Attribute, assuming that it represents the maximum time after which
 transported keying material will expire on the authenticator,
 regardless of whether transported keying material is cached.
 An IEEE 802.11 authenticator receiving transported keying material is
 expected to initialize a timer to the Session-Timeout value, and once
 the timer expires, the transported keying material expires.  Whether
 this results in session termination or EAP re-authentication is
 controlled by the value of the Termination-Action Attribute.  Where
 EAP re-authentication occurs, the transported keying material is
 replaced, and with it, new calculated keys are put in place.  Where
 session termination occurs, transported and derived keying material
 is deleted.
 Overloading the Session-Timeout Attribute is problematic in
 situations where it is necessary to control the maximum session time
 and key lifetime independently.  For example, it might be desirable
 to limit the lifetime of cached keying material to 5 minutes while
 permitting a user once authenticated to remain connected for up to an
 hour without re-authenticating.  As a result, in the future,
 additional attributes can be specified to control the lifetime of
 cached keys; these attributes MAY modify the meaning of the
 Session-Timeout Attribute in specific circumstances.

Aboba, et al. Standards Track [Page 38] RFC 5247 EAP Key Management Framework August 2008

 Since the TSK lifetime is often determined by authenticator
 resources, and the backend authentication server has no insight into
 the TSK derivation process by the principle of ciphersuite
 independence, it is not appropriate for the backend authentication
 server to manage any aspect of the TSK derivation process, including
 the TSK lifetime.

3.5.2. Lower-Layer Mechanisms

 Lower-layer mechanisms can be used to enable the lifetime of keying
 material to be negotiated between the peer and authenticator.  This
 can be accomplished either using the Secure Association Protocol or
 within the lower-layer transport.
 Where TSKs are established as the result of a Secure Association
 Protocol exchange, it is RECOMMENDED that the Secure Association
 Protocol include support for TSK re-key.  Where the TSK is taken
 directly from the MSK, there is no need to manage the TSK lifetime as
 a separate parameter, since the TSK lifetime and MSK lifetime are
 identical.

3.5.3. EAP Method-Specific Negotiation

 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.  EAP
    Methods deriving keys MUST provide for mutual authentication
    between the EAP peer and the EAP Server.
 However, EAP does not itself support the negotiation of lifetimes for
 exported EAP keying material such as the MSK, EMSK, and IV.
 While EAP itself does not support lifetime negotiation, it would be
 possible to specify methods that do.  However, systems that rely on
 key lifetime negotiation within EAP methods would only function with
 these methods.  Also, there is no guarantee that the key lifetime
 negotiated within the EAP method would be compatible with backend
 authentication server policy.  In the interest of method independence
 and compatibility with backend authentication server implementations,
 management of the lifetime of keying material SHOULD NOT be provided
 within EAP methods.

Aboba, et al. Standards Track [Page 39] RFC 5247 EAP Key Management Framework August 2008

3.6. Key Cache Synchronization

 Key lifetime negotiation alone cannot guarantee key cache
 synchronization.  Even where a lower-layer exchange is run
 immediately after EAP in order to determine the lifetime of keying
 material, it is still possible for the authenticator to purge all or
 part of the key cache prematurely (e.g., due to reboot or need to
 reclaim memory).
 The lower layer can utilize the Discovery phase 0 to improve key
 cache synchronization.  For example, if the authenticator manages the
 key cache by deleting the oldest key first, the relative creation
 time of the last key to be deleted could be advertised within the
 Discovery phase, enabling the peer to determine whether keying
 material had been prematurely expired from the authenticator key
 cache.

3.7. Key Strength

 As noted in Section 2.1, EAP lower layers determine TSKs in different
 ways.  Where exported EAP keying material is utilized in the
 derivation, encryption or authentication of TSKs, it is possible for
 EAP key generation to represent the weakest link.
 In order to ensure that methods produce EAP keying material of an
 appropriate symmetric key strength, it is RECOMMENDED that EAP
 methods utilizing public key cryptography choose a public key that
 has a cryptographic strength providing the required level of attack
 resistance.  This is typically provided by configuring EAP methods,
 since there is no coordination between the lower layer and EAP method
 with respect to minimum required symmetric key strength.
 Section 5 of BCP 86 [RFC3766] offers advice on the required RSA or DH
 module and DSA subgroup size in bits, for a given level of attack
 resistance in bits.  The National Institute for Standards and
 Technology (NIST) also offers advice on appropriate key sizes in
 [SP800-57].

Aboba, et al. Standards Track [Page 40] RFC 5247 EAP Key Management Framework August 2008

3.8. Key Wrap

 The key wrap specified in [RFC2548], which is based on an MD5-based
 stream cipher, has known problems, as described in [RFC3579] Section
 4.3.  RADIUS uses the shared secret for multiple purposes, including
 per-packet authentication and attribute hiding, considerable
 information is exposed about the shared secret with each packet.
 This exposes the shared secret to dictionary attacks.  MD5 is used
 both to compute the RADIUS Response Authenticator and the
 Message-Authenticator Attribute, and concerns exist relating to the
 security of this hash [MD5Collision].
 As discussed in [RFC3579] Section 4.3, the security vulnerabilities
 of RADIUS are extensive, and therefore development of an alternative
 key wrap technique based on the RADIUS shared secret would not
 substantially improve security.  As a result, [RFC3579] Section 4.2
 recommends running RADIUS over IPsec.  The same approach is taken in
 Diameter EAP [RFC4072], which in Section 4.1.3 defines the
 EAP-Master-Session-Key Attribute-Value Pair (AVP) in clear-text, to
 be protected by IPsec or TLS.

4. Handoff Vulnerabilities

 A handoff occurs when an EAP peer moves to a new authenticator.
 Several mechanisms have been proposed for reducing handoff latency
 within networks utilizing EAP.  These include:
 EAP pre-authentication
    In EAP pre-authentication, an EAP peer pre-establishes EAP keying
    material with an authenticator prior to arrival.  EAP
    pre-authentication only affects the timing of EAP authentication,
    but does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
    exchanges;  Discovery (phase 0) and Secure Association Protocol
    (phase 2) exchanges occur as described in Section 1.3.  As a
    result, the primary benefit is to enable EAP authentication to be
    removed from the handoff critical path, thereby reducing latency.
    Use of EAP pre-authentication within IEEE 802.11 is described in
    [IEEE-802.11] and [8021XPreAuth].

Aboba, et al. Standards Track [Page 41] RFC 5247 EAP Key Management Framework August 2008

 Proactive key distribution
    In proactive key distribution, keying material and authorizations
    are transported from the backend authentication server to a
    candidate authenticator in advance of a handoff.  As a result, EAP
    (phase 1a) is not needed, but the Discovery (phase 0), and Secure
    Association Protocol exchanges (phase 2) are still necessary.
    Within the AAA exchange (phase 1b), authorization and key
    distribution functions are typically supported, but not
    authentication.  Proactive key distribution is described in
    [MishraPro], [IEEE-03-084], and [HANDOFF].
 Key caching
    Caching of EAP keying material enables an EAP peer to re-attach to
    an authenticator without requiring EAP (phase 1a) or AAA (phase
    1b) exchanges.  However, Discovery (phase 0) and Secure
    Association Protocol (phase 2) exchanges are still needed.  Use of
    key caching within IEEE 802.11 is described in [IEEE-802.11].
 Context transfer
    In context transfer schemes, keying material and authorizations
    are transferred between a previous authenticator and a new
    authenticator.  This can occur in response to a handoff request by
    the EAP peer, or in advance, as in proactive key distribution.  As
    a result, EAP (phase 1a) is eliminated, but not the Discovery
    (phase 0) or Secure Association Protocol exchanges (phase 2).  If
    a secure channel can be established between the new and previous
    authenticator without assistance from the backend authentication
    server, then the AAA exchange (phase 1b) can be eliminated;
    otherwise, it is still needed, although it can be shortened.
    Context transfer protocols are described in [IEEE-802.11F] (now
    deprecated) and "Context Transfer Protocol (CXTP)" [RFC4067].
    "Fast Authentication Methods for Handovers between IEEE 802.11
    Wireless LANs" [Bargh] analyzes fast handoff techniques, including
    context transfer mechanisms.

Aboba, et al. Standards Track [Page 42] RFC 5247 EAP Key Management Framework August 2008

 Token distribution
    In token distribution schemes, the EAP peer is provided with a
    credential, subsequently enabling it to authenticate with one or
    more additional authenticators.  During the subsequent
    authentications, EAP (phase 1a) is eliminated or shortened; the
    Discovery (phase 0) and Secure Association Protocol exchanges
    (phase 2) still occur, although the latter can be shortened.  If
    the token includes authorizations and can be validated by an
    authenticator without assistance from the backend authentication
    server, then the AAA exchange (phase 1b) can be eliminated;
    otherwise, it is still needed, although it can be shortened.
    Token-based schemes, initially proposed in early versions of IEEE
    802.11i [IEEE-802.11i], are described in [Token], [Tokenk], and
    [SHORT-TERM].
 The sections that follow discuss the security vulnerabilities
 introduced by the above schemes.

4.1. EAP Pre-Authentication

 EAP pre-authentication differs from a normal EAP conversation
 primarily with respect to the lower-layer encapsulation.  For
 example, in [IEEE-802.11], EAP pre-authentication frames utilize a
 distinct Ethertype, but otherwise conforms to the encapsulation
 described in [IEEE-802.1X].  As a result, an EAP pre-authentication
 conversation differs little from the model described in Section 1.3,
 other than the introduction of a delay between phase 1 and phase 2.
 EAP pre-authentication relies on lower-layer mechanisms for discovery
 of candidate authenticators.  Where discovery can provide information
 on candidate authenticators outside the immediate listening range,
 and the peer can determine whether it already possesses valid EAP
 keying material with candidate authenticators, the peer can avoid
 unnecessary EAP pre-authentications and can establish EAP keying
 material well in advance, regardless of the coverage overlap between
 authenticators.  However, if the peer can only discover candidate
 authenticators within listening range and cannot determine whether it
 can reuse existing EAP keying material, then it is possible that the
 peer will not be able to complete EAP pre-authentication prior to
 connectivity loss or that it can pre-authenticate multiple times with
 the same authenticator, increasing backend authentication server
 load.
 Since a peer can complete EAP pre-authentication with an
 authenticator without eventually attaching to it, it is possible that
 phase 2 will not occur.  In this case, an Accounting-Request
 signifying the start of service will not be sent, or will only be
 sent with a substantial delay after the completion of authentication.

Aboba, et al. Standards Track [Page 43] RFC 5247 EAP Key Management Framework August 2008

 As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA
 exchange resulting from EAP pre-authentication differs little from an
 ordinary exchange described in "RADIUS Support for EAP" [RFC3579].
 For example, since in IEEE 802.11 [IEEE-802.11] an Association
 exchange does not occur prior to EAP pre-authentication, the SSID is
 not known by the authenticator at authentication time, so that an
 Access-Request cannot include the SSID within the Called-Station-Id
 attribute as described in [RFC3580] Section 3.20.
 Since only the absence of an SSID in the Called-Station-Id attribute
 distinguishes an EAP pre-authentication attempt, if the authenticator
 does not always include the SSID for a normal EAP authentication
 attempt, it is possible that the backend authentication server will
 not be able to determine whether a session constitutes an EAP
 pre-authentication attempt, potentially resulting in authorization or
 accounting problems.  Where the number of simultaneous sessions is
 limited, the backend authentication server can refuse to authorize a
 valid EAP pre-authentication attempt or can enable the peer to engage
 in more simultaneous sessions than they are authorized for.  Where
 EAP pre-authentication occurs with an authenticator which the peer
 never attaches to, it is possible that the backend accounting server
 will not be able to determine whether the absence of an
 Accounting-Request was due to packet loss or a session that never
 started.
 In order to enable pre-authentication requests to be handled more
 reliably, it is RECOMMENDED that AAA protocols explicitly identify
 EAP pre-authentication.  In order to suppress unnecessary EAP
 pre-authentication exchanges, it is RECOMMENDED that authenticators
 unambiguously identify themselves as described in Section 2.3.

4.2. Proactive Key Distribution

 In proactive key distribution schemes, the backend authentication
 server transports keying material and authorizations to an
 authenticator in advance of the arrival of the peer.  The
 authenticators selected to receive the transported key material are
 selected based on past patterns of peer movement between
 authenticators known as the "neighbor graph".  In order to reduce
 handoff latency, proactive key distribution schemes typically only
 demonstrate proof of possession of transported keying material
 between the EAP peer and authenticator.  During a handoff, the
 backend authentication server is not provided with proof that the
 peer successfully authenticated to an authenticator; instead, the
 authenticator generates a stream of accounting messages without a
 corresponding set of authentication exchanges.  As described in
 [MishraPro], knowledge of the neighbor graph can be established via
 static configuration or analysis of authentication exchanges.  In

Aboba, et al. Standards Track [Page 44] RFC 5247 EAP Key Management Framework August 2008

 order to prevent corruption of the neighbor graph, new neighbor graph
 entries can only be created as the result of a successful EAP
 exchange, and accounting packets with no corresponding authentication
 exchange need to be verified to correspond to neighbor graph entries
 (e.g., corresponding to handoffs between neighbors).
 In order to prevent compromise of one authenticator from resulting in
 compromise of other authenticators, cryptographic separation needs to
 be maintained between the keying material transported to each
 authenticator.  However, even where cryptographic separation is
 maintained, an attacker compromising an authenticator can still
 disrupt the operation of other authenticators.  As noted in [RFC3579]
 Section 4.3.7, in the absence of spoofing detection within the AAA
 infrastructure, it is possible for EAP authenticators to impersonate
 each other.  By forging NAS identification attributes within
 authentication messages, an attacker compromising one authenticator
 could corrupt the neighbor graph, tricking the backend authentication
 server into transporting keying material to arbitrary authenticators.
 While this would not enable recovery of EAP keying material without
 breaking fundamental cryptographic assumptions, it could enable
 subsequent fraudulent accounting messages, or allow an attacker to
 disrupt service by increasing load on the backend authentication
 server or thrashing the authenticator key cache.
 Since proactive key distribution requires the distribution of derived
 keying material to candidate authenticators, the effectiveness of
 this scheme depends on the ability of backend authentication server
 to anticipate the movement of the EAP peer.  Since proactive key
 distribution relies on backend authentication server knowledge of the
 neighbor graph, it is most applicable to intra-domain handoff
 scenarios.  However, in inter-domain handoff, where there can be many
 authenticators, peers can frequently connect to authenticators that
 have not been previously encountered, making it difficult for the
 backend authentication server to derive a complete neighbor graph.
 Since proactive key distribution schemes typically require
 introduction of server-initiated messages as described in [RFC5176]
 and [HANDOFF], security issues described in [RFC5176] Section 6 are
 applicable, including authorization (Section 6.1) and replay
 detection (Section 6.3) problems.

Aboba, et al. Standards Track [Page 45] RFC 5247 EAP Key Management Framework August 2008

4.3. AAA Bypass

 Fast handoff techniques that enable elimination of the AAA exchange
 (phase 1b) differ fundamentally from typical network access scenarios
 (dial-up, wired LAN, etc.) that include user authentication as well
 as authorization for the offered service.  Where the AAA exchange
 (phase 1b) is omitted, authorizations and keying material are not
 provided by the backend authentication server, and as a result, they
 need to be supplied by other means.  This section describes some of
 the implications.

4.3.1. Key Transport

 Where transported keying material is not supplied by the backend
 authentication server, it needs to be provided by another party
 authorized to access that keying material.  As noted in Section 1.5,
 only the EAP peer, authenticator, and server are authorized to
 possess transported keying material.  Since EAP peers do not trust
 each other, if the backend authentication server does not supply
 transported keying material to a new authenticator, it can only be
 provided by a previous authenticator.
 As noted in Section 1.5, the goal of the EAP conversation is to
 derive session keys known only to the peer and the authenticator.  If
 keying material is replicated between a previous authenticator and a
 new authenticator, then the previous authenticator can possess
 session keys used between the peer and new authenticator.  Also, the
 new authenticator can possess session keys used between the peer and
 the previous authenticator.
 If a one-way function is used to derive the keying material to be
 transported to the new authenticator, then the new authenticator
 cannot possess previous session keys without breaking a fundamental
 cryptographic assumption.

4.3.2. Authorization

 As a part of the authentication process, the backend authentication
 server determines the user's authorization profile and transmits the
 authorizations to the authenticator along with the transported keying
 material.  Typically, the profile is determined based on the user
 identity, but a certificate presented by the user can also provide
 authorization information.
 The backend authentication server is responsible for making a user
 authorization decision, which requires answering the following
 questions:

Aboba, et al. Standards Track [Page 46] RFC 5247 EAP Key Management Framework August 2008

 (a)  Is this a legitimate user of this network?
 (b)  Is the user allowed to access this network?
 (c)  Is the user permitted to access this network on this day and at
      this time?
 (d)  Is the user within the concurrent session limit?
 (e)  Are there any fraud, credit limit, or other concerns that could
      lead to access denial?
 (f)  If access is to be granted, what are the service parameters
      (mandatory tunneling, bandwidth, filters, and so on) to be
      provisioned for the user?
 While the authorization decision is, in principle, simple, the
 distributed decision making process can add complexity.  Where
 brokers or proxies are involved, all of the AAA entities in the chain
 from the authenticator to the home backend authentication server are
 involved in the decision.  For example, a broker can deny access even
 if the home backend authentication server would allow it, or a proxy
 can add authorizations (e.g., bandwidth limits).
 Decisions can be based on static policy definitions and profiles as
 well as dynamic state (e.g., time of day or concurrent session
 limits).  In addition to the Accept/Reject decisions made by AAA
 entities, service parameters or constraints can be communicated to
 the authenticator.
 The criteria for Accept/Reject decisions or the reasons for choosing
 particular authorizations are typically not communicated to the
 authenticator, only the final result is.  As a result, the
 authenticator has no way to know on what the decision was based.  Was
 a set of authorization parameters sent because this service is always
 provided to the user, or was the decision based on the time of day
 and the capabilities of the authenticator?

4.3.3. Correctness

 When the AAA exchange (phase 1b) is bypassed, several challenges
 arise in ensuring correct authorization:
 Theft of service
    Bypassing the AAA exchange (phase 1b) SHOULD NOT enable a user to
    extend their network access or gain access to services they are
    not entitled to.

Aboba, et al. Standards Track [Page 47] RFC 5247 EAP Key Management Framework August 2008

 Consideration of network-wide state
    Handoff techniques SHOULD NOT render the backend authentication
    server incapable of keeping track of network-wide state.  For
    example, a backend authentication server can need to keep track of
    simultaneous user sessions.
 Elevation of privilege
    Backend authentication servers often perform conditional
    evaluation, in which the authorizations returned in an
    Access-Accept message are contingent on the authenticator or on
    dynamic state such as the time of day.  In this situation,
    bypassing the AAA exchange could enable unauthorized access unless
    the restrictions are explicitly encoded within the authorizations
    provided by the backend authentication server.
 A handoff mechanism that provides proper authorization is said to be
 "correct".  One condition for correctness is as follows:
    For a handoff to be "correct" it MUST establish on the new
    authenticator the same authorizations as would have been created
    had the new authenticator completed a AAA conversation with the
    backend authentication server.
 A properly designed handoff scheme will only succeed if it is
 "correct" in this way.  If a successful handoff would establish
 "incorrect" authorizations, it is preferable for it to fail.  Where
 the supported services differ between authenticators, a handoff that
 bypasses the backend authentication server is likely to fail.
 Section 1.1 of [RFC2865] states:
    A authenticator that does not implement a given service MUST NOT
    implement the RADIUS attributes for that service.  For example, a
    authenticator that is unable to offer ARAP service MUST NOT
    implement the RADIUS attributes for ARAP.  A authenticator MUST
    treat a RADIUS access-accept authorizing an unavailable service as
    an access-reject instead.
 This behavior applies to attributes that are known, but not
 implemented.  For attributes that are unknown, Section 5 of [RFC2865]
 states:
    A RADIUS server MAY ignore Attributes with an unknown Type.  A
    RADIUS client MAY ignore Attributes with an unknown Type.
 In order to perform a correct handoff, if a new authenticator is
 provided with RADIUS authorizations for a known but unavailable
 service, then it MUST process these authorizations the same way it
 would handle a RADIUS Access-Accept requesting an unavailable

Aboba, et al. Standards Track [Page 48] RFC 5247 EAP Key Management Framework August 2008

 service;  this MUST cause the handoff to fail.  However, if a new
 authenticator is provided with authorizations including unknown
 attributes, then these attributes MAY be ignored.  The definition of
 a "known but unsupported service" MUST encompass requests for
 unavailable security services.  This includes vendor-specific
 attributes related to security, such as those described in [RFC2548].
 Although it can seem somewhat counter-intuitive, failure is indeed
 the "correct" result where a known but unsupported service is
 requested.
 Presumably, a correctly configured backend authentication server
 would not request that an authenticator provide a service that it
 does not implement.  This implies that if the new authenticator were
 to complete a AAA conversation, it would be likely to receive
 different service instructions.  Failure of the handoff is the
 desired result since it will cause the new authenticator to go back
 to the backend server in order to receive the appropriate service
 definition.
 Handoff mechanisms that bypass the backend authentication server are
 most likely to be successful when employed in a homogeneous
 deployment within a single administrative domain.  In a heterogeneous
 deployment, the backend authentication server can return different
 authorizations depending on the authenticator making the request in
 order to make sure that the requested service is consistent with the
 authenticator capabilities.  Where a backend authentication server
 would send different authorizations to the new authenticator than
 were sent to a previous authenticator, transferring authorizations
 between the previous authenticator and the new authenticator will
 result in incorrect authorization.
 Virtual LAN (VLAN) support is defined in [IEEE-802.1Q]; RADIUS
 support for dynamic VLANs is described in [RFC3580] and [RFC4675].
 If some authenticators support dynamic VLANs while others do not,
 then attributes present in the Access-Request (such as the
 NAS-Port-Type, NAS-IP-Address, NAS-IPv6-Address, and NAS-Identifier)
 could be examined by the backend authentication server to determine
 when VLAN attributes will be returned, and if so, which ones.
 However, if the backend authenticator is bypassed, then a handoff
 occurring between authenticators supporting different VLAN
 capabilities could result in a user obtaining access to an
 unauthorized VLAN (e.g., a user with access to a guest VLAN being
 given unrestricted access to the network).

Aboba, et al. Standards Track [Page 49] RFC 5247 EAP Key Management Framework August 2008

 Similarly, it is preferable for a handoff between an authenticator
 providing confidentiality and another that does not to fail, since if
 the handoff were successful, the user would be moved from a secure to
 an insecure channel without permission from the backend
 authentication server.

5. Security Considerations

 The EAP threat model is described in [RFC3748] Section 7.1.  The
 security properties of EAP methods (known as "security claims") are
 described in [RFC3748] Section 7.2.1.  EAP method requirements for
 applications such as Wireless LAN authentication are described in
 [RFC4017].  The RADIUS threat model is described in [RFC3579] Section
 4.1, and responses to these threats are described in [RFC3579],
 Sections 4.2 and 4.3.
 However, in addition to threats against EAP and AAA, there are other
 system level threats.  In developing the threat model, it is assumed
 that:
    All traffic is visible to the attacker.
    The attacker can alter, forge, or replay messages.
    The attacker can reroute messages to another principal.
    The attacker can be a principal or an outsider.
    The attacker can compromise any key that is sufficiently old.
 Threats arising from these assumptions include:
 (a)  An attacker can compromise or steal an EAP peer or
      authenticator, in an attempt to gain access to other EAP peers
      or authenticators or to obtain long-term secrets.
 (b)  An attacker can attempt a downgrade attack in order to exploit
      known weaknesses in an authentication method or cryptographic
      algorithm.
 (c)  An attacker can try to modify or spoof packets, including
      Discovery or Secure Association Protocol frames, EAP or AAA
      packets.
 (d)  An attacker can attempt to induce an EAP peer, authenticator, or
      server to disclose keying material to an unauthorized party, or
      utilize keying material outside the context that it was intended
      for.
 (e)  An attacker can alter, forge, or replay packets.

Aboba, et al. Standards Track [Page 50] RFC 5247 EAP Key Management Framework August 2008

 (f)  An attacker can cause an EAP peer, authenticator, or server to
      reuse a stale key.  Use of stale keys can also occur
      unintentionally.  For example, a poorly implemented backend
      authentication server can provide stale keying material to an
      authenticator, or a poorly implemented authenticator can reuse
      nonces.
 (g)  An authenticated attacker can attempt to obtain elevated
      privilege in order to access information that it does not have
      rights to.
 (h)  An attacker can attempt a man-in-the-middle attack in order to
      gain access to the network.
 (i)  An attacker can compromise an EAP authenticator in an effort to
      commit fraud.  For example, a compromised authenticator can
      provide incorrect information to the EAP peer and/or server via
      out-of-band mechanisms (such as via a AAA or lower-layer
      protocol).  This includes impersonating another authenticator,
      or providing inconsistent information to the peer and EAP
      server.
 (j)  An attacker can launch a denial-of-service attack against the
      EAP peer, authenticator, or backend authentication server.
 In order to address these threats, [RFC4962] Section 3 describes
 required and recommended security properties.  The sections that
 follow analyze the compliance of EAP methods, AAA protocols, and
 Secure Association Protocols with those guidelines.

5.1. Peer and Authenticator Compromise

 Requirement: In the event that an authenticator is compromised or
 stolen, an attacker can gain access to the network through that
 authenticator, or can obtain the credentials needed for the
 authenticator/AAA client to communicate with one or more backend
 authentication servers.  Similarly, if a peer is compromised or
 stolen, an attacker can obtain credentials needed to communicate with
 one or more authenticators.  A mandatory requirement from [RFC4962]
 Section 3:
    Prevent the Domino effect
    Compromise of a single peer MUST NOT compromise keying material
    held by any other peer within the system, including session keys
    and long-term keys.  Likewise, compromise of a single
    authenticator MUST NOT compromise keying material held by any
    other authenticator within the system.  In the context of a key

Aboba, et al. Standards Track [Page 51] RFC 5247 EAP Key Management Framework August 2008

    hierarchy, this means that the compromise of one node in the key
    hierarchy must not disclose the information necessary to
    compromise other branches in the key hierarchy.  Obviously, the
    compromise of the root of the key hierarchy will compromise all of
    the keys; however, a compromise in one branch MUST NOT result in
    the compromise of other branches.  There are many implications of
    this requirement; however, two implications deserve highlighting.
    First, the scope of the keying material must be defined and
    understood by all parties that communicate with a party that holds
    that keying material.  Second, a party that holds keying material
    in a key hierarchy must not share that keying material with
    parties that are associated with other branches in the key
    hierarchy.
    Group keys are an obvious exception.  Since all members of the
    group have a copy of the same key, compromise of any one of the
    group members will result in the disclosure of the group key.
 Some of the implications of the requirement are as follows:
 Key Sharing
      In order to be able to determine whether keying material has
      been shared, it is necessary for the identity of the EAP
      authenticator (NAS-Identifier) to be defined and understood by
      all parties that communicate with it.  EAP lower-layer
      specifications such as [IEEE-802.11], [IEEE-802.16e],
      [IEEE-802.1X], IKEv2 [RFC4306], and PPP [RFC1661] do not involve
      key sharing.
 AAA Credential Sharing
      AAA credentials (such as RADIUS shared secrets, IPsec pre-shared
      keys or certificates) MUST NOT be shared between AAA clients,
      since if one AAA client were compromised, this would enable an
      attacker to impersonate other AAA clients to the backend
      authentication server, or even to impersonate a backend
      authentication server to other AAA clients.
 Compromise of Long-Term Credentials
      An attacker obtaining keying material (such as TSKs, TEKs, or
      the MSK) MUST NOT be able to obtain long-term user credentials
      such as pre-shared keys, passwords, or private-keys without
      breaking a fundamental cryptographic assumption.  The mandatory
      requirements of [RFC4017] Section 2.2 include generation of EAP
      keying material, capability to generate EAP keying material with
      128 bits of effective strength, resistance to dictionary
      attacks, shared state equivalence, and protection against
      man-in-the-middle attacks.

Aboba, et al. Standards Track [Page 52] RFC 5247 EAP Key Management Framework August 2008

5.2. Cryptographic Negotiation

 Mandatory requirements from [RFC4962] Section 3:
    Cryptographic algorithm independent
    The AAA key management protocol MUST be cryptographic algorithm
    independent.  However, an EAP method MAY depend on a specific
    cryptographic algorithm.  The ability to negotiate the use of a
    particular cryptographic algorithm provides resilience against
    compromise of a particular cryptographic algorithm.  Algorithm
    independence is also REQUIRED with a Secure Association Protocol
    if one is defined.  This is usually accomplished by including an
    algorithm identifier and parameters in the protocol, and by
    specifying the algorithm requirements in the protocol
    specification.  While highly desirable, the ability to negotiate
    key derivation functions (KDFs) is not required.  For
    interoperability, at least one suite of mandatory-to-implement
    algorithms MUST be selected.  Note that without protection by
    IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865] does
    not meet this requirement, since the integrity protection
    algorithm cannot be negotiated.
    This requirement does not mean that a protocol must support both
    public-key and symmetric-key cryptographic algorithms.  It means
    that the protocol needs to be structured in such a way that
    multiple public-key algorithms can be used whenever a public-key
    algorithm is employed.  Likewise, it means that the protocol needs
    to be structured in such a way that multiple symmetric-key
    algorithms can be used whenever a symmetric-key algorithm is
    employed.
    Confirm ciphersuite selection
    The selection of the "best" ciphersuite SHOULD be securely
    confirmed.  The mechanism SHOULD detect attempted roll-back
    attacks.
 EAP methods satisfying [RFC4017] Section 2.2 mandatory requirements
 and AAA protocols utilizing transmission-layer security are capable
 of addressing downgrade attacks.  [RFC3748] Section 7.2.1 describes
 the "protected ciphersuite negotiation" security claim that refers to
 the ability of an EAP method to negotiate the ciphersuite used to
 protect the EAP method conversation, as well as to integrity protect
 the ciphersuite negotiation.  [RFC4017] Section 2.2 requires EAP
 methods satisfying this security claim.  Since TLS v1.2 [RFC5246] and
 IKEv2 [RFC4306] support negotiation of Key Derivation Functions
 (KDFs), EAP methods based on TLS or IKEv2 will, if properly designed,

Aboba, et al. Standards Track [Page 53] RFC 5247 EAP Key Management Framework August 2008

 inherit this capability.  However, negotiation of KDFs is not
 required by RFC 4962 [RFC4962], and EAP methods based on neither TLS
 nor IKEv2 typically do not support KDF negotiation.
 When AAA protocols utilize TLS [RFC5246] or IPsec [RFC4301] for
 transmission layer security, they can leverage the cryptographic
 algorithm negotiation support provided by IKEv2 [RFC4306] or TLS
 [RFC5246].  RADIUS [RFC3579] by itself does not support cryptographic
 algorithm negotiation and relies on MD5 for integrity protection,
 authentication, and confidentiality.  Given the known weaknesses in
 MD5 [MD5Collision], this is undesirable, and can be addressed via use
 of RADIUS over IPsec, as described in [RFC3579] Section 4.2.
 To ensure against downgrade attacks within lower-layer protocols,
 algorithm independence is REQUIRED with lower layers using EAP for
 key derivation.  For interoperability, at least one suite of
 mandatory-to-implement algorithms MUST be selected.  Lower-layer
 protocols supporting EAP for key derivation SHOULD also support
 secure ciphersuite negotiation as well as KDF negotiation.
 As described in [RFC1968], PPP ECP does not support secure
 ciphersuite negotiation.  While [IEEE-802.16e] and [IEEE-802.11]
 support ciphersuite negotiation for protection of data, they do not
 support negotiation of the cryptographic primitives used within the
 Secure Association Protocol, such as message integrity checks (MICs)
 and KDFs.

5.3. Confidentiality and Authentication

 Mandatory requirements from [RFC4962] Section 3:
    Authenticate all parties
    Each party in the AAA key management protocol MUST be
    authenticated to the other parties with whom they communicate.
    Authentication mechanisms MUST maintain the confidentiality of any
    secret values used in the authentication process.  When a secure
    association protocol is used to establish session keys, the
    parties involved in the secure association protocol MUST identify
    themselves using identities that are meaningful in the lower-layer
    protocol environment that will employ the session keys.  In this
    situation, the authenticator and peer may be known by different
    identifiers in the AAA protocol environment and the lower-layer
    protocol environment, making authorization decisions difficult
    without a clear key scope.  If the lower-layer identifier of the

Aboba, et al. Standards Track [Page 54] RFC 5247 EAP Key Management Framework August 2008

    peer will be used to make authorization decisions, then the pair
    of identifiers associated with the peer MUST be authorized by the
    authenticator and/or the AAA server.
    AAA protocols, such as RADIUS [RFC2865] and Diameter [RFC3588],
    provide a mechanism for the identification of AAA clients; since
    the EAP authenticator and AAA client are always co-resident, this
    mechanism is applicable to the identification of EAP
    authenticators.
    When multiple base stations and a "controller" (such as a WLAN
    switch) comprise a single EAP authenticator, the "base station
    identity" is not relevant; the EAP method conversation takes place
    between the EAP peer and the EAP server.  Also, many base stations
    can share the same authenticator identity.  The authenticator
    identity is important in the AAA protocol exchange and the secure
    association protocol conversation.
    Authentication mechanisms MUST NOT employ plaintext passwords.
    Passwords may be used provided that they are not sent to another
    party without confidentiality protection.
    Keying material confidentiality and integrity
    While preserving algorithm independence, confidentiality and
    integrity of all keying material MUST be maintained.
 Conformance to these requirements is analyzed in the sections that
 follow.

5.3.1. Spoofing

 Per-packet authentication and integrity protection provides
 protection against spoofing attacks.
 Diameter [RFC3588] provides support for per-packet authentication and
 integrity protection via use of IPsec or TLS.  RADIUS/EAP [RFC3579]
 provides for per-packet authentication and integrity protection via
 use of the Message-Authenticator Attribute.
 [RFC3748] Section 7.2.1 describes the "integrity protection" security
 claim and [RFC4017] Section 2.2 requires EAP methods supporting this
 claim.
 In order to prevent forgery of Secure Association Protocol frames,
 per-frame authentication and integrity protection is RECOMMENDED on
 all messages.  IKEv2 [RFC4306] supports per-frame integrity

Aboba, et al. Standards Track [Page 55] RFC 5247 EAP Key Management Framework August 2008

 protection and authentication, as does the Secure Association
 Protocol defined in [IEEE-802.16e].  [IEEE-802.11] supports per-frame
 integrity protection and authentication on all messages within the
 4-way handshake except the first message.  An attack leveraging this
 omission is described in [Analysis].

5.3.2. Impersonation

 Both RADIUS [RFC2865] and Diameter [RFC3588] implementations are
 potentially vulnerable to a rogue authenticator impersonating another
 authenticator.  While both protocols support mutual authentication
 between the AAA client/authenticator and the backend authentication
 server, the security mechanisms vary.
 In RADIUS, the shared secret used for authentication is determined by
 the source address of the RADIUS packet.  However, when RADIUS
 Access-Requests are forwarded by a proxy, the NAS-IP-Address,
 NAS-Identifier, or NAS-IPv6-Address attributes received by the RADIUS
 server will not correspond to the source address.  As noted in
 [RFC3579] Section 4.3.7, if the first-hop proxy does not check the
 NAS identification attributes against the source address in the
 Access-Request packet, it is possible for a rogue authenticator to
 forge NAS-IP-Address [RFC2865], NAS-IPv6-Address [RFC3162], or
 NAS-Identifier [RFC2865] attributes in order to impersonate another
 authenticator; attributes such as the Called-Station-Id [RFC2865] and
 Calling-Station-Id [RFC2865] can be forged as well.  Among other
 things, this can result in messages (and transported keying material)
 being sent to the wrong authenticator.
 While [RFC3588] requires use of the Route-Record AVP, this utilizes
 Fully Qualified Domain Names (FQDNs), so that impersonation detection
 requires DNS A, AAAA, and PTR Resource Records (RRs) to be properly
 configured.  As a result, Diameter is as vulnerable to this attack as
 RADIUS, if not more so.  [RFC3579] Section 4.3.7 recommends
 mechanisms for impersonation detection; to prevent access to keying
 material by proxies without a "need to know", it is necessary to
 allow the backend authentication server to communicate with the
 authenticator directly, such as via the redirect functionality
 supported in [RFC3588].

5.3.3. Channel Binding

 It is possible for a compromised or poorly implemented EAP
 authenticator to communicate incorrect information to the EAP peer
 and/or server.  This can enable an authenticator to impersonate
 another authenticator or communicate incorrect information via
 out-of-band mechanisms (such as via AAA or the lower layer).

Aboba, et al. Standards Track [Page 56] RFC 5247 EAP Key Management Framework August 2008

 Where EAP is used in pass-through mode, the EAP peer does not verify
 the identity of the pass-through authenticator within the EAP
 conversation.  Within the Secure Association Protocol, the EAP peer
 and authenticator only demonstrate mutual possession of the
 transported keying material; they do not mutually authenticate.  This
 creates a potential security vulnerability, described in [RFC3748]
 Section 7.15.
 As described in [RFC3579] Section 4.3.7, it is possible for a
 first-hop AAA proxy to detect a AAA client attempting to impersonate
 another authenticator.  However, it is possible for a pass-through
 authenticator acting as a AAA client to provide correct information
 to the backend authentication server while communicating misleading
 information to the EAP peer via the lower layer.
 For example, a compromised authenticator can utilize another
 authenticator's Called-Station-Id or NAS-Identifier in communicating
 with the EAP peer via the lower layer.  Also, a pass-through
 authenticator acting as a AAA client can provide an incorrect peer
 Calling-Station-Id [RFC2865] [RFC3580] to the backend authentication
 server via the AAA protocol.
 As noted in [RFC3748] Section 7.15, this vulnerability can be
 addressed by EAP methods that support a protected exchange of channel
 properties such as endpoint identifiers, including (but not limited
 to): Called-Station-Id [RFC2865] [RFC3580], Calling-Station-Id
 [RFC2865] [RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
 [RFC2865], and NAS-IPv6-Address [RFC3162].
 Using such a protected exchange, it is possible to match the channel
 properties provided by the authenticator via out-of-band mechanisms
 against those exchanged within the EAP method.  Typically, the EAP
 method imports channel binding parameters from the lower layer on the
 peer, and transmits them securely to the EAP server, which exports
 them to the lower layer or AAA layer.  However, transport can occur
 from EAP server to peer, or can be bi-directional.  On the side of
 the exchange (peer or server) where channel binding is verified, the
 lower layer or AAA layer passes the result of the verification (TRUE
 or FALSE) up to the EAP method.  While the verification can be done
 either by the peer or the server, typically only the server has the
 knowledge to determine the correctness of the values, as opposed to
 merely verifying their equality.  For further discussion, see
 [EAP-SERVICE].
 It is also possible to perform channel binding without transporting
 data over EAP, as described in [EAP-CHANNEL].  In this approach the
 EAP method includes channel binding parameters in the calculation of
 exported EAP keying material, making it impossible for the peer and

Aboba, et al. Standards Track [Page 57] RFC 5247 EAP Key Management Framework August 2008

 authenticator to complete the Secure Association Protocol if there is
 a mismatch in the channel binding parameters.  However, this approach
 can only be applied where methods generating EAP keying material are
 used along with lower layers that utilize EAP keying material.  For
 example, this mechanism would not enable verification of channel
 binding on wired IEEE 802 networks using [IEEE-802.1X].

5.3.4. Mutual Authentication

 [RFC3748] Section 7.2.1 describes the "mutual authentication" and
 "dictionary attack resistance" claims, and [RFC4017] requires EAP
 methods satisfying these claims.  EAP methods complying with
 [RFC4017] therefore provide for mutual authentication between the EAP
 peer and server.
 [RFC3748] Section 7.2.1 also describes the "Cryptographic binding"
 security claim, and [RFC4017] Section 2.2 requires support for this
 claim.  As described in [EAP-BINDING], EAP method sequences and
 compound authentication mechanisms can be subject to
 man-in-the-middle attacks.  When such attacks are successfully
 carried out, the attacker acts as an intermediary between a victim
 and a legitimate authenticator.  This allows the attacker to
 authenticate successfully to the authenticator, as well as to obtain
 access to the network.
 In order to prevent these attacks, [EAP-BINDING] recommends
 derivation of a compound key by which the EAP peer and server can
 prove that they have participated in the entire EAP exchange.  Since
 the compound key MUST NOT be known to an attacker posing as an
 authenticator, and yet must be derived from EAP keying material, it
 MAY be desirable to derive the compound key from a portion of the
 EMSK.  Where this is done, in order to provide proper key hygiene, it
 is RECOMMENDED that the compound key used for man-in-the-middle
 protection be cryptographically separate from other keys derived from
 the EMSK.
 Diameter [RFC3588] provides for per-packet authentication and
 integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also
 provides for per-packet authentication and integrity protection.
 Where the authenticator/AAA client and backend authentication server
 communicate directly and credible key wrap is used (see Section 3.8),
 this ensures that the AAA Key Transport (phase 1b) achieves its
 security objectives: mutually authenticating the AAA
 client/authenticator and backend authentication server and providing
 transported keying material to the EAP authenticator and to no other
 party.

Aboba, et al. Standards Track [Page 58] RFC 5247 EAP Key Management Framework August 2008

 [RFC2607] Section 7 describes the security issues occurring when the
 authenticator/AAA client and backend authentication server do not
 communicate directly.  Where a AAA intermediary is present (such as a
 RADIUS proxy or a Diameter agent), and data object security is not
 used, transported keying material can be recovered by an attacker in
 control of the intermediary.  As discussed in Section 2.1, unless the
 TSKs are derived independently from EAP keying material (as in
 IKEv2), possession of transported keying material enables decryption
 of data traffic sent between the peer and the authenticator to whom
 the keying material was transported.  It also allows the AAA
 intermediary to impersonate the authenticator or the peer.  Since the
 peer does not authenticate to a AAA intermediary, it has no ability
 to determine whether it is authentic or authorized to obtain keying
 material.
 However, as long as transported keying material or keys derived from
 it are only utilized by a single authenticator, compromise of the
 transported keying material does not enable an attacker to
 impersonate the peer to another authenticator.  Vulnerability to
 compromise of a AAA intermediary can be mitigated by implementation
 of redirect functionality, as described in [RFC3588] and [RFC4072].
 The Secure Association Protocol does not provide for mutual
 authentication between the EAP peer and authenticator, only mutual
 proof of possession of transported keying material.  In order for the
 peer to verify the identity of the authenticator, mutual proof of
 possession needs to be combined with impersonation prevention and
 channel binding.  Impersonation prevention (described in Section
 5.3.2) enables the backend authentication server to determine that
 the transported keying material has been provided to the correct
 authenticator.  When utilized along with impersonation prevention,
 channel binding (described in Section 5.3.3) enables the EAP peer to
 verify that the EAP server has authorized the authenticator to
 possess the transported keying material.  Completion of the Secure
 Association Protocol exchange demonstrates that the EAP peer and the
 authenticator possess the transported keying material.

5.4. Key Binding

 Mandatory requirement from [RFC4962] Section 3:
    Bind key to its context
    Keying material MUST be bound to the appropriate context.  The
    context includes the following:
    o  The manner in which the keying material is expected to be used.

Aboba, et al. Standards Track [Page 59] RFC 5247 EAP Key Management Framework August 2008

    o  The other parties that are expected to have access to the
       keying material.
    o  The expected lifetime of the keying material.  Lifetime of a
       child key SHOULD NOT be greater than the lifetime of its parent
       in the key hierarchy.
    Any party with legitimate access to keying material can determine
    its context.  In addition, the protocol MUST ensure that all
    parties with legitimate access to keying material have the same
    context for the keying material.  This requires that the parties
    are properly identified and authenticated, so that all of the
    parties that have access to the keying material can be determined.
    The context will include the peer and NAS identities in more than
    one form.  One (or more) name form is needed to identify these
    parties in the authentication exchange and the AAA protocol.
    Another name form may be needed to identify these parties within
    the lower layer that will employ the session key.
 Within EAP, exported keying material (MSK, EMSK,IV) is bound to the
 Peer-Id(s) and Server-Id(s), which are exported along with the keying
 material.  However, not all EAP methods support authenticated server
 identities (see Appendix A).
 Within the AAA protocol, transported keying material is destined for
 the EAP authenticator identified by the NAS-Identifier Attribute
 within the request, and is for use by the EAP peer identified by the
 Peer-Id(s), User-Name [RFC2865], or Chargeable User Identity (CUI)
 [RFC4372] attributes.  The maximum lifetime of the transported keying
 material can be provided, as discussed in Section 3.5.1.  Key usage
 restrictions can also be included as described in Section 3.2.  Key
 lifetime issues are discussed in Sections 3.3, 3.4, and 3.5.

5.5. Authorization

 Requirement: The Secure Association Protocol (phase 2) conversation
 may utilize different identifiers from the EAP conversation (phase
 1a), so that binding between the EAP and Secure Association Protocol
 identities is REQUIRED.
 Mandatory requirement from [RFC4962] Section 3:
    Peer and authenticator authorization
    Peer and authenticator authorization MUST be performed.  These
    entities MUST demonstrate possession of the appropriate keying
    material, without disclosing it.  Authorization is REQUIRED

Aboba, et al. Standards Track [Page 60] RFC 5247 EAP Key Management Framework August 2008

    whenever a peer associates with a new authenticator.  The
    authorization checking prevents an elevation of privilege attack,
    and it ensures that an unauthorized authenticator is detected.
    Authorizations SHOULD be synchronized between the peer, NAS, and
    backend authentication server.  Once the AAA key management
    protocol exchanges are complete, all of these parties should hold
    a common view of the authorizations associated with the other
    parties.
    In addition to authenticating all parties, key management
    protocols need to demonstrate that the parties are authorized to
    possess keying material.  Note that proof of possession of keying
    material does not necessarily prove authorization to hold that
    keying material.  For example, within an IEEE 802.11, the 4-way
    handshake demonstrates that both the peer and authenticator
    possess the same EAP keying material.  However, by itself, this
    possession proof does not demonstrate that the authenticator was
    authorized by the backend authentication server to possess that
    keying material.  As noted in [RFC3579] in Section 4.3.7, where
    AAA proxies are present, it is possible for one authenticator to
    impersonate another, unless each link in the AAA chain implements
    checks against impersonation.  Even with these checks in place, an
    authenticator may still claim different identities to the peer and
    the backend authentication server.  As described in [RFC3748]
    Section 7.15, channel binding is required to enable the peer to
    verify that the authenticator claim of identity is both consistent
    and correct.
 Recommendation from [RFC4962] Section 3:
    Authorization restriction
    If peer authorization is restricted, then the peer SHOULD be made
    aware of the restriction.  Otherwise, the peer may inadvertently
    attempt to circumvent the restriction.  For example, authorization
    restrictions in an IEEE 802.11 environment include:
    o  Key lifetimes, where the keying material can only be used for a
       certain period of time;
    o  SSID restrictions, where the keying material can only be used
       with a specific IEEE 802.11 SSID;
    o  Called-Station-ID restrictions, where the keying material can
       only be used with a single IEEE 802.11 BSSID; and

Aboba, et al. Standards Track [Page 61] RFC 5247 EAP Key Management Framework August 2008

    o  Calling-Station-ID restrictions, where the keying material can
       only be used with a single peer IEEE 802 MAC address.
 As described in Section 2.3, consistent identification of the EAP
 authenticator enables the EAP peer to determine the scope of keying
 material provided to an authenticator, as well as to confirm with the
 backend authentication server that an EAP authenticator proving
 possession of EAP keying material during the Secure Association
 Protocol was authorized to obtain it.
 Within the AAA protocol, the authorization attributes are bound to
 the transported keying material.  While the AAA exchange provides the
 AAA client/authenticator with authorizations relating to the EAP
 peer, neither the EAP nor AAA exchanges provide authorizations to the
 EAP peer.  In order to ensure that all parties hold the same view of
 the authorizations, it is RECOMMENDED that the Secure Association
 Protocol enable communication of authorizations between the EAP
 authenticator and peer.
 In lower layers where the authenticator consistently identifies
 itself to the peer and backend authentication server and the EAP peer
 completes the Secure Association Protocol exchange with the same
 authenticator through which it completed the EAP conversation,
 authorization of the authenticator is demonstrated to the peer by
 mutual authentication between the peer and authenticator as discussed
 in the previous section.  Identification issues are discussed in
 Sections 2.3, 2.4, and 2.5 and key scope issues are discussed in
 Section 3.2.
 Where the EAP peer utilizes different identifiers within the EAP
 method and Secure Association Protocol conversations, peer
 authorization can be difficult to demonstrate to the authenticator
 without additional restrictions.  This problem does not exist in
 IKEv2 where the Identity Payload is used for peer identification both
 within IKEv2 and EAP, and where the EAP conversation is
 cryptographically protected within IKEv2 binding the EAP and IKEv2
 exchanges.  However, within [IEEE-802.11], the EAP peer identity is
 not used within the 4-way handshake, so that it is necessary for the
 authenticator to require that the EAP peer utilize the same MAC
 address for EAP authentication as for the 4-way handshake.

Aboba, et al. Standards Track [Page 62] RFC 5247 EAP Key Management Framework August 2008

5.6. Replay Protection

 Mandatory requirement from [RFC4962] Section 3:
    Replay detection mechanism
    The AAA key management protocol exchanges MUST be replay
    protected, including AAA, EAP and Secure Association Protocol
    exchanges.  Replay protection allows a protocol message recipient
    to discard any message that was recorded during a previous
    legitimate dialogue and presented as though it belonged to the
    current dialogue.
 [RFC3748] Section 7.2.1 describes the "replay protection" security
 claim, and [RFC4017] Section 2.2 requires use of EAP methods
 supporting this claim.
 Diameter [RFC3588] provides support for replay protection via use of
 IPsec or TLS.  "RADIUS Support for EAP" [RFC3579] protects against
 replay of keying material via the Request Authenticator.  According
 to [RFC2865] Section 3:
    In Access-Request Packets, the Authenticator value is a 16 octet
    random number, called the Request Authenticator.
 However, some RADIUS packets are not replay protected.  In
 Accounting, Disconnect, and Care-of Address (CoA)-Request packets,
 the Request Authenticator contains a keyed Message Integrity Code
 (MIC) rather than a nonce.  The Response Authenticator in Accounting,
 Disconnect, and CoA-Response packets also contains a keyed MIC whose
 calculation does not depend on a nonce in either the Request or
 Response packets.  Therefore, unless an Event-Timestamp attribute is
 included or IPsec is used, it is possible that the recipient will not
 be able to determine whether these packets have been replayed.  This
 issue is discussed further in [RFC5176] Section 6.3.
 In order to prevent replay of Secure Association Protocol frames,
 replay protection is REQUIRED on all messages.  [IEEE-802.11]
 supports replay protection on all messages within the 4-way
 handshake; IKEv2 [RFC4306] also supports this.

Aboba, et al. Standards Track [Page 63] RFC 5247 EAP Key Management Framework August 2008

5.7. Key Freshness

 Requirement: A session key SHOULD be considered compromised if it
 remains in use beyond its authorized lifetime.  Mandatory requirement
 from [RFC4962] Section 3:
    Strong, fresh session keys
    While preserving algorithm independence, session keys MUST be
    strong and fresh.  Each session deserves an independent session
    key.  Fresh keys are required even when a long replay counter
    (that is, one that "will never wrap") is used to ensure that loss
    of state does not cause the same counter value to be used more
    than once with the same session key.
    Some EAP methods are capable of deriving keys of varying strength,
    and these EAP methods MUST permit the generation of keys meeting a
    minimum equivalent key strength.  BCP 86 [RFC3766] offers advice
    on appropriate key sizes.  The National Institute for Standards
    and Technology (NIST) also offers advice on appropriate key sizes
    in [SP800-57].
    A fresh cryptographic key is one that is generated specifically
    for the intended use.  In this situation, a secure association
    protocol is used to establish session keys.  The AAA protocol and
    EAP method MUST ensure that the keying material supplied as an
    input to session key derivation is fresh, and the secure
    association protocol MUST generate a separate session key for each
    session, even if the keying material provided by EAP is cached.  A
    cached key persists after the authentication exchange has
    completed.  For the AAA/EAP server, key caching can happen when
    state is kept on the server.  For the NAS or client, key caching
    can happen when the NAS or client does not destroy keying material
    immediately following the derivation of session keys.
    Session keys MUST NOT be dependent on one another.  Multiple
    session keys may be derived from a higher-level shared secret as
    long as a one-time value, usually called a nonce, is used to
    ensure that each session key is fresh.  The mechanism used to
    generate session keys MUST ensure that the disclosure of one
    session key does not aid the attacker in discovering any other
    session keys.
 EAP, AAA, and the lower layer each bear responsibility for ensuring
 the use of fresh, strong session keys.  EAP methods need to ensure
 the freshness and strength of EAP keying material provided as an
 input to session key derivation.  [RFC3748] Section 7.10 states:

Aboba, et al. Standards Track [Page 64] RFC 5247 EAP Key Management Framework August 2008

    EAP methods SHOULD ensure the freshness of the MSK and EMSK, even
    in cases where one party may not have a high quality random number
    generator.  A RECOMMENDED method is for each party to provide a
    nonce of at least 128 bits, used in the derivation of the MSK and
    EMSK.
 The contribution of nonces enables the EAP peer and server to ensure
 that exported EAP keying material is fresh.
 [RFC3748] Section 7.2.1 describes the "key strength" and "session
 independence" security claims, and [RFC4017] requires EAP methods
 supporting these claims as well as methods capable of providing
 equivalent key strength of 128 bits or greater.  See Section 3.7 for
 more information on key strength.
 The AAA protocol needs to ensure that transported keying material is
 fresh and is not utilized outside its recommended lifetime.  Replay
 protection is necessary for key freshness, but an attacker can
 deliver a stale (and therefore potentially compromised) key in a
 replay-protected message, so replay protection is not sufficient.  As
 discussed in Section 3.5, the Session-Timeout Attribute enables the
 backend authentication server to limit the exposure of transported
 keying material.
 The EAP Session-Id, described in Section 1.4, enables the EAP peer,
 authenticator, and server to distinguish EAP conversations.  However,
 unless the authenticator keeps track of EAP Session-Ids, the
 authenticator cannot use the Session-Id to guarantee the freshness of
 keying material.
 The Secure Association Protocol, described in Section 3.1, MUST
 generate a fresh session key for each session, even if the EAP keying
 material and parameters provided by methods are cached, or either the
 peer or authenticator lack a high entropy random number generator.  A
 RECOMMENDED method is for the peer and authenticator to each provide
 a nonce or counter used in session key derivation.  If a nonce is
 used, it is RECOMMENDED that it be at least 128 bits.  While
 [IEEE-802.11] and IKEv2 [RFC4306] satisfy this requirement,
 [IEEE-802.16e] does not, since randomness is only contributed from
 the Base Station.

Aboba, et al. Standards Track [Page 65] RFC 5247 EAP Key Management Framework August 2008

5.8. Key Scope Limitation

 Mandatory requirement from [RFC4962] Section 3:
    Limit key scope
    Following the principle of least privilege, parties MUST NOT have
    access to keying material that is not needed to perform their
    role.  A party has access to a particular key if it has access to
    all of the secret information needed to derive it.
    Any protocol that is used to establish session keys MUST specify
    the scope for session keys, clearly identifying the parties to
    whom the session key is available.
 Transported keying material is permitted to be accessed by the EAP
 peer, authenticator and server.  The EAP peer and server derive EAP
 keying material during the process of mutually authenticating each
 other using the selected EAP method.  During the Secure Association
 Protocol exchange, the EAP peer utilizes keying material to
 demonstrate to the authenticator that it is the same party that
 authenticated to the EAP server and was authorized by it.  The EAP
 authenticator utilizes the transported keying material to prove to
 the peer not only that the EAP conversation was transported through
 it (this could be demonstrated by a man-in-the-middle), but that it
 was uniquely authorized by the EAP server to provide the peer with
 access to the network.  Unique authorization can only be demonstrated
 if the EAP authenticator does not share the transported keying
 material with a party other than the EAP peer and server.  TSKs are
 permitted to be accessed only by the EAP peer and authenticator (see
 Section 1.5); TSK derivation is discussed in Section 2.1.  Since
 demonstration of authorization within the Secure Association Protocol
 exchange depends on possession of transported keying material, the
 backend authentication server can obtain TSKs unless it deletes the
 transported keying material after sending it.

5.9. Key Naming

 Mandatory requirement from [RFC4962] Section 3:
    Uniquely named keys
    AAA key management proposals require a robust key naming scheme,
    particularly where key caching is supported.  The key name
    provides a way to refer to a key in a protocol so that it is clear
    to all parties which key is being referenced.  Objects that cannot
    be named cannot be managed.  All keys MUST be uniquely named, and
    the key name MUST NOT directly or indirectly disclose the keying

Aboba, et al. Standards Track [Page 66] RFC 5247 EAP Key Management Framework August 2008

    material.  If the key name is not based on the keying material,
    then one can be sure that it cannot be used to assist in a search
    for the key value.
 EAP key names (defined in Section 1.4.1), along with the Peer-Id(s)
 and Server-Id(s), uniquely identify EAP keying material, and do not
 directly or indirectly expose EAP keying material.
 Existing AAA server implementations do not distribute key names along
 with the transported keying material.  However, Diameter EAP
 [RFC4072] Section 4.1.4 defines the EAP-Key-Name AVP for the purpose
 of transporting the EAP Session-Id.  Since the EAP-Key-Name AVP is
 defined within the RADIUS attribute space, it can be used either with
 RADIUS or Diameter.
 Since the authenticator is not provided with the name of the
 transported keying material by existing backend authentication server
 implementations, existing Secure Association Protocols do not utilize
 EAP key names.  For example, [IEEE-802.11] supports PMK caching; to
 enable the peer and authenticator to determine the cached PMK to
 utilize within the 4-way handshake, the PMK needs to be named.  For
 this purpose, [IEEE-802.11] utilizes a PMK naming scheme that is
 based on the key.  Since IKEv2 [RFC4306] does not cache transported
 keying material, it does not need to refer to transported keying
 material.

5.10. Denial-of-Service Attacks

 Key caching can result in vulnerability to denial-of-service attacks.
 For example, EAP methods that create persistent state can be
 vulnerable to denial-of-service attacks on the EAP server by a rogue
 EAP peer.
 To address this vulnerability, EAP methods creating persistent state
 can limit the persistent state created by an EAP peer.  For example,
 for each peer an EAP server can choose to limit persistent state to a
 few EAP conversations, distinguished by the EAP Session-Id.  This
 prevents a rogue peer from denying access to other peers.
 Similarly, to conserve resources an authenticator can choose to limit
 the persistent state corresponding to each peer.  This can be
 accomplished by limiting each peer to persistent state corresponding
 to a few EAP conversations, distinguished by the EAP Session-Id.
 Whether creation of new TSKs implies deletion of previously derived
 TSKs depends on the EAP lower layer.  Where there is no implied
 deletion, the authenticator can choose to limit the number of TSKs
 and associated state that can be stored for each peer.

Aboba, et al. Standards Track [Page 67] RFC 5247 EAP Key Management Framework August 2008

6. References

6.1. Normative References

 [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3748]      Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
                H. Levkowetz, Ed., "Extensible Authentication Protocol
                (EAP)", RFC 3748, June 2004.
 [RFC4962]      Housley, R. and B. Aboba, "Guidance for
                Authentication, Authorization, and Accounting (AAA)
                Key Management", BCP 132, RFC 4962, July 2007.

6.2. Informative References

 [8021XPreAuth] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff
                in a Public Wireless LAN Based on IEEE 802.1x Model",
                Proceedings of the IFIP TC6/WG6.8 Working Conference
                on Personal Wireless Communications, p.175-182,
                October 23-25, 2002.
 [Analysis]     He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way
                Handshake", Proceedings of the 2004 ACM Workshop on
                Wireless Security, pp. 43-50, ISBN: 1-58113-925-X.
 [Bargh]        Bargh, M., Hulsebosch, R., Eertink, E., Prasad, A.,
                Wang, H. and P. Schoo, "Fast Authentication Methods
                for Handovers between IEEE 802.11 Wireless LANs",
                Proceedings of the 2nd ACM international workshop on
                Wireless mobile applications and services on WLAN
                hotspots, October, 2004.
 [GKDP]         Dondeti, L., Xiang, J., and S. Rowles, "GKDP: Group
                Key Distribution Protocol", Work in Progress, March
                2006.
 [He]           He, C., Sundararajan, M., Datta, A. Derek, A. and J.
                C.  Mitchell, "A Modular Correctness Proof of TLS and
                IEEE 802.11i", ACM Conference on Computer and
                Communications Security (CCS '05), November, 2005.

Aboba, et al. Standards Track [Page 68] RFC 5247 EAP Key Management Framework August 2008

 [IEEE-802.11]  Institute of Electrical and Electronics Engineers,
                "Information technology - Telecommunications and
                information exchange between systems - Local and
                metropolitan area networks - Specific Requirements
                Part 11:  Wireless LAN Medium Access Control (MAC) and
                Physical Layer (PHY) Specifications", IEEE Standard
                802.11-2007, 2007.
 [IEEE-802.1X]  Institute of Electrical and Electronics Engineers,
                "Local and Metropolitan Area Networks: Port-Based
                Network Access Control", IEEE Standard 802.1X-2004,
                December 2004.
 [IEEE-802.1Q]  IEEE Standards for Local and Metropolitan Area
                Networks:  Draft Standard for Virtual Bridged Local
                Area Networks, P802.1Q-2003, January 2003.
 [IEEE-802.11i] Institute of Electrical and Electronics Engineers,
                "Supplement to Standard for Telecommunications and
                Information Exchange Between Systems - LAN/MAN
                Specific Requirements - Part 11: Wireless LAN Medium
                Access Control (MAC) and Physical Layer (PHY)
                Specifications:  Specification for Enhanced Security",
                IEEE 802.11i/D1, 2001.
 [IEEE-802.11F] Institute of Electrical and Electronics Engineers,
                "Recommended Practice for Multi-Vendor Access Point
                Interoperability via an Inter-Access Point Protocol
                Across Distribution Systems Supporting IEEE 802.11
                Operation", IEEE 802.11F, July 2003 (now deprecated).
 [IEEE-802.16e] Institute of Electrical and Electronics Engineers,
                "IEEE Standard for Local and Metropolitan Area
                Networks: Part 16: Air Interface for Fixed and Mobile
                Broadband Wireless Access Systems: Amendment for
                Physical and Medium Access Control Layers for Combined
                Fixed and Mobile Operations in Licensed Bands" IEEE
                802.16e, August 2005.
 [IEEE-03-084]  Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K.
                Jang, "Proactive Key Distribution to support fast and
                secure roaming", IEEE 802.11 Working Group, IEEE-03-
                084r1-I, http://www.ieee802.org/11/Documents/
                DocumentHolder/3-084.zip, January 2003.

Aboba, et al. Standards Track [Page 69] RFC 5247 EAP Key Management Framework August 2008

 [EAP-SERVICE]  Arkko, J. and P. Eronen, "Authenticated Service
                Information for the Extensible Authentication Protocol
                (EAP)", Work in Progress, October 2005.
 [SHORT-TERM]   Friedman, A., Sheffer, Y., and A. Shaqed, "Short-Term
                Certificates", Work in Progress, June 2007.
 [HANDOFF]      Arbaugh, W. and B. Aboba, "Handoff Extension to
                RADIUS", Work in Progress, October 2003.
 [EAP-CHANNEL]  Ohba, Y., Parthasrathy, M., and M. Yanagiya, "Channel
                Binding Mechanism Based on Parameter Binding in Key
                Derivation", Work in Progress, June 2007.
 [EAP-BINDING]  Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon,
                "The Compound Authentication Binding Problem", Work in
                Progress, October 2003.
 [MD5Collision] Klima, V., "Tunnels in Hash Functions: MD5 Collisions
                Within a Minute", Cryptology ePrint Archive, March
                2006, http://eprint.iacr.org/2006/105.pdf
 [MishraPro]    Mishra, A., Shin, M. and W. Arbaugh, "Pro-active Key
                Distribution using Neighbor Graphs", IEEE Wireless
                Communications, vol. 11, February 2004.
 [RFC1661]      Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
                STD 51, RFC 1661, July 1994.
 [RFC1968]      Meyer, G., "The PPP Encryption Control Protocol
                (ECP)", RFC 1968, June 1996.
 [RFC2230]      Atkinson, R., "Key Exchange Delegation Record for the
                DNS", RFC 2230, November 1997.
 [RFC2409]      Harkins, D. and D. Carrel, "The Internet Key Exchange
                (IKE)", RFC 2409, November 1998.
 [RFC2516]      Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone,
                D., and R. Wheeler, "A Method for Transmitting PPP
                Over Ethernet (PPPoE)", RFC 2516, February 1999.
 [RFC2548]      Zorn, G., "Microsoft Vendor-specific RADIUS
                Attributes", RFC 2548, March 1999.
 [RFC2607]      Aboba, B. and J. Vollbrecht, "Proxy Chaining and
                Policy Implementation in Roaming", RFC 2607, June
                1999.

Aboba, et al. Standards Track [Page 70] RFC 5247 EAP Key Management Framework August 2008

 [RFC2716]      Aboba, B. and D. Simon, "PPP EAP TLS Authentication
                Protocol", RFC 2716, October 1999.
 [RFC2782]      Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
                for specifying the location of services (DNS SRV)",
                RFC 2782, February 2000.
 [RFC2845]      Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
                Wellington, "Secret Key Transaction Authentication for
                DNS (TSIG)", RFC 2845, May 2000.
 [RFC2865]      Rigney, C., Willens, S., Rubens, A., and W. Simpson,
                "Remote Authentication Dial In User Service (RADIUS)",
                RFC 2865, June 2000.
 [RFC3007]      Wellington, B., "Secure Domain Name System (DNS)
                Dynamic Update", RFC 3007, November 2000.
 [RFC3162]      Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
                RFC 3162, August 2001.
 [RFC3547]      Baugher, M., Weis, B., Hardjono, T., and H. Harney,
                "The Group Domain of Interpretation", RFC 3547, July
                2003.
 [RFC3579]      Aboba, B. and P. Calhoun, "RADIUS (Remote
                Authentication Dial In User Service) Support For
                Extensible Authentication Protocol (EAP)", RFC 3579,
                September 2003.
 [RFC3580]      Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
                Roese, "IEEE 802.1X Remote Authentication Dial In User
                Service (RADIUS) Usage Guidelines", RFC 3580,
                September 2003.
 [RFC3588]      Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
                J. Arkko, "Diameter Base Protocol", RFC 3588,
                September 2003.
 [RFC3766]      Orman, H. and P. Hoffman, "Determining Strengths For
                Public Keys Used For Exchanging Symmetric Keys", BCP
                86, RFC 3766, April 2004.
 [RFC3830]      Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
                K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC
                3830, August 2004.

Aboba, et al. Standards Track [Page 71] RFC 5247 EAP Key Management Framework August 2008

 [RFC4005]      Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
                "Diameter Network Access Server Application", RFC
                4005, August 2005.
 [RFC4017]      Stanley, D., Walker, J., and B. Aboba, "Extensible
                Authentication Protocol (EAP) Method Requirements for
                Wireless LANs", RFC 4017, March 2005.
 [RFC4033]      Arends, R., Austein, R., Larson, M., Massey, D., and
                S. Rose, "DNS Security Introduction and Requirements",
                RFC 4033, March 2005.
 [RFC4035]      Arends, R., Austein, R., Larson, M., Massey, D., and
                S. Rose, "Protocol Modifications for the DNS Security
                Extensions", RFC 4035, March 2005.
 [RFC4067]      Loughney, J., Ed., Nakhjiri, M., Perkins, C., and R.
                Koodli, "Context Transfer Protocol (CXTP)", RFC 4067,
                July 2005.
 [RFC4072]      Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
                Extensible Authentication Protocol (EAP) Application",
                RFC 4072, August 2005.
 [RFC4118]      Yang, L., Zerfos, P., and E. Sadot, "Architecture
                Taxonomy for Control and Provisioning of Wireless
                Access Points (CAPWAP)", RFC 4118, June 2005.
 [RFC4186]      Haverinen, H., Ed., and J. Salowey, Ed., "Extensible
                Authentication Protocol Method for Global System for
                Mobile Communications (GSM) Subscriber Identity
                Modules (EAP-SIM)", RFC 4186, January 2006.
 [RFC4187]      Arkko, J. and H. Haverinen, "Extensible Authentication
                Protocol Method for 3rd Generation Authentication and
                Key Agreement (EAP-AKA)", RFC 4187, January 2006.
 [RFC4282]      Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
                Network Access Identifier", RFC 4282, December 2005.
 [RFC4284]      Adrangi, F., Lortz, V., Bari, F., and P. Eronen,
                "Identity Selection Hints for the Extensible
                Authentication Protocol (EAP)", RFC 4284, January
                2006.
 [RFC4301]      Kent, S. and K. Seo, "Security Architecture for the
                Internet Protocol", RFC 4301, December 2005.

Aboba, et al. Standards Track [Page 72] RFC 5247 EAP Key Management Framework August 2008

 [RFC4306]      Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
                Protocol", RFC 4306, December 2005.
 [RFC4372]      Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
                "Chargeable User Identity", RFC 4372, January 2006.
 [RFC4334]      Housley, R. and T. Moore, "Certificate Extensions and
                Attributes Supporting Authentication in Point-to-Point
                Protocol (PPP) and Wireless Local Area Networks
                (WLAN)", RFC 4334, February 2006.
 [RFC4535]      Harney, H., Meth, U., Colegrove, A., and G. Gross,
                "GSAKMP: Group Secure Association Key Management
                Protocol", RFC 4535, June 2006.
 [RFC4763]      Vanderveen, M. and H. Soliman, "Extensible
                Authentication Protocol Method for Shared-secret
                Authentication and Key Establishment (EAP-SAKE)", RFC
                4763, November 2006.
 [RFC4675]      Congdon, P., Sanchez, M., and B. Aboba, "RADIUS
                Attributes for Virtual LAN and Priority Support", RFC
                4675, September 2006.
 [RFC4718]      Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
                Implementation Guidelines", RFC 4718, October 2006.
 [RFC4764]      Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol:
                A Pre-Shared Key Extensible Authentication Protocol
                (EAP) Method", RFC 4764, January 2007.
 [RFC5176]      Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
                Aboba, "Dynamic Authorization Extensions to Remote
                Authentication Dial In User Service (RADIUS)", RFC
                5176, January 2008.
 [RFC5216]      Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
                Authentication Protocol", RFC 5216, March 2008.
 [RFC5246]      Dierks, T. and E. Rescorla, "The Transport Layer
                Security (TLS) Protocol Version 1.2", RFC 5246, August
                2008.
 [SP800-57]     National Institute of Standards and Technology,
                "Recommendation for Key Management", Special
                Publication 800-57, May 2006.

Aboba, et al. Standards Track [Page 73] RFC 5247 EAP Key Management Framework August 2008

 [Token]        Fantacci, R., Maccari, L., Pecorella, T., and F.
                Frosali, "A secure and performant token-based
                authentication for infrastructure and mesh 802.1X
                networks", IEEE Conference on Computer Communications,
                June 2006.
 [Tokenk]       Ohba, Y., Das, S., and A. Duttak, "Kerberized Handover
                Keying: A Media-Independent Handover Key Management
                Architecture", Mobiarch 2007.

Acknowledgments

 Thanks to Ashwin Palekar, Charlie Kaufman, and Tim Moore of
 Microsoft, Jari Arkko of Ericsson, Dorothy Stanley of Aruba Networks,
 Bob Moskowitz of TruSecure, Jesse Walker of Intel, Joe Salowey of
 Cisco, and Russ Housley of Vigil Security for useful feedback.

Aboba, et al. Standards Track [Page 74] RFC 5247 EAP Key Management Framework August 2008

Appendix A - Exported Parameters in Existing Methods

 This Appendix specifies Session-Id, Peer-Id, Server-Id and
 Key-Lifetime for EAP methods that have been published prior to this
 specification.  Future EAP method specifications MUST include a
 definition of the Session-Id, Peer-Id and Server-Id (could be the
 null string).  In the descriptions that follow, all fields comprising
 the Session-Id are assumed to be in network byte order.
 EAP-Identity
    The EAP-Identity method is defined in [RFC3748].  It does not
    derive keys, and therefore does not define the Session-Id.  The
    Peer-Id and Server-Id are the null string (zero length).
 EAP-Notification
    The EAP-Notification method is defined in [RFC3748].  It does not
    derive keys and therefore does not define the Session-Id.  The
    Peer-Id and Server-Id are the null string (zero length).
 EAP-MD5-Challenge
    The EAP-MD5-Challenge method is defined in [RFC3748].  It does not
    derive keys and therefore does not define the Session-Id.  The
    Peer-Id and Server-Id are the null string (zero length).
 EAP-GTC
    The EAP-GTC method is defined in [RFC3748].  It does not derive
    keys and therefore does not define the Session-Id.  The Peer-Id
    and Server-Id are the null string (zero length).
 EAP-OTP
    The EAP-OTP method is defined in [RFC3748].  It does not derive
    keys and therefore does not define the Session-Id.  The Peer-Id
    and Server-Id are the null string (zero length).

Aboba, et al. Standards Track [Page 75] RFC 5247 EAP Key Management Framework August 2008

 EAP-AKA
    EAP-AKA is defined in [RFC4187].  The EAP-AKA Session-Id is the
    concatenation of the EAP Type Code (0x17) with the contents of the
    RAND field from the AT_RAND attribute, followed by the contents of
    the AUTN field in the AT_AUTN attribute:
    Session-Id = 0x17 || RAND || AUTN
    The Peer-Id is the contents of the Identity field from the
    AT_IDENTITY attribute, using only the Actual Identity Length
    octets from the beginning, however.  Note that the contents are
    used as they are transmitted, regardless of whether the
    transmitted identity was a permanent, pseudonym, or fast EAP
    re-authentication identity.  The Server-Id is the null string
    (zero length).
 EAP-SIM
    EAP-SIM is defined in [RFC4186].  The EAP-SIM Session-Id is the
    concatenation of the EAP Type Code (0x12) with the contents of the
    RAND field from the AT_RAND attribute, followed by the contents of
    the NONCE_MT field in the AT_NONCE_MT attribute:
    Session-Id = 0x12 || RAND || NONCE_MT
    The Peer-Id is the contents of the Identity field from the
    AT_IDENTITY attribute, using only the Actual Identity Length
    octets from the beginning, however.  Note that the contents are
    used as they are transmitted, regardless of whether the
    transmitted identity was a permanent, pseudonym, or fast EAP
    re-authentication identity.  The Server-Id is the null string
    (zero length).
 EAP-PSK
    EAP-PSK is defined in [RFC4764].  The EAP-PSK Session-Id is the
    concatenation of the EAP Type Code (0x2F) with the peer (RAND_P)
    and server (RAND_S) nonces:
    Session-Id = 0x2F || RAND_P || RAND_S
    The Peer-Id is the contents of the ID_P field and the Server-Id is
    the contents of the ID_S field.

Aboba, et al. Standards Track [Page 76] RFC 5247 EAP Key Management Framework August 2008

 EAP-SAKE
    EAP-SAKE is defined in [RFC4763].  The EAP-SAKE Session-Id is the
    concatenation of the EAP Type Code (0x30) with the contents of the
    RAND_S field from the AT_RAND_S attribute, followed by the
    contents of the RAND_P field in the AT_RAND_P attribute:
    Session-Id = 0x30 || RAND_S || RAND_P
    Note that the EAP-SAKE Session-Id is not the same as the "Session
    ID" parameter chosen by the Server, which is sent in the first
    message, and replicated in subsequent messages.  The Peer-Id is
    contained within the value field of the AT_PEERID attribute and
    the Server-Id, if available, is contained in the value field of
    the AT_SERVERID attribute.
 EAP-TLS
    For EAP-TLS, the Peer-Id, Server-Id and Session-Id are defined in
    [RFC5216].

Aboba, et al. Standards Track [Page 77] RFC 5247 EAP Key Management Framework August 2008

Authors' Addresses

  Bernard Aboba
  Microsoft Corporation
  One Microsoft Way
  Redmond, WA 98052
  EMail: bernarda@microsoft.com
  Phone: +1 425 706 6605
  Fax:   +1 425 936 7329
  Dan Simon
  Microsoft Research
  Microsoft Corporation
  One Microsoft Way
  Redmond, WA 98052
  EMail: dansimon@microsoft.com
  Phone: +1 425 706 6711
  Fax:   +1 425 936 7329
  Pasi Eronen
  Nokia Research Center
  P.O. Box 407
  FIN-00045 Nokia Group
  Finland
  EMail: pasi.eronen@nokia.com

Aboba, et al. Standards Track [Page 78] RFC 5247 EAP Key Management Framework August 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Aboba, et al. Standards Track [Page 79]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5247.txt · Last modified: 2008/08/14 23:09 (external edit)