--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / freeradius.git / commitdiff