doc: Add RFC documents

1 files changed, 4427 insertions, 0 deletions

diff --git a/doc/rfc/rfc5247.txt b/doc/rfc/rfc5247.txt
new file mode 100644
index 0000000..f5ed788
--- /dev/null
+++ b/doc/rfc/rfc5247.txt
@@ -0,0 +1,4427 @@
+
+
+
+
+
+
+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) | |            |
+|   |         +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ |            |
+|   |               ^             |               |       |            |
+|   |               |             |               |       |            V
++-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+         ---+
+    |               |             |               |                    ^
+    |               |             |               |           Exported |
+    | Peer-Id(s),   | channel     | MSK (64+B)    | IV (64B)      by   |
+    | Server-Id(s), | bindings    | EMSK (64+B)   | (Optional)    EAP  |
+    | Session-Id    | & Result    |               |             Method |
+    V               V             V               V                    V
+
+     Figure 2:  EAP Method Parameter Import/Export
+
+   Peer-Id
+
+      If an EAP method that generates keys authenticates one or more
+      method-specific peer identities, those identities are exported by
+      the method as the Peer-Id(s).  It is possible for more than one
+      Peer-Id to be exported by an EAP method.  Not all EAP methods
+      provide a method-specific peer identity; where this is not
+      defined, the Peer-Id is the null string.  In EAP methods that do
+      not support key generation, the Peer-Id MUST be the null string.
+      Where an EAP method that derives keys does not provide a Peer-Id,
+      the EAP server will not authenticate the identity of the EAP peer
+      with which it derived keying material.
+
+
+
+
+
+
+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]
+