RFC 5247
Extensible Authentication Protocol (EAP) Key Management Framework
Part 1 of 18 🎀
Title Block 📜
- RFC: 5247 🌸
- Title: Extensible Authentication Protocol (EAP) Key Management Framework
- Authors: B. Aboba and D. Simon (Microsoft Corporation), P. Eronen (Nokia)
- Working group: Network Working Group
- Category: Standards Track
- Date: August 2008
- Updates: RFC 3748 🦋
- Obsoletes: nothing listed in the header
Status of This Memo ✨
Okay bestie, this one is a Standards Track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶. For where this protocol stands right now, check the current edition of the "Internet Official Protocol Standards" (STD 1) 💅. Distribution of this memo is unlimited 🌈.
Abstract ✨
EAP, which is defined in RFC 3748, is the thing that makes extensible network access authentication possible 🔥. This doc lays out the EAP key hierarchy and gives a framework for moving around the keying material and parameters that EAP authentication algorithms generate. Those algorithms are called "methods" 🧚. It also includes a detailed system-level security analysis that explains the conditions under which the key management guidelines in RFC 4962 can be satisfied 👑.
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 ..............751. Introduction ✨
Okay so EAP (defined in [RFC3748]) was built for extensible authentication on network access, in situations where the Internet Protocol (IP) protocol is not available 🌸. It started out for Point-to-Point Protocol (PPP) [RFC1661], and then it spread 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]. It's giving main character energy 💅.
EAP is a two-party protocol that happens between the EAP peer and server 🫶. Inside EAP, keying material gets generated by EAP authentication algorithms, which are called "methods" 🔑. Some of that keying material can be used by the EAP methods themselves, and some of it can be exported ✨. On top of exporting keying material, EAP methods can also export related parameters like authenticated peer and server identities and a unique EAP conversation identifier 🦋. They can also import and export lower-layer parameters, known as "channel binding parameters" (or just "channel bindings") 🧚.
This document specifies the EAP key hierarchy and gives a framework for moving around the keying material and parameters that EAP methods generate 💖. It also includes a detailed security analysis, which looks at the conditions under which the requirements in "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management" [RFC4962] can be satisfied 👑. Bestie, this is the part where the security nerd in me gets obsessed 🙈.
1.1. Requirements Language 🎀
Here's the vibe on the BCP 14 words: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read exactly the way [RFC2119] describes 💅. No reinterpreting them, periodt 💀.
1.2. Terminology
Okay bestie, time for the vocab lesson 📚💅 The terms "Cryptographic binding", "Cryptographic separation", "Key strength" and "Mutual authentication" are defined in [RFC3748] and mean the exact same thing here. This doc also leans on a bunch of other terms, so let's go 🦋
4-Way Handshake
A pairwise Authentication and Key Management Protocol (AKMP) defined in [IEEE-802.11]. It confirms that two parties both possess a Pairwise Master Key, and it hands out a Group Key too 🔑
AAA (Authentication, Authorization, and Accounting)
AAA protocols with EAP support include "RADIUS Support for EAP" [RFC3579] and "Diameter EAP Application" [RFC4072]. In this document, "AAA server" and "backend authentication server" mean the same thing and get used interchangeably 🎀
AAA-Key
AAA-Key is just another name for the Master Session Key (MSK). Since AAA can carry multiple keys, the term is potentially confusing, so this document doesn't use it 🙈
Authenticator
The entity that starts EAP authentication ✨
Backend Authentication Server
An entity that provides an authentication service to an authenticator. When it's used, this server typically runs EAP methods on behalf of the authenticator. This terminology is also used in [IEEE-802.1X] 💜
Channel Binding
A secure mechanism that makes sure a subset of the parameters sent by the authenticator (like authenticator identifiers and properties) gets agreed upon by the EAP peer and server. The parameters are also expected to be securely agreed upon by the EAP peer and authenticator via the lower layer, as long as the authenticator advertised them. It's giving security tbh 🔥
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 like Transient EAP Keys (TEKs) 🧚
EAP Pre-Authentication
Using EAP to pre-establish EAP keying material on an authenticator before the peer shows up at the access network that authenticator manages. Early planning, iconic 👑
EAP Re-Authentication
EAP authentication between an EAP peer and a server that already share valid, unexpired EAP keying material. No need to start from zero 💅
EAP Server
The entity that terminates the EAP authentication method with the peer. If no backend authentication server is used, the EAP server is part of the authenticator. If the authenticator is operating in pass-through mode, the EAP server lives 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)
Extra keying material derived between the peer and server that the EAP method exports. The EMSK is at least 64 octets long and is never shared with a third party. The EMSK MUST be at least as long as the MSK in size. Protect that EMSK bestie 🔐
Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an initialization vector field, derived between the peer and EAP server. The IV is a known value in methods like EAP-TLS (Transport Layer Security) [RFC5216], so it can't be used by itself to compute anything that needs to stay secret. That's why 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, "keying material" means EAP keying material as well as derived keying material 💖
Key Scope
The parties who have access to a key ✨
Key Wrap
Encrypting one symmetric cryptographic key inside another. The algorithm doing 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 often use long-term secrets to enable authentication between the peer and server. For a method based on pre-shared key authentication, the long-term credential is the pre-shared key. For a public-key-based method, it's the corresponding private key 🗝️
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 derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 octets long 🌟
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 way. 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. 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. Each protocol has its own flavour 🍭
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. It's a whole package 📦
Secure Association Protocol
An exchange between the EAP peer and authenticator that manages security associations derived from EAP exchanges. The protocol establishes unicast and (optionally) multicast security associations, which include symmetric keys and a context for using those keys. The 4-way handshake defined within [IEEE-802.11] is an example of a Secure Association Protocol 🤝
Session-Id
The EAP Session-Id uniquely identifies an EAP authentication exchange between an EAP peer (identified by the Peer-Id(s)) and server (identified by the Server-Id(s)). For more info, see Section 1.4 📇
Transient EAP Keys (TEKs)
Session keys used to set up 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 the EAP peer and server for protecting the EAP conversation. The TEKs are stored locally by the EAP method and are not exported. Also note: the ciphersuite used to set up that protected channel is unrelated to the ciphersuite used later to protect data sent between the EAP peer and authenticator. Two different vibes, not the same thing 🙃
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
When EAP key derivation is supported, the conversation usually goes through 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, phases 0, 1b, and 2 are handled outside of 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 find authenticators and discover what they can do. A peer can locate an authenticator that provides access to a particular network, or it can locate an authenticator behind a bridge that it wants to set up a Secure Association with. Discovery can happen manually or automatically, depending on the lower layer EAP runs over 🔍
The authentication phase (phase 1) can start once the peer and authenticator have discovered each other. If this phase happens, it always includes EAP authentication (phase 1a). When the chosen EAP method supports key derivation, EAP keying material gets derived on both the peer and the EAP server during phase 1a 🔑
An extra step (phase 1b) is needed in deployments that include a backend authentication server, to move keying material from the backend authentication server to the authenticator. To obey the principle of mode independence (see Section 1.6.1), any keying material the lower layer needs is transported from the EAP server to the authenticator whenever a backend authentication server is present. Since existing TSK derivation and transport techniques depend solely on the MSK, in existing implementations that's the only keying material replicated in the AAA key transport phase 1b 🧳
Successfully finishing EAP authentication and key derivation doesn't automatically mean the peer is committed to joining the network tied to that EAP server. That commitment is implied by creating 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) happens between the peer and authenticator to manage the creation and deletion of unicast (phase 2a) and multicast (phase 2b) security associations between them. Here's the conversation between the parties, 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) | |
| | |
Figure 1: Conversation Overview1.3.1. Examples
okay so existing EAP lower layers handle phase 0, 2a, and 2b in totally different ways 💅 let's tour them 🦋
- PPP 🎀: The Point-to-Point Protocol, defined in [RFC1661], doesn't support discovery, and it doesn't include a Secure Association Protocol either. not it 😭
- PPPoE 🌸: PPP over Ethernet, defined in [RFC2516], does include support for a Discovery stage (phase 0) ✨ The EAP peer sends a PPPoE Active Discovery Initiation (PADI) packet to the broadcast address, indicating the service it's requesting. Then the Access Concentrator replies with a PPPoE Active Discovery Offer (PADO) packet containing its name, the service name, and an indication of the services the concentrator offers. The discovery phase is not secured 🙈 And PPPoE, like PPP, doesn't include a Secure Association Protocol.
- IKEv2 🔥: Internet Key Exchange v2 (IKEv2), defined in [RFC4306], supports EAP and handles unicast security associations (phase 2a). Multicast security associations (phase 2b) usually don't involve EAP though, so they need a group key management protocol like 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 finding IPsec security gateways. [RFC2230] talks about using Key eXchange (KX) Resource Records (RRs) for this. KX RRs are supported by lots of Domain Name Service (DNS) server implementations, but they haven't been widely deployed yet 🥲 Alternatively, DNS SRV RRs [RFC2782] can be used for this purpose. And if DNS is used for gateway location, DNS security mechanisms like 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 with the Beacon and Probe Request/Response mechanisms. Access Points (APs) periodically announce their Service Set Identifiers (SSIDs) and capabilities using Beacon frames, and stations can query for APs by sending a Probe Request. Neither Beacon nor Probe Request/Response frames are secured, so it's giving open door 🚪 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 to support peer-to-peer communications. And 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], doesn't support discovery (phase 0), and it doesn't provide for derivation of unicast or multicast secure associations 💀
1.4. EAP Key Hierarchy ✨
okay this is the part where it gets really structured 🗝️ As shown in Figure 2, the EAP method key derivation has, at the root, the long-term credential used 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 along with extra info. That info is usually used outside of the EAP method to decide whether to grant access to a service. The peer stores whatever it needs to pick which secret to use for which service 🔑
If authentication is based on proof of possession of the private key that matches the public key in 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 what it needs to choose which certificate to use for which service 📜 Based on the long-term credential set up 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.
EAP methods also MAY export the IV, but the use of the IV is deprecated 🙅♀️ The EMSK MUST NOT be provided to an entity outside the EAP server or peer. It's also not allowed 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. Do not let the EMSK leak, bestie 🚫🫶
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)). They MAY export one or more method-specific server identifiers (Server-Id(s)) too 💜 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 they're 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 🎀
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| 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/ExportPeer-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's 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 that's 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 🫠 And where an EAP method that derives keys doesn't provide a Peer-Id, the EAP server will not authenticate the identity of the EAP peer it derived keying material with 😤
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's 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 that's 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 🧃 And where an EAP method that derives keys doesn't provide a Server-Id, the EAP peer will not authenticate the identity of the EAP server it derived EAP keying material with 🙃
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-IdWhere 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-IdThe Method-Id is typically constructed from nonces or counters used within the EAP method exchange. Including the Type Code or Expanded Type Code in the EAP Session-Id makes sure that each EAP method has a distinct Session-Id space 🌈 Since an EAP session isn't 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 🦋
Channel Binding 🔗
Channel binding is the process by which lower-layer parameters are verified for consistency between the EAP peer and server. 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 🔑
okay so every key in the EAP key management framework gets a name (a unique identifier) and a scope (who's allowed to have it) 🫶 for exported keying material and TEKs, the scope is set by the authenticated method-specific peer identities (Peer-Id(s)) and the authenticated server identities (Server-Id(s)), whenever those are available ✨
MSK and EMSK Names 🎀 The MSK and EMSK get exported by the EAP peer and EAP server, and they MUST be named using the EAP Session-Id plus a binary or textual indication of which EAP keying material it is ✨ no skipping this one bestie 💅
PMK Name 🌸 this document does not define a naming scheme for the Pairwise Master Key (PMK) 🙈 the PMK is only identified by the name of the key it was derived from ✨
side quest 🧚: IEEE 802.11 does name the PMK so it can be referred to in the Secure Association Protocol. that name (the PMKID) is based on a hash of the PMK itself plus some other parameters 💜 (see [IEEE-802.11] Section 8.5.1.2) iykyk 💀
TEK Name 🦋 Transient EAP Keys (TEKs) MAY be named ✨ and how they get named is specified in the EAP method specification 💖
TSK Name 🍓 Transient Session Keys (TSKs) are typically named 🫶 but their naming is specified in the lower layer, so the right set of TSKs can be identified when processing a given packet 💅
1.5. Security Goals 🛡️
okay the whole point of the EAP conversation is to derive fresh session keys between the EAP peer and authenticator that are known ONLY to those two parties 😭 and for both the peer and the authenticator to show they're authorized to do their jobs, either to each other or through a trusted third party (the backend authentication server) 👑
finishing an EAP method exchange that supports key derivation (phase 1a) gets you EAP keying material (MSK, EMSK, TEKs) that's known only to the EAP peer (identified by the Peer-Id(s)) and the EAP server (identified by the Server-Id(s)) ✨ both of them know that material is fresh 🌈 the Peer-Id and Server-Id get talked about in Sections 1.4, 2.4, and 2.5 and also in Appendix A 🧚 key freshness is covered in Sections 3.4, 3.5, and 5.7 💜
finishing the AAA exchange (phase 1b) transports keying material from the EAP server (identified by the Server-Id(s)) to the EAP authenticator (identified by the NAS-Identifier) without disclosing it to anyone else 🔥 the EAP server and authenticator both know that material is fresh too ✨ disclosure issues are covered in Sections 3.8 and 5.3, and the security properties of AAA protocols are covered in Sections 5.1 - 5.9 🫶
the backend authentication server is trusted to transport keying material ONLY to the authenticator that was set up with the peer 🙈 and it's trusted to send that material to no other parties either 💅 in lots of systems, the keying material the EAP peer and EAP server established gets combined with publicly available data to derive other keys 🍓 the backend server is trusted to NOT derive those same keys or act as a man-in-the-middle, even though it has access to the keying material it would need to do that 😭🫶
the authenticator is a trusted party too 👑 it's trusted not to hand keying material from the backend authentication server to any other parties 💖 if the authenticator uses a key derivation function to derive extra keying material, it's trusted to hand that derived material only to the appropriate party that the peer knows about, and nobody else 🦋 when this approach is used, you have to be careful that the resulting key management system meets all the principles in [RFC4962], confirming that keys used to protect data are known only by the peer and the authenticator 🔐 (no cap, this part is serious 💀)
completing the Secure Association Protocol (phase 2) results in derivation or transport of Transient Session Keys (TSKs) that are known only to the EAP peer (identified by the Peer-Id(s)) and the authenticator (identified by the NAS-Identifier) ✨ both the peer and the authenticator know the TSKs are fresh 🌸 and both of them show they're authorized to do their roles 👑 authorization is discussed in Sections 4.3.2 and 5.5, and the security properties of Secure Association Protocols are discussed in Section 3.1 💜
1.6. EAP Invariants 🌈
there are some basic characteristics, called "EAP Invariants", that hold true for EAP implementations ✨ they are:
- Mode independence 🧚
- Media independence 🦋
- Method independence 🍓
- Ciphersuite independence 💅
1.6.1. Mode Independence 🎀
EAP usually gets deployed to support extensible network access authentication, where a peer wants network access through one or more authenticators ✨ when authenticators are deployed standalone, the EAP conversation happens between the peer and the authenticator, and the authenticator locally implements one or more EAP methods 💖 but when it's used in "pass-through" mode, EAP lets you deploy new authentication methods WITHOUT needing new code on the authenticator 🔥 main character energy, honestly 👑
the authenticator can implement some EAP methods locally and use them to authenticate its own local users 🫶 at the same time, it can 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 works by encapsulating EAP packets inside the Authentication, Authorization, and Accounting (AAA) protocol spoken between the authenticator and the backend authentication server 💜 AAA protocols that support EAP include RADIUS [RFC3579] and Diameter [RFC4072] 🌸
it's a fundamental property of EAP that, at the EAP method layer, the conversation between the EAP peer and server is unaffected by whether the authenticator is running in "pass-through" mode ✨ EAP methods work identically in every way, including key derivation and parameter import/export, whether or not the authenticator is a pass-through 😭
when an EAP method that supports key derivation completes successfully, EAP keying material and parameters get exported on the EAP peer and server 💖 the peer or server can import channel binding parameters that might include the identity of the EAP authenticator, but that info is treated as opaque octets 🙈 so within EAP, the only identities that matter are the Peer-Id(s) and Server-Id(s) 💅 channel binding parameters only get interpreted by the lower layer 🍓
within EAP, the main job of the AAA protocol is to keep mode independence intact 👑 as far as the EAP peer is concerned, its conversation with the EAP authenticator, and all the consequences of that conversation, are identical no matter what mode the authenticator is operating in ✨ literally the whole point 🫶
1.6.2. Media Independence 🌊
one of EAP's goals is to let EAP methods run on any lower layer that meets the criteria in [RFC3748] Section 3.1 🧚 for example, as [RFC3748] describes, EAP authentication can run over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and wireless networks like 802.11 [IEEE-802.11] and 802.16 [IEEE-802.16e] 💜
to keep media independence, EAP has to avoid depending on media-specific elements 🙈 for example, EAP methods can't be assumed to know anything about the lower layer they're carried over, and they can't be restricted to identifiers tied to one particular usage environment (e.g., Medium Access Control (MAC) addresses) 🦋
media independence can still be kept inside EAP methods that support channel binding or method-specific identification 🌸 an EAP method doesn't need to know what's inside an identifier to use it ✨ that's how a method can use media-specific identifiers like MAC addresses without messing up media independence 🫶 channel binding parameters are treated as opaque octets by EAP methods, so handling them doesn't require any media-specific knowledge 💅
1.6.3. Method Independence 🍓
pass-through lets authenticators support any method implemented on the peer and server, not just methods implemented locally 💖 this means the authenticator doesn't have to implement the EAP methods that peers are configured to use 🧚 in fact, a pass-through authenticator doesn't need to implement any EAP methods at all, so it can't 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 when there's no single EAP method that's both mandatory to implement AND offers acceptable security for the media in use 🔥 for example, the [RFC3748] mandatory-to-implement EAP method (MD5-Challenge) doesn't provide dictionary attack resistance, mutual authentication, or key derivation, so it isn't appropriate for Wireless Local Area Network (WLAN) authentication [RFC4017] 💀 still, the peer and authenticator can interoperate as long as a suitable EAP method is supported on both the EAP peer and the server 🫶✨
1.6.4. Ciphersuite Independence
okay so ciphersuite independence is basically a requirement for media independence 💅 lower-layer ciphersuites change from medium to medium, so media independence needs the exported EAP keying material to be large enough (with sufficient entropy 🎀) to handle any ciphersuite. literally any one 😭
EAP methods can negotiate the ciphersuite that protects the EAP conversation itself ✨. but the ciphersuite protecting the data after EAP authentication is done gets negotiated between the peer and authenticator inside the lower layer, outside of EAP. not EAP's job, bestie 🫶
example time 🧚: in PPP, the ciphersuite is negotiated in the Encryption Control Protocol (ECP) defined in [RFC1968], after EAP auth is finished. over in [IEEE-802.11], the AP ciphersuites get advertised in the Beacon and Probe Responses before EAP auth, and then they get securely verified during a 4-way handshake exchange 🦋
since the data ciphersuites depend on the lower layer, making EAP methods know about lower-layer ciphersuites would compromise media independence 💀 so methods export ciphersuite-independent EAP keying material instead. ciphersuite negotiation happens in the lower layer, so there's no need for lower-layer ciphersuite negotiation within EAP. iconic behavior, honestly 👑
if a ciphersuite wants to be usable within the EAP keying framework, its spec needs to describe how TSKs suitable for that ciphersuite are derived from the exported EAP keying material 🌸. and to keep 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, I'm obsessed 😭:
- Reduced update requirements 🔥: ciphersuite independence lets EAP methods work with new ciphersuites without the methods needing updates. if EAP methods had to specify how to derive transient session keys for each ciphersuite, they'd need updating every time a new ciphersuite got developed. plus, backend authentication servers might not be usable with all EAP-capable authenticators, since the backend authentication server would also need an update each time support for a new ciphersuite gets added to the authenticator 💀
- Reduced EAP method complexity 💖: EAP methods don't have to include ciphersuite-specific code. if every EAP method had ciphersuite-specific code for transient session key derivation, the complexity would go up and the effort would get duplicated 😤
- Simplified configuration 🎀: EAP method implementations on the peer and server don't have to configure ciphersuite-specific parameters. the ciphersuite gets negotiated between the peer and authenticator outside of EAP. when the authenticator runs in "pass-through" mode, the EAP server isn't a party to that negotiation and isn't involved in the data flow between the EAP peer and authenticator 🧚. so the EAP server doesn't know the ciphersuites and negotiation policies the peer and authenticator use, and it isn't aware of the ciphersuite negotiated between them. for example, since ECP negotiation happens after authentication when running over PPP, the EAP peer and server can't anticipate the negotiated ciphersuite, so that info can't be handed to the EAP method ✨
2. Lower-Layer Operation ✨
okay now the lower layer part 🌈. once EAP auth completes, the EAP keying material and parameters the EAP method exported get handed to the lower layer and the AAA layer (if there is one) 🎀. that includes 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 it might still be provided 🙈
to keep the EAP keying material derived within methods secure, lower layers MUST NOT export keys passed down by EAP methods 🔒. that means EAP keying material passed to a lower layer is for the exclusive use of that lower layer, and it MUST NOT be used within another lower layer. this way, compromising one lower layer can't compromise 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, and 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 that get requested by and passed down to the AAA layer MAY be replicated to the AAA layer on the authenticator (except the EMSK 🙅). then on the authenticator, the AAA layer hands the replicated keying material and parameters to the lower layer the EAP authentication conversation happened over. this is how mode independence stays maintained 🦋
and last but definitely not least: the EAP layer, plus the peer and authenticator layers, MUST NOT modify or cache keying material or parameters (channel bindings included) passing in either direction between the EAP method layer and the lower layer or AAA layer 👑
2.1. Transient Session Keys
where the lower layer explicitly supports it, lower layers MAY cache keying material, including exported EAP keying material and/or TSKs ✨. the structure of that key cache gets defined by the lower layer. for interoperability's sake, new lower-layer specifications MUST describe key caching behavior 🎀. unless the lower layer explicitly specifies otherwise, the EAP peer, server, and authenticator MUST assume that peers and authenticators do NOT cache keying material 🙈. existing EAP lower layers and AAA layers handle transient session key generation and EAP keying material caching in different ways, so let's go through them 🌸
IEEE 802.1X-2004
when used with wired networks, IEEE 802.1X-2004 [IEEE-802.1X] doesn't support link-layer ciphersuites 💀. as a result, it doesn't provide for generating TSKs or caching EAP keying material and parameters. once EAP authentication completes, it's assumed that EAP keying material and parameters are discarded, because on IEEE 802 wired networks there's no subsequent Secure Association Protocol exchange. Perfect Forward Secrecy (PFS) is only possible if the negotiated EAP method supports it 🔥
PPP
PPP, defined in [RFC1661], doesn't include a Secure Association Protocol and doesn't support caching 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 ever supported caching EAP keying material, that could result in TSK reuse 🙅. so once the PPP session is terminated, EAP keying material and parameters MUST be discarded. since caching EAP keying material isn't permitted within PPP, there's no way to handle TSK re-key without EAP re-authentication 💅. Perfect Forward Secrecy (PFS) is only possible if the negotiated EAP method supports it 🌸
IKEv2
IKEv2, defined in [RFC4306], only uses the MSK for authentication purposes, not key derivation 🧚. the EMSK, IV, Peer-Id, Server-Id, or Session-Id aren't used. so the TSKs IKEv2 derives are cryptographically independent of the EAP keying material, and re-key of IPsec SAs can be handled without EAP re-authentication 👑. within IKEv2, it's possible to negotiate PFS regardless of which EAP method got negotiated ✨. IKEv2 as specified in [RFC4306] doesn't cache EAP keying material or parameters; once IKEv2 authentication completes, it's assumed that EAP keying material and parameters are discarded 🫶. that means the Session-Timeout Attribute gets 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 in [IEEE-802.11]. in IEEE 802.11, TSKs get derived from the MSK using a Secure Association Protocol called the 4-way handshake, which includes a nonce exchange 💖. this guarantees TSK freshness even if the MSK is reused, which is so clever 😭. the 4-way handshake also enables TSK re-key without EAP re-authentication 🌈. PFS is only possible within IEEE 802.11 if caching isn't 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 where the authenticator chooses the TSKs without any contribution from the peer 🧚. the TSKs are encrypted, authenticated, and integrity protected using the MSK, and they get 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] don't support caching keying material or parameters 😤. in existing AAA clients, proxy, and server implementations, exported EAP keying material (MSK, EMSK, and IV), along with parameters and derived keys, isn't cached and MUST be presumed lost after the AAA exchange completes 🙈
to avoid key reuse, the AAA layer MUST delete transported keys once they're sent 🔥. the AAA layer MUST NOT retain keys it has previously sent. for example, an AAA layer that has transported the MSK MUST delete it, and keys MUST NOT be derived from the MSK from that point forward 👑 bestie, that's the whole tea ☕💖
2.2. Authenticator and Peer Architecture ✨
Okay so this spec doesn't boss anyone around about how the EAP authenticator or peer is built 💅 Any of the authenticator architectures in [RFC4118] totally works. That means lower layers have to identify EAP peers and authenticators unambiguously, without sneaking in assumptions about what the peer or authenticator looks like 🧚
For example, multiple base stations plus a "controller" (like a WLAN switch) can act as one EAP authenticator together 🏰 In that setup, the "base station identity" doesn't even matter to the EAP method conversation, except maybe as an opaque blob for channel binding. And tons of 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 be on the network through multiple authenticators, or through multiple ports on one authenticator. An authenticator can also give network access to multiple peers, each through its own port. When one physical authenticator pretends to be several virtual ones (multi-personality, iconic 😭), a single physical port can end up belonging to multiple virtual authenticators.
An authenticator can be set up to talk to more than one EAP server, and each of those servers is set up to talk to a subset of the authenticators. Figure 3 shows the whole vibe 👑
2.3. Authenticator Identification 🪪
The EAP method conversation is between the EAP peer and server 🤝 The authenticator identity, if the EAP method even cares about it, gets treated as an opaque blob for channel binding (see Section 5.3.3). BUT the authenticator identity matters a lot 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 backend server's point of view, keying material and parameters get shipped to the EAP authenticator identified by the NAS-Identifier Attribute. An EAP authenticator MUST NOT share EAP keying material or parameters with anyone else. So if the EAP peer or backend authentication server spots EAP keying material and parameters being used outside the scope defined by the NAS-Identifier, the keying material MUST be considered compromised 🚨💀
The Secure Association Protocol conversation is between the peer and the authenticator. For lower layers that support key caching, it's super important that the EAP peer, authenticator, and backend server all have the same view of the usage scope of the transported keying material 🧠 To make that happen, it is RECOMMENDED that the Secure Association Protocol explicitly communicate the usage scope of the EAP keying material passed down to the lower layer, instead of implicitly assuming it's 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 can't be described by a single endpoint address 🙈 Same deal for peers: where a peer can have multiple ports and sharing EAP keying material and parameters between peer ports of the same link type is allowed, the extent of the peer key cache can't be communicated with a single endpoint address either. So instead, it is RECOMMENDED that the EAP peer and authenticator consistently identify themselves using explicit identifiers, rather than endpoint addresses or port identifiers 🎀
AAA protocols like RADIUS [RFC3579] and Diameter [RFC4072] give a way to identify AAA clients. Since the EAP authenticator and AAA client MUST be co-resident, that mechanism is also applicable to identifying 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 explicitly identifying the authenticator, both within the AAA protocol exchange and the Secure Association Protocol conversation 💜
Problems that can pop up when 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.
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) don't 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 one physical authenticator advertises itself as multiple virtual authenticators, if those virtual authenticators don't maintain logically separate key caches, then by authenticating to one virtual authenticator, the peer can gain access to the other virtual authenticators sharing that key cache 😱
For example, say a physical authenticator runs a "Guest" virtual authenticator and a "Corporate Intranet" virtual authenticator. An attacker acting as a peer could authenticate with the "Guest" virtual authenticator and derive EAP keying material. If "Guest" and "Corporate Intranet" share a key cache, the peer can use the EAP keying material derived for the "Guest" network to get into the "Corporate Intranet" network 💀 Rude!!
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 🎀
Okay so, [RFC3748] Section 7.3 says the identity the peer sends in the EAP-Response/Identity can be totally different from the peer identities the EAP method actually authenticates. Like, the identity in EAP-Response/Identity can be a privacy identifier, which is covered in "The Network Access Identifier" [RFC4282] Section 2. 🦋 As [RFC4284] points out, you can also use a Network Access Identifier (NAI) for source routing. An NAI used that way is called "decorated," as described in [RFC4282] Section 2.7. Iconic behavior, honestly. 💅
When the EAP peer puts its Network Access Identifier (NAI) in the EAP-Response/Identity, as described in [RFC3579], the authenticator copies that NAI into the User-Name Attribute inside the Access-Request. As the Access-Request travels toward the backend authentication server, AAA proxies strip the decoration off the NAI in the User-Name Attribute. The NAI inside the EAP-Response/Identity that's encapsulated in the Access-Request stays exactly the same. 🫶 So when the Access-Request finally lands at the backend authentication server, the EAP-Response/Identity can look different from the User-Name Attribute, which might have some or all of its decoration gone. 😭 If there's no Peer-Id, the backend authentication server SHOULD use the contents of the User-Name Attribute as the peer identity, not the EAP-Response/Identity. Plot twist, but that's the move. 🌸
An EAP method can export more than one Peer-Id. For example, a peer certificate can hold several peer identities. In a tunnel method, peer identities can be authenticated in both the outer and inner exchanges, and those identities can differ in type and contents. Like, an outer exchange might give a Peer-Id as a Relative Distinguished Name (RDN), while an inner exchange identifies the peer by its NAI or MAC address. 🧚 If the EAP keying material comes only from the outer exchange, then only the outer Peer-Id(s) get exported. If the keying material comes from both the inner and outer exchanges, the tunnel method exports both the inner and outer Peer-Id(s). ✨
2.5. Server Identification 👑
An EAP method can also export more than one Server-Id. For example, a server certificate can contain several server identities. In a tunnel method, server identities could be authenticated in both the outer and inner exchanges, and they could be different in type and contents. Like, an outer exchange might provide a Server-Id as an IP address, while an inner exchange identifies the server by its Fully-Qualified Domain Name (FQDN) or hostname. 🌈 If the EAP keying material comes only from the outer exchange, the EAP method exports only the outer Server-Id(s). If it comes from both the inner and outer exchanges, the EAP method exports both the inner and outer Server-Id(s). 💖
As Figure 3 shows, an authenticator can be set up to talk to multiple EAP servers. Which EAP server it talks to can change depending on configuration and on which servers are available. The EAP peer can assume that all the EAP servers in a realm have the credentials needed to validate an authentication attempt. What it can't assume is that those servers share persistent state. 🍓
Authenticators can be configured with different primary or secondary EAP servers to balance the load. The authenticator can also pick the EAP server dynamically. If there's a communication failure, it can fail over to another EAP server. For example, in Figure 3, Authenticator2 can start out with EAP server1 as its primary backend authentication server and EAP server2 as the backup. But if EAP server1 goes down, EAP server2 can become the primary server. Main character energy for the authenticator. 🦋
Generally, the EAP peer can't steer an authentication attempt to a specific EAP server within a realm. That decision is made by AAA clients. The peer also can't figure out which EAP server it'll be talking to before the EAP method conversation starts. The Server-Id isn't included in the EAP-Request/Identity. Since the EAP server might be picked dynamically, the authenticator usually can't advertise the Server-Id during the discovery phase. Some EAP methods don't export the Server-Id at all, so the EAP peer might never learn which server it was talking to after a successful EAP conversation. 🙈
So an EAP peer that connects to a new authenticator, or reconnects to the same one, can end up talking to a different EAP server. Fast reconnect, defined in [RFC3748] Section 7.2, can fail if the EAP server the peer talks to isn't the same one it originally set up a security association with. For example, an EAP peer trying to resume an EAP-TLS session might find that the new EAP-TLS server doesn't have the TLS Master Key identified by the TLS Session-Id. The session resumption then fails, and a full EAP-TLS exchange is needed. 😭💀
EAP methods that export the Server-Id MUST authenticate the server. Not every EAP method that supports mutual authentication gives a non-null Server-Id, though. Some methods only let the EAP peer verify that the EAP server has a long-term secret, without revealing the EAP server's identity. In that case, the EAP peer knows an authenticator was authorized by an EAP server, but it can't confirm which EAP server that was. If the EAP method doesn't provide a Server-Id, the peer can't identify the EAP server it generated keying material with. That can make it hard for the EAP peer to find where a key held by that EAP server lives. 🔥
As noted in [RFC5216] Section 5.2, EAP methods that authenticate with 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 decide whether a specific EAP server is authorized. Sometimes, like when the certificate extensions defined in [RFC4334] are in the server certificate, the peer can even verify some channel binding parameters from it. ✨🫶
Things can get messy when the EAP server identifies itself differently to the EAP peer than it does to the authenticator. For example, the Server-Id exported by an EAP method might not match the Fully Qualified Domain Name (FQDN) of the backend authentication server. When certificate-based authentication is used within RADIUS or Diameter, the subjectAltName in the backend authentication server certificate might not match the Server-Id or the backend authentication server FQDN. This usually isn't a problem in EAP, since the authenticator doesn't know the identities used between the EAP peer and the server. It can become a real issue for key caching, though, if the authenticator is expected to find the backend authentication server that matches a Server-Id the EAP peer provided. 🌸
If the backend authentication server FQDN is different from the subjectAltName in its certificate, the AAA client might not be able to tell whether it's talking to the right backend authentication server. And if the Server-Id and the backend authentication server FQDN differ, the combination of the key scope (Peer-Id(s), Server-Id(s)) and the EAP conversation identifier (Session-Id) might not be enough to figure out where the key lives. For example, an authenticator can identify backend authentication servers by IP address, as happens in RADIUS, or by Fully Qualified Domain Name, as in Diameter. If the Server-Id doesn't match the IP address or FQDN of any known backend authentication server, it may be impossible to find which backend authentication server holds the key. 🥺
3. Security Association Management 💜
[RFC3748] gives EAP key derivation, but it doesn't manage lower-layer security associations. Here's what's missing, bestie: 🧁
(a) Security Association negotiation. EAP doesn't 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 lower layers underneath. EAP also doesn't negotiate the traffic profiles to be protected with the negotiated ciphersuites. Sometimes the traffic being protected can have lower-layer source and destination addresses that differ from the lower-layer peer or authenticator addresses. 🙃
(b) Re-key. EAP doesn't support re-keying exported EAP keying material without EAP re-authentication. EAP methods can still support "fast reconnect," as defined in [RFC3748] Section 7.2.1. ✨
(c) Key delete/install semantics. EAP doesn't synchronize installing or deleting keying material between the EAP peer and the authenticator. 😬
(d) Lifetime negotiation. EAP doesn't support lifetime negotiation for exported EAP keying material, and existing EAP methods don't support key lifetime negotiation either. 💀
(e) Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can be reused if EAP keying material is cached. 🫣
These gaps are usually handled by a post-EAP handshake called the Secure Association Protocol. Literally the fix we need. 🎀🌈
3.1. Secure Association Protocol ✨
Okay so, neither EAP nor EAP methods can set up lower-layer security associations 💀 so it is RECOMMENDED that these facilities live inside the Secure Association Protocol, including:
(a) Entity Naming. A basic feature of a Secure Association Protocol is explicitly naming the parties in the exchange 🎀 Without explicit identification, the parties aren't 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), so that the peer and authenticator can show they've been authorized 🔑 Mutual proof of possession is not the same as mutual authentication, though. So the peer can't verify authenticator assertions (including the authenticator identity) just from this exchange. Authenticator identity verification is discussed in Section 2.3 🦋
(c) Secure capabilities negotiation. To protect against spoofing during the discovery phase, make sure the "best" ciphersuite gets picked, and stop anyone from forging negotiated security parameters, the Secure Association Protocol MUST support secure capabilities negotiation 🛡️ This covers 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, the EAP peer and authenticator can end up sharing more than one key of a given type 👯 So the Secure Association Protocol MUST explicitly name the keys used in the proof of possession exchange, so nobody gets confused when more than one set of keying material could be the basis for the exchange 🫶 Using 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 naming phase 2 security associations and their associated transient session keys, so the right 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 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 start a new session using keying material derived in a previous session 🌈 If the TSKs were derived solely from a portion of the exported EAP keying material, that would mean reusing session keys, which 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 it MUST support deriving fresh unicast and multicast TSKs, even when the transported keying material from the backend authentication server isn't fresh 💖 This is typically handled by exchanging nonces or counters, which then get mixed with the keying material to generate fresh unicast (phase 2a) and possibly multicast (phase 2b) session keys ✨ Since the Secure Association Protocol doesn't use exported EAP keying material directly to protect data, it protects that material against compromise 🛡️
(f) Key lifetime management. This includes explicit key lifetime negotiation or seamless re-key 🍓 EAP doesn't support re-keying EAP keying material without re-authentication, and existing EAP methods don't support key lifetime negotiation either 😤 So the Secure Association Protocol MAY handle the re-key and the 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 need key lifetime negotiation ⏳ For example, IKEv1 [RFC2409] and IKEv2 [RFC4306] are different in that IKEv1 negotiated SA lifetimes, while in IKEv2 each end of the SA enforces its own lifetime policy on the SA and re-keys the SA when necessary 👑
(g) Key state resynchronization. The peer or authenticator can reboot or reclaim resources, clearing some or all of the key cache 🙃 So key lifetime negotiation can't guarantee the key cache stays synchronized, and the peer may not be able to tell, before trying to use a key, whether it exists in the authenticator cache 🫠 It is therefore RECOMMENDED for the EAP lower layer to provide a mechanism for key state resynchronization, either via the SAP or using a lower layer indication (see [RFC3748] Section 3.4) 🌸 If the peer and authenticator don't jointly possess a key to protect the resynchronization exchange, secure resynchronization isn't possible, so alternatives (such as starting EAP re-authentication after a timer expires) are needed to keep resynchronization timely ⏰
(h) Key scope synchronization. To support key scope determination, the Secure Association Protocol SHOULD provide a mechanism that lets the peer determine the scope of the key cache on each authenticator, and lets the authenticator determine the scope of the key cache on a peer 🔍 This includes negotiating restrictions on key usage 🎀
(i) Traffic profile negotiation. The traffic protected by a lower-layer security association won't necessarily have the same lower-layer source or destination address as the EAP peer and authenticator 🌍 It's also possible for the peer and authenticator to negotiate multiple security associations, each with a different traffic profile. When that's the case, the profile of protected traffic SHOULD be explicitly negotiated 💅 For example, in IKEv2 an Initiator and Responder can use EAP for authentication, then negotiate a Tunnel Mode Security Association (SA), which permits passing 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) that originates from the Local Area Network (LAN) it's attached to 🙌 To make this work, 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 its own traffic profile and quality of service parameters ✨
(j) Direct operation. The phase 2 Secure Association Protocol is about establishing security associations between the EAP peer and authenticator, including deriving transient session keys, so only those two parties have "a need to know" the transient session keys 🔐 The Secure Association Protocol MUST operate directly between the peer and authenticator, and it MUST NOT be passed-through to the backend authentication server or include additional parties 🙅♀️
(k) Bi-directional operation. Some ciphersuites only need a single set of transient session keys to protect traffic in both directions, but other ciphersuites need a unique set in each direction 🔄 The phase 2 Secure Association Protocol SHOULD provide for deriving unicast and multicast keys in each direction, so you don't need two separate phase 2 exchanges to create a bi-directional phase 2 security association 💖 See [RFC3748] Section 2.4 for more discussion 📚
3.2. Key Scope 🌷
Unless the lower layer says otherwise explicitly, after phase 1b is complete, the transported keying material and parameters are bound to the EAP peer and authenticator 💜 They are not bound to a specific peer or authenticator port 🚪
While EAP keying material passed down to the lower layer isn't intrinsically bound to particular authenticator and peer ports, TSKs MAY be bound to particular authenticator and peer ports by the Secure Association Protocol 🔒 A lower layer MAY also permit TSKs to be used on multiple peer and/or authenticator ports, as long as TSK freshness is guaranteed (such as by keeping replay counter state within the authenticator) 🧚
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 to further restrict the scope of keying material 🍭 For example, in IEEE 802.11, the backend authentication server can give the authenticator 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 that restrict the key scope, it is RECOMMENDED that the authenticator securely communicate those restrictions to the peer 🫶 This can be done using the Secure Association Protocol, but it can also be done via the EAP method or the lower layer 🎀
3.3. Parent-Child Relationships ✨
okay so whenever an EAP re-authentication happens, the EAP method exports brand new EAP keying material 💅 In EAP lower layers where re-auth eventually leads to TSK replacement, the max lifetime of derived keying material (TSKs included) can be less than or equal to the lifetime of the MSK/EMSK, but it can't be greater. 🦋
Here's the drama 😭 If TSKs are derived from or wrapped by exported EAP keying material, then compromising that exported material means the TSKs are compromised too. So if EAP keying material is considered stale, not only SHOULD EAP re-authentication be initiated, but also replacement of child keys, including TSKs. 🔥
Now, where EAP keying material is only used for entity authentication and NOT for TSK derivation (like in IKEv2), compromising the exported EAP keying material doesn't compromise the TSKs. 🙈 Still, it could let an attacker impersonate an authenticator, so EAP re-authentication and TSK re-key are RECOMMENDED. ✨
With respect to IKEv2, Section 5.2 of [RFC4718], "IKEv2 Clarifications and Implementation Guidelines", says:
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 get used a lot (like TSKs protecting traffic) can expire sooner than the exported EAP keying material they depend on 🌸 so it's seriously useful to support re-key of child keys before EAP re-authentication. Deleting the MSK/EMSK doesn't automatically mean deleting TSKs or child keys, btw. 🧚
Also, failing to mutually prove possession of exported EAP keying material during the Secure Association Protocol exchange need not be grounds for both parties to delete their keying material. Rate-limiting Secure Association Protocol exchanges could be used to block a brute force attack. 💜
3.4. Local Key Lifetimes 🎀
The Transient EAP Keys (TEKs) are session keys that protect the EAP conversation. They're internal to the EAP method and never exported. 🫶 TEKs are typically created during an EAP conversation, used until the end of that conversation, and then discarded. Methods can re-key TEKs during a conversation though, which is a whole vibe. ✨
When you're using TEKs within an EAP conversation or across conversations, replay protection and key separation requirements have to be 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 way, TEK compromise can't lead 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 (like EAP-TLS [RFC5216]) derive and cache the TLS Master Secret, typically for pretty substantial periods of time. The lifetime of any other local EAP keying material calculated within the EAP method is defined by the method. 🌈
Heads up though: with fast reconnect, there's no guarantee the original long-term credentials are still in the peer's possession. Like, a smart-card holding the private key for EAP-TLS may have been removed 😬 So EAP servers SHOULD also verify that the long-term credentials are still valid, such as by checking that the certificate used in the original authentication hasn't expired yet. 🍓
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)So here's the thing 👑 If the EAP method doesn't support negotiating the lifetime of exported EAP keying material, AND the lower layer doesn't provide a key lifetime negotiation mechanism, the peer might have literally no way to learn how long the keying material lasts. That leaves the peer uncertain about how long the authenticator will keep keying material in its key cache. 🤷♀️ In that case, the lifetime can be managed as a system parameter on both the peer and the authenticator, and a default lifetime of 8 hours is RECOMMENDED. 🕰️
3.5.1. AAA Protocols 🦋
AAA protocols like 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]. When 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. ⏱️
But wait, there's more 👀 We also need a way to specify the maximum lifetime of cached keying material. When EAP pre-authentication is supported, cached keying material can be pre-established on the authenticator before the session starts, and it'll stick around until it expires. EAP lower layers that support caching of keying material MAY also persist that material after a session ends, so the peer can resume communication later using the cached keying material. In these situations, it can be really desirable for the backend authentication server to specify the maximum lifetime of cached keying material. 🌸
To make this happen, [IEEE-802.11] overloads the Session-Timeout Attribute, treating it as the maximum time after which transported keying material expires on the authenticator, regardless of whether that material is cached. 🫠
An IEEE 802.11 authenticator that receives transported keying material is expected to start a timer set to the Session-Timeout value. Once the timer expires, the transported keying material expires. Whether that leads to session termination or EAP re-authentication is controlled by the value of the Termination-Action Attribute. If EAP re-authentication happens, the transported keying material gets replaced, and new calculated keys are put in place with it. If session termination happens, transported and derived keying material is deleted. 🧹
Overloading the Session-Timeout Attribute is kinda problematic when you need to control the maximum session time and the key lifetime independently 🙃 For example, you might want to limit the lifetime of cached keying material to 5 minutes while letting a user, once authenticated, stay connected for up to an hour without re-authenticating. So in the future, additional attributes can be specified to control the lifetime of cached keys, and these attributes MAY modify the meaning of the Session-Timeout Attribute in specific circumstances. 🧩
Also, since the TSK lifetime is often determined by authenticator resources, and the backend authentication server has no insight into the TSK derivation process (thanks to the principle of ciphersuite independence), it isn't 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 negotiate the lifetime of keying material between the peer and the authenticator. This can happen either through the Secure Association Protocol or within the lower-layer transport. 🛸
When 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. 🔁 And if the TSK is taken directly from the MSK, there's 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.
Even so, EAP doesn't support negotiating lifetimes for exported EAP keying material like the MSK, EMSK, and IV. 😮💨
Sure, EAP could support lifetime negotiation, and it'd be possible to specify methods that do. But systems relying on key lifetime negotiation within EAP methods would only work with those methods. 🙄 Plus, there's no guarantee that a key lifetime negotiated inside the EAP method would match backend authentication server policy. For the sake of method independence and compatibility with backend authentication server implementations, managing the lifetime of keying material SHOULD NOT be provided within EAP methods. 🚫
3.6. Key Cache Synchronization 🧠
Key lifetime negotiation alone can't guarantee key cache synchronization 🫣 Even if a lower-layer exchange runs right after EAP to determine the lifetime of keying material, the authenticator can still purge all or part of its key cache early (for example, because of a reboot or a need to reclaim memory). 💾
The lower layer can use Discovery phase 0 to improve key cache synchronization. For example, if the authenticator manages its 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. That way, the peer can figure out whether keying material was expired early from the authenticator's key cache. 🕵️♀️✨
3.7. Key Strength 💪
As noted in Section 2.1, EAP lower layers determine TSKs in different ways. When exported EAP keying material is used in the derivation, encryption, or authentication of TSKs, EAP key generation could be the weakest link. 🔗
To make sure methods produce EAP keying material with an appropriate symmetric key strength, it is RECOMMENDED that EAP methods using public key cryptography choose a public key with cryptographic strength that provides the required level of attack resistance. This is usually handled by configuring the EAP methods, since there's no coordination between the lower layer and the EAP method when it comes 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]. 🌟
3.8. Key Wrap 🎀
Okay so the key wrap in [RFC2548] is based on an MD5-based stream cipher, and it has known problems 😭 (see [RFC3579] Section 4.3 for the tea). RADIUS uses the shared secret for multiple jobs, including per-packet authentication and attribute hiding, so a lot of information about the shared secret gets exposed with every single packet 🙈. That makes it open to dictionary attacks. MD5 is used for both the RADIUS Response Authenticator and the Message-Authenticator Attribute, and there are real concerns about how secure that hash is [MD5Collision].
As discussed in [RFC3579] Section 4.3, RADIUS has extensive security vulnerabilities, so making a new key wrap technique based on the RADIUS shared secret wouldn't substantially improve security 💅. That's why [RFC3579] Section 4.2 recommends running RADIUS over IPsec. Diameter EAP [RFC4072] takes the same approach. In Section 4.1.3 it defines the EAP-Master-Session-Key Attribute-Value Pair (AVP) in clear-text, which means it has to be protected by IPsec or TLS 🔐.
4. Handoff Vulnerabilities ✨
A handoff happens when an EAP peer moves to a new authenticator 🦋. Several mechanisms have been proposed to reduce handoff latency in networks that use EAP. These include:
- EAP pre-authentication: An EAP peer pre-establishes EAP keying material with an authenticator before it arrives. EAP pre-authentication only changes the timing of EAP authentication. It doesn't shorten or eliminate the EAP (phase 1a) or AAA (phase 1b) exchanges, and the Discovery (phase 0) and Secure Association Protocol (phase 2) exchanges happen as described in Section 1.3. So the big win is that EAP authentication can be pulled off the handoff critical path, which cuts latency ⚡. Use of EAP pre-authentication within IEEE 802.11 is described in [IEEE-802.11] and [8021XPreAuth].
- Proactive key distribution: Keying material and authorizations are sent from the backend authentication server to a candidate authenticator ahead of a handoff 🌸. EAP (phase 1a) isn't needed, but the Discovery (phase 0) and Secure Association Protocol (phase 2) exchanges 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 EAP keying material lets an EAP peer re-attach to an authenticator without needing EAP (phase 1a) or AAA (phase 1b) exchanges 🧚. Discovery (phase 0) and Secure Association Protocol (phase 2) exchanges are still needed, though. Use of key caching within IEEE 802.11 is described in [IEEE-802.11].
- Context transfer: Keying material and authorizations get transferred between a previous authenticator and a new one 🔁. This can happen in response to a handoff request from the EAP peer, or in advance, as in proactive key distribution. The result is that EAP (phase 1a) is eliminated, but not the Discovery (phase 0) or Secure Association Protocol exchanges (phase 2). If a secure channel can be set up between the new and previous authenticator without help from the backend authentication server, then the AAA exchange (phase 1b) can be eliminated. Otherwise it's still needed, though 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 🧠.
- Token distribution: The EAP peer is given a credential that lets it authenticate with one or more additional authenticators 🎟️. During those later authentications, EAP (phase 1a) is eliminated or shortened. The Discovery (phase 0) and Secure Association Protocol exchanges (phase 2) still happen, although the latter can be shortened. If the token includes authorizations and can be validated by an authenticator without help from the backend authentication server, then the AAA exchange (phase 1b) can be eliminated. Otherwise it's still needed, though it can be shortened. Token-based schemes, first 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. Buckle up, bestie 😤.
4.1. EAP Pre-Authentication
EAP pre-authentication differs from a normal EAP conversation mainly in the lower-layer encapsulation 📦. For example, in [IEEE-802.11], EAP pre-authentication frames use a distinct Ethertype but otherwise follow the encapsulation described in [IEEE-802.1X]. So an EAP pre-authentication conversation looks pretty similar to the model in Section 1.3, except there's a delay between phase 1 and phase 2 ⏳.
EAP pre-authentication depends on lower-layer mechanisms to discover candidate authenticators 🔍. If discovery can give information about candidate authenticators outside the immediate listening range, and the peer can figure out whether it already has valid EAP keying material with those candidates, the peer can skip unnecessary EAP pre-authentications. It can also set up EAP keying material well in advance, no matter how much the coverage areas overlap ✨. But if the peer can only discover candidates within listening range, and it can't tell whether it can reuse existing EAP keying material, then the peer might not finish EAP pre-authentication before it loses connectivity. Or it might pre-authenticate multiple times with the same authenticator, which increases load on the backend authentication server 📈.
A peer can complete EAP pre-authentication with an authenticator without ever attaching to it, so phase 2 might not happen at all 🙃. In that case, an Accounting-Request signifying the start of service won't be sent, or it'll only be sent after a big delay following the end of authentication.
As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA exchange from EAP pre-authentication differs little from an ordinary exchange described in "RADIUS Support for EAP" [RFC3579]. For example, IEEE 802.11 [IEEE-802.11] doesn't run an Association exchange before EAP pre-authentication. That means the authenticator doesn't know the SSID at authentication time, so an Access-Request can't include the SSID in the Called-Station-Id attribute, as described in [RFC3580] Section 3.20 🤷♀️.
The only thing that tells an EAP pre-authentication attempt apart is the absence of an SSID in the Called-Station-Id attribute. So if the authenticator doesn't always include the SSID for a normal EAP authentication attempt, the backend authentication server might not be able to tell whether a session is an EAP pre-authentication attempt. That can lead to authorization or accounting problems 🚨. If the number of simultaneous sessions is limited, the backend authentication server might refuse to authorize a valid EAP pre-authentication attempt, or it might let the peer run more simultaneous sessions than it's authorized for. And when EAP pre-authentication happens with an authenticator the peer never attaches to, the backend accounting server might not be able to tell whether a missing Accounting-Request was caused by packet loss or by a session that never started 😱.
To make pre-authentication requests easier to handle reliably, it is RECOMMENDED that AAA protocols explicitly identify EAP pre-authentication 💖. To cut down on unnecessary EAP pre-authentication exchanges, it is RECOMMENDED that authenticators unambiguously identify themselves, as described in Section 2.3 🫶.
4.2. Proactive Key Distribution ✨
okay so in proactive key distribution, the backend authentication server sends keying material and authorizations to an authenticator before the peer shows up 🦋. Which authenticators get the goods? The ones picked from past patterns of peer movement between authenticators, aka the "neighbor graph" 🗺️. To keep handoff latency low, these schemes typically only prove possession of the transported keying material between the EAP peer and the authenticator. During a handoff, the backend authentication server doesn't get proof that the peer successfully authenticated to an authenticator. Instead, the authenticator just generates a stream of accounting messages with no matching authentication exchanges 💀. As described in [MishraPro], the neighbor graph can be known through static configuration or by analyzing authentication exchanges. To keep the neighbor graph from getting corrupted, 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 match neighbor graph entries (for example, handoffs between neighbors) 🔍.
Next, the drama 🎭. To stop one compromised authenticator from taking down the others, cryptographic separation needs to be maintained between the keying material sent to each authenticator. BUT even with that separation, an attacker who compromises an authenticator can still mess with the other authenticators 😤. As noted in [RFC3579] Section 4.3.7, without spoofing detection inside the AAA infrastructure, EAP authenticators can impersonate each other. So if an attacker forges NAS identification attributes in authentication messages, they could corrupt the neighbor graph and trick the backend authentication server into sending keying material to arbitrary authenticators 🙈. Is this a full break? Nope, the EAP keying material still can't be recovered without breaking fundamental cryptographic assumptions. But it could enable fraudulent accounting messages later, or let the attacker disrupt service by piling load onto the backend authentication server or thrashing the authenticator key cache 🌪️.
Proactive key distribution hands out derived keying material to candidate authenticators, so the whole scheme only works if the backend authentication server can predict where the EAP peer is going 🔮. It relies on the server knowing the neighbor graph, which makes it most useful for intra-domain handoffs. Inter-domain handoffs are trickier, since there can be tons of authenticators and peers often connect to ones that haven't been encountered before. That makes it really hard for the backend authentication server to build a complete neighbor graph 😭.
Also, since proactive key distribution typically needs server-initiated messages like the ones in [RFC5176] and [HANDOFF], the security issues in [RFC5176] Section 6 apply. That includes the authorization problems (Section 6.1) and the replay detection problems (Section 6.3) 🔐.
4.3. AAA Bypass 🚫
Fast handoff techniques that skip the AAA exchange (phase 1b) are a totally different vibe from normal network access, like dial-up, wired LAN, and so on. Those usually include user authentication AND authorization for the service being offered. When the AAA exchange (phase 1b) gets left out, the backend authentication server doesn't provide authorizations or keying material, so they have to come from somewhere else 🧚. This section breaks down some of the implications 💅.
4.3.1. Key Transport
When the backend authentication server doesn't supply the transported keying material, it has to come from another party that's authorized to access it. As noted in Section 1.5, only the EAP peer, authenticator, and server are authorized to possess transported keying material. And since EAP peers don't trust each other, if the backend authentication server doesn't hand transported keying material to a new authenticator, the only option left is a previous authenticator 🤝.
Here's the tea ☕. As noted in Section 1.5, the whole point of the EAP conversation is to derive session keys known only to the peer and the authenticator. If keying material gets replicated between a previous authenticator and a new authenticator, then the previous authenticator can possess session keys used between the peer and the new authenticator. And the new authenticator can possess session keys used between the peer and the previous authenticator. Yikes 😬.
BUT, if a one-way function is used to derive the keying material sent to the new authenticator, then the new authenticator can't possess previous session keys without breaking a fundamental cryptographic assumption 🔒✨.
4.3.2. Authorization
As part of the authentication process, the backend authentication server figures out the user's authorization profile and sends the authorizations to the authenticator along with the transported keying material 📨. Usually the profile is based on the user identity, but a certificate presented by the user can also carry authorization information 🎀.
The backend authentication server is responsible for making the user authorization decision, which means answering these questions:
- (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?
The authorization decision is simple in principle, but the distributed decision-making can get messy 🌀. When brokers or proxies are involved, every AAA entity in the chain from the authenticator to the home backend authentication server gets a say. For example, a broker can deny access even if the home backend authentication server would have allowed it, or a proxy can add authorizations (like bandwidth limits) 🙃.
Decisions can be based on static policy definitions and profiles, plus dynamic state like time of day or concurrent session limits ⏰. Besides the Accept/Reject decisions made by AAA entities, service parameters or constraints can also be communicated to the authenticator 🍓.
Here's the catch 🙈. The criteria for Accept/Reject decisions, or the reasons for picking particular authorizations, are typically NOT passed to the authenticator. Only the final result gets sent. So the authenticator has no way to know what the decision was based on. 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? No clue, bestie 🤷♀️💜.
4.3.3. Correctness 🎀
okay so when the AAA exchange (phase 1b) gets bypassed, three things can go sideways and it's giving chaos 😭
- 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.
- 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 do conditional evaluation, so the authorizations in an Access-Accept message depend on the authenticator or on dynamic state like the time of day. If the AAA exchange is bypassed, unauthorized access could happen unless the restrictions are explicitly encoded within the authorizations provided by the backend authentication server.
A handoff mechanism that provides proper authorization is called "correct" 🦋 One condition for correctness is this:
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 well-designed handoff scheme only succeeds if it's "correct" in this way. If a successful handoff would set up "incorrect" authorizations, failing is the better outcome 🙅♀️ Where the supported services differ between authenticators, a handoff that skips the backend authentication server will probably fail. Section 1.1 of [RFC2865] says:
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 applies to attributes that are known but not implemented. For unknown attributes, Section 5 of [RFC2865] says:
A RADIUS server MAY ignore Attributes with an unknown Type. A
RADIUS client MAY ignore Attributes with an unknown Type.So, to handle a correct handoff: if a new authenticator gets RADIUS authorizations for a known but unavailable service, it MUST process them the same way it would handle a RADIUS Access-Accept requesting an unavailable service, and this MUST cause the handoff to fail ❌ However, if a new authenticator gets authorizations that include unknown attributes, those 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]. It can seem backwards, but failure really is the "correct" result when a known but unsupported service is requested 🤯
Presumably, a correctly configured backend authentication server wouldn't ask an authenticator to provide a service it doesn't implement. That means if the new authenticator completed a AAA conversation, it would probably get different service instructions. Failing the handoff is the desired result, because it sends the new authenticator back to the backend server to get the right service definition 🧚
Handoff mechanisms that skip the backend authentication server are most likely to work in a homogeneous deployment inside a single administrative domain. In a heterogeneous deployment, the backend authentication server can return different authorizations depending on which authenticator is asking, so the requested service matches what that authenticator can actually do. If the backend authentication server would send the new authenticator different authorizations than it sent the previous one, then transferring authorizations between the two will result in incorrect authorization 💀
Virtual LAN (VLAN) support is defined in [IEEE-802.1Q], and RADIUS support for dynamic VLANs is described in [RFC3580] and [RFC4675]. If some authenticators support dynamic VLANs and others don't, the backend authentication server could look at attributes in the Access-Request (like NAS-Port-Type, NAS-IP-Address, NAS-IPv6-Address, and NAS-Identifier) to decide when VLAN attributes get returned, and which ones. But if the backend authenticator is bypassed, a handoff between authenticators with different VLAN capabilities could let a user into an unauthorized VLAN. For example, a user with access to a guest VLAN could end up with unrestricted access to the network 🙈
Same vibe with confidentiality: it's preferable for a handoff to fail when one authenticator provides confidentiality and the other doesn't. If it succeeded, the user would be moved from a secure channel to an insecure one without the backend authentication server's permission 🔓
5. Security Considerations 🔐
Okay, this part is serious, bestie, so let's get into it 🥹 The EAP threat model is described in [RFC3748] Section 7.1. The security properties of EAP methods (called "security claims") are described in [RFC3748] Section 7.2.1. EAP method requirements for applications like Wireless LAN authentication are described in [RFC4017]. The RADIUS threat model is described in [RFC3579] Section 4.1, and responses to those threats are described in [RFC3579], Sections 4.2 and 4.3.
But on top of threats against EAP and AAA, there are other system-level threats too 😱 When building the threat model, it's 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.
- (f) An attacker can cause an EAP peer, authenticator, or server to reuse a stale key. Use of stale keys can also happen 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 they don't 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.
To address these threats, [RFC4962] Section 3 describes required and recommended security properties. The sections that follow analyze how well EAP methods, AAA protocols, and Secure Association Protocols comply with those guidelines ✨
5.1. Peer and Authenticator Compromise
Okay bestie, let's talk about the worst-case scenario 😭. If an authenticator gets compromised or stolen, an attacker can slide into the network through it, or grab the credentials the authenticator/AAA client uses to talk to one or more backend authentication servers. Same energy on the peer side: if a peer gets compromised or stolen, the attacker can get the credentials needed to talk to one or more authenticators 💀.
So there's a mandatory requirement from [RFC4962] Section 3, and it's giving Prevent the Domino effect 🎀:
Compromising one peer MUST NOT compromise keying material held by any other peer in the system, including session keys and long-term keys. Same goes for authenticators: compromising one authenticator MUST NOT compromise keying material held by any other authenticator in the system. In a key hierarchy, that means breaking one node must not reveal what's needed to break into other branches. Obviously if the root gets compromised, all the keys are gone 💀, but a compromise in one branch MUST NOT result in the compromise of other branches. There are a bunch of implications here, but two are worth highlighting. First, the scope of the keying material must be defined and understood by every party that talks to a party holding that keying material. Second, a party holding keying material in a key hierarchy must not share it with parties associated with other branches.
Group keys are the obvious exception 🫶. Since every group member has a copy of the same key, compromising any one member will expose the group key.
Some of the implications look like this:
Key Sharing: To figure out whether keying material has been shared, the identity of the EAP authenticator (NAS-Identifier) has to be defined and understood by everyone who communicates with it. EAP lower-layer specs like [IEEE-802.11], [IEEE-802.16e], [IEEE-802.1X], IKEv2 [RFC4306], and PPP [RFC1661] do not involve key sharing ✨.
AAA Credential Sharing: AAA credentials (like RADIUS shared secrets, IPsec pre-shared keys, or certificates) MUST NOT be shared between AAA clients 🚫. If one AAA client got compromised, an attacker could impersonate the other AAA clients to the backend authentication server, or even impersonate a backend authentication server to the other AAA clients.
Compromise of Long-Term Credentials: An attacker who obtains keying material (such as TSKs, TEKs, or the MSK) MUST NOT be able to obtain long-term user credentials like pre-shared keys, passwords, or private keys without breaking a fundamental cryptographic assumption 🔐. The mandatory requirements of [RFC4017] Section 2.2 include generating EAP keying material, the 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.
5.2. Cryptographic Negotiation
Mandatory requirements from [RFC4962] Section 3, and this one is so important 💜:
Cryptographic algorithm independent: The AAA key management protocol MUST be cryptographic algorithm independent. However, an EAP method MAY depend on a specific cryptographic algorithm. Being able to negotiate a particular algorithm gives you resilience if that algorithm gets compromised. Algorithm independence is also REQUIRED with a Secure Association Protocol if one is defined. This is usually done by including an algorithm identifier and parameters in the protocol, and by specifying the algorithm requirements in the protocol specification. Negotiating key derivation functions (KDFs) is highly desirable but not required 🌸. For interoperability, at least one suite of mandatory-to-implement algorithms MUST be selected. Also, without protection by IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865] does not meet this requirement, since its integrity protection algorithm cannot be negotiated 🙈.
This doesn't mean a protocol has to support both public-key and symmetric-key algorithms. It means the protocol has to be structured so that multiple public-key algorithms can be used whenever a public-key algorithm is employed. Likewise, it means the protocol has to be structured so 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 that satisfy the [RFC4017] Section 2.2 mandatory requirements, and AAA protocols that use transmission-layer security, are capable of addressing downgrade attacks 🦋. [RFC3748] Section 7.2.1 describes the "protected ciphersuite negotiation" security claim, which refers to an EAP method's ability 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 inherit this capability if they're properly designed. However, RFC 4962 [RFC4962] doesn't require KDF negotiation, and EAP methods based on neither TLS nor IKEv2 typically don't support it 🥲.
When AAA protocols use TLS [RFC5246] or IPsec [RFC4301] for transmission-layer security, they can use the cryptographic algorithm negotiation support provided by IKEv2 [RFC4306] or TLS [RFC5246]. RADIUS [RFC3579] by itself doesn't support cryptographic algorithm negotiation and relies on MD5 for integrity protection, authentication, and confidentiality. Given the known weaknesses in MD5 [MD5Collision], that's not ideal 💀, and it can be addressed by using RADIUS over IPsec, as described in [RFC3579] Section 4.2.
To protect against downgrade attacks within lower-layer protocols, algorithm independence is REQUIRED with lower layers that use EAP for key derivation. For interoperability, at least one suite of mandatory-to-implement algorithms MUST be selected. Lower-layer protocols that support 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 😬. [IEEE-802.16e] and [IEEE-802.11] support ciphersuite negotiation for protecting data, but they don't support negotiating 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, and these are the main character rules 👑:
Authenticate all parties: Each party in the AAA key management protocol MUST be authenticated to the other parties it communicates with. 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 it MUST identify themselves using identities that are meaningful in the lower-layer protocol environment that will use 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, which makes authorization decisions difficult without a clear key scope. If the lower-layer identifier of the 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 like RADIUS [RFC2865] and Diameter [RFC3588] have a way to identify AAA clients. Since the EAP authenticator and AAA client are always co-resident, that mechanism also works for identifying EAP authenticators 🧚.
When multiple base stations and a "controller" (like a WLAN switch) make up a single EAP authenticator, the "base station identity" doesn't matter, because the EAP method conversation happens between the EAP peer and the EAP server. Also, many base stations can share the same authenticator identity. The authenticator identity does matter 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, the 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 gives you protection against spoofing attacks 🎀. Diameter [RFC3588] supports per-packet authentication and integrity protection through IPsec or TLS. RADIUS/EAP [RFC3579] provides per-packet authentication and integrity protection through the Message-Authenticator Attribute.
[RFC3748] Section 7.2.1 describes the "integrity protection" security claim, and [RFC4017] Section 2.2 requires EAP methods that support this claim.
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 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 that takes advantage of this omission is described in [Analysis] 😭.
5.3.2. Impersonation 🎭
Okay bestie, this one is a bit of a drama queen 😭. Both RADIUS [RFC2865] and Diameter [RFC3588] implementations could be vulnerable to a rogue authenticator pretending to be another authenticator 💀. Both protocols do support mutual authentication between the AAA client/authenticator and the backend authentication server, but the security mechanisms are different, so it's not one-size-fits-all 🙈.
In RADIUS, the shared secret used for authentication is picked based on the source address of the RADIUS packet 🔐. The catch is that when a proxy forwards RADIUS Access-Requests, the NAS-IP-Address, NAS-Identifier, or NAS-IPv6-Address attributes that the RADIUS server receives won't match the source address anymore 😬. As noted in [RFC3579] Section 4.3.7, if the first-hop proxy doesn't check the NAS identification attributes against the source address in the Access-Request packet, a rogue authenticator could forge NAS-IP-Address [RFC2865], NAS-IPv6-Address [RFC3162], or NAS-Identifier [RFC2865] attributes and impersonate another authenticator 🦹♀️. Attributes like Called-Station-Id [RFC2865] and Calling-Station-Id [RFC2865] can be faked too 🎭. Honestly, the result can be that messages (plus the transported keying material 🔑) get sent to the wrong authenticator, and that is a major mess 😭.
Now for Diameter. [RFC3588] requires use of the Route-Record AVP, but this one uses Fully Qualified Domain Names (FQDNs) 🌐. So for impersonation detection to work, you need DNS A, AAAA, and PTR Resource Records (RRs) set up properly 📋. That means Diameter is just as vulnerable to this attack as RADIUS, if not more 💅. [RFC3579] Section 4.3.7 recommends mechanisms for impersonation detection ✨. To stop proxies from getting into keying material when they have no "need to know" 🙅♀️, the backend authentication server needs to be able to talk to the authenticator directly, for example via the redirect functionality supported in [RFC3588] 🦋.
5.3.3. Channel Binding 🔗
Here's the tea 🍵: a compromised or poorly implemented EAP authenticator could send incorrect information to the EAP peer and/or server 😱. That lets an authenticator impersonate another authenticator, or pass along wrong info through out-of-band mechanisms like AAA or the lower layer 🙃.
When EAP is used in pass-through mode, the EAP peer doesn't verify the identity of the pass-through authenticator inside the EAP conversation 👀. Inside the Secure Association Protocol, the EAP peer and authenticator just prove they both have the transported keying material; they don't mutually authenticate 🫠. That creates a potential security vulnerability, which is described in [RFC3748] Section 7.15 💥.
As described in [RFC3579] Section 4.3.7, a first-hop AAA proxy can catch a AAA client that's trying to impersonate another authenticator 🕵️♀️. The plot twist is that a pass-through authenticator acting as a AAA client can give the backend authentication server correct information while sending misleading info to the EAP peer over the lower layer 😈.
For example, a compromised authenticator could use another authenticator's Called-Station-Id or NAS-Identifier when talking to the EAP peer over the lower layer 🤥. Also, a pass-through authenticator acting as a AAA client can send an incorrect peer Calling-Station-Id [RFC2865] [RFC3580] to the backend authentication server through the AAA protocol 🚩.
As noted in [RFC3748] Section 7.15, this vulnerability can be fixed by EAP methods that support a protected exchange of channel properties like endpoint identifiers 🛡️. That includes (but isn't limited to) Called-Station-Id [RFC2865] [RFC3580], Calling-Station-Id [RFC2865] [RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162] 💜.
With a protected exchange like that, you can match the channel properties the authenticator gave you via out-of-band mechanisms against the ones exchanged inside the EAP method 🧩. Usually the EAP method pulls channel binding parameters from the lower layer on the peer side, then sends them securely to the EAP server, which exports them to the lower layer or AAA layer ✨. But the info can also go from EAP server to peer, or go both ways 🔁. Wherever the verification happens (peer or server), the lower layer or AAA layer passes the result up to the EAP method as TRUE or FALSE 🎀. Either side can do the verifying, but usually only the server actually has what it takes to tell whether the values are correct, not just whether they match each other 🧠. For more on this, check [EAP-SERVICE] 📚.
You can also do channel binding without sending any data over EAP, as described in [EAP-CHANNEL] 🌸. In this approach, the EAP method puts channel binding parameters into the calculation of the exported EAP keying material, so the peer and authenticator just can't finish the Secure Association Protocol if the channel binding parameters don't match 🔒. The catch? This only works where the methods generating EAP keying material are used with lower layers that use EAP keying material 😩. For example, this mechanism wouldn't let you verify channel binding on wired IEEE 802 networks using [IEEE-802.1X] 🙅♀️.
5.3.4. Mutual Authentication 🤝
Okay so [RFC3748] Section 7.2.1 describes the "mutual authentication" and "dictionary attack resistance" claims, and [RFC4017] requires EAP methods that satisfy these claims 🙌. So EAP methods that comply with [RFC4017] give you 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 hit by man-in-the-middle attacks 😵. When one of these attacks works, the attacker is basically the middle person between a victim and a legitimate authenticator 🕴️. That lets the attacker authenticate successfully to the authenticator, and also get access to the network 🚨.
To stop this, [EAP-BINDING] recommends deriving a compound key that lets the EAP peer and server prove they took part in the entire EAP exchange 🪄. The compound key MUST NOT be known to an attacker pretending to be an authenticator, but it still has to come from EAP keying material. So it MAY be desirable to derive the compound key from a portion of the EMSK 🧁. If you do that, then for proper key hygiene 🧼, it is RECOMMENDED that the compound key used for man-in-the-middle protection be cryptographically separate from the other keys derived from the EMSK 💅.
Diameter [RFC3588] provides per-packet authentication and integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also provides per-packet authentication and integrity protection 🛡️. When the authenticator/AAA client and backend authentication server talk directly and credible key wrap is used (see Section 3.8), that makes sure the AAA Key Transport (phase 1b) hits its security goals 🎯. Those goals are: mutually authenticating the AAA client/authenticator and backend authentication server, and giving the transported keying material to the EAP authenticator and to nobody else 🫶.
[RFC2607] Section 7 describes the security issues that happen when the authenticator/AAA client and backend authentication server don't talk directly 🙈. If there's an AAA intermediary (like a RADIUS proxy or a Diameter agent) and data object security isn't used, an attacker controlling the intermediary can recover the transported keying material 😱. As discussed in Section 2.1, unless the TSKs are derived independently from EAP keying material (as in IKEv2), having the transported keying material lets someone decrypt data traffic between the peer and the authenticator it was transported to 🔓. It also lets the AAA intermediary impersonate the authenticator or the peer 🎭. And since the peer doesn't authenticate to a AAA intermediary, it can't figure out whether that intermediary is authentic or authorized to get the keying material 🫠.
Here's the silver lining ✨: as long as the transported keying material, or keys derived from it, are only used by a single authenticator, stealing that material doesn't let an attacker impersonate the peer to a different authenticator 🦋. Being vulnerable to a compromised AAA intermediary can be reduced by using redirect functionality, as described in [RFC3588] and [RFC4072] 🌈.
The Secure Association Protocol doesn't give you mutual authentication between the EAP peer and authenticator, only mutual proof of possession of the transported keying material 🥲. For the peer to verify who the authenticator is, mutual proof of possession has to be combined with impersonation prevention and channel binding 🧩. Impersonation prevention (described in Section 5.3.2) lets the backend authentication server confirm the transported keying material went to the right authenticator 📬. When it's used alongside impersonation prevention, channel binding (described in Section 5.3.3) lets the EAP peer verify that the EAP server authorized the authenticator to hold the transported keying material 👑. And finishing the Secure Association Protocol exchange shows that the EAP peer and the authenticator both have the transported keying material 🎉.
5.4. Key Binding ✨
Okay bestie, key binding 🔐💖 is basically making sure every key knows exactly whose vibe it is and where it belongs. Here's the 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:
- The manner in which the keying material is expected to be used.
- The other parties that are expected to have access to the keying material.
- 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. Main character energy, but make it secure 💅
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. So yes, one identity can wear multiple outfits 👗✨
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). Not every method is giving authenticated server vibes, so check Appendix A 🙈
Within the AAA protocol, transported keying material is destined for the EAP authenticator identified by the NAS-Identifier Attribute within the request. It 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. Lots of rules, all very iconic 👑
5.5. Authorization 🦋
Requirement: The Secure Association Protocol (phase 2) conversation may utilize different identifiers from the EAP conversation (phase 1a), so binding between the EAP and Secure Association Protocol identities is REQUIRED. Basically the two chats need to know they're talking about the same person 🫶
Here's the 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 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. No sneaky imposters allowed 😤
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. Everyone should be on the same page, bestie 📖
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 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. Knowing the key ≠ being allowed to have the key 💀
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. Catch the liar by checking every single link 🕵️♀️
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:
- Key lifetimes, where the keying material can only be used for a certain period of time;
- SSID restrictions, where the keying material can only be used with a specific IEEE 802.11 SSID;
- Called-Station-ID restrictions, where the keying material can only be used with a single IEEE 802.11 BSSID; and
- 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. It also lets the peer 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. Receipts, please 🧾
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. Let the peer in on the tea too 🫖
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. Consistency is everything 💜
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 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. IKEv2 is giving "one name, everywhere" and 802.11 needs the MAC address to keep up 🧚
5.6. Replay Protection 🌈
Here's the 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. Nobody gets to rerun an old conversation and pretend it's new 🙅♀️
[RFC3748] Section 7.2.1 describes the "replay protection" security claim, and [RFC4017] Section 2.2 requires use of EAP methods supporting this claim. So the methods themselves need to bring the protection 💅
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. Yikes, these ones are a little unprotected 😬
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.
5.7. Key Freshness 🌸
okay so this one is all about making sure every session key is brand new and never gets reused 🔐 A session key SHOULD be considered compromised if it's still being used after its authorized lifetime 💀 This is a mandatory requirement from [RFC4962] Section 3, and it goes like this:
Strong, fresh session keys ✨
While staying algorithm-independent, session keys MUST be strong and fresh. Every session deserves its own independent session key 🦋 Fresh keys are still needed even when you're using a long replay counter (the kind that "will never wrap"), because losing state must not cause the same counter value to be used more than once with the same session key 😭
Some EAP methods can derive keys of varying strength, and those methods MUST allow generating keys that meet a minimum equivalent key strength 💪 BCP 86 [RFC3766] has advice on appropriate key sizes, and NIST also offers advice on this in [SP800-57].
A fresh cryptographic key is one generated specifically for its intended use 🎀 A secure association protocol is used to establish session keys. The AAA protocol and EAP method MUST ensure that the keying material fed into 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. Caching is when the material sticks around after the authentication exchange is done. On the AAA/EAP server, caching can happen when state is kept on the server. On the NAS or client, it can happen when keying material isn't destroyed right after session keys are derived.
Session keys MUST NOT be dependent on one another 🙅 You can derive several session keys from a higher-level shared secret, as long as a one-time value (usually a nonce) makes sure each one is fresh. The mechanism that generates session keys MUST ensure that disclosing one session key doesn't help an attacker find any other session keys 🔒
EAP, AAA, and the lower layer each share responsibility for fresh, strong session keys 👑 EAP methods need to make sure the freshness and strength of the EAP keying material fed into session key derivation. [RFC3748] Section 7.10 says:
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 lets the EAP peer and server make sure 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 that support these claims, plus methods able to provide equivalent key strength of 128 bits or greater. See Section 3.7 for more on key strength 💖
The AAA protocol needs to make sure transported keying material is fresh and isn't used outside its recommended lifetime ⏳ Replay protection is necessary for key freshness, but an attacker can deliver a stale (and therefore potentially compromised) key inside a replay-protected message, so replay protection is not sufficient 😱 As discussed in Section 3.5, the Session-Timeout Attribute lets the backend authentication server limit how exposed transported keying material can be.
The EAP Session-Id, described in Section 1.4, lets the EAP peer, authenticator, and server tell EAP conversations apart 🧚 However, unless the authenticator keeps track of EAP Session-Ids, it can't 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 if either the peer or authenticator lacks 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 🙈
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 they don't need 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 used to establish session keys MUST specify the scope for those 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 while mutually authenticating each other with the selected EAP method. During the Secure Association Protocol exchange, the EAP peer uses keying material to show the authenticator that it's the same party that authenticated to the EAP server and was authorized by it. The EAP authenticator uses the transported keying material to prove to the peer that the EAP conversation went through it (a man-in-the-middle could demonstrate that too), and that it was uniquely authorized by the EAP server to give the peer network access 👑 Unique authorization can only be shown if the EAP authenticator doesn't share the transported keying material with anyone other than the EAP peer and server.
TSKs are permitted to be accessed only by the EAP peer and authenticator (see Section 1.5), and TSK derivation is discussed in Section 2.1 🧩 Since showing authorization inside the Secure Association Protocol exchange depends on possessing 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 need a robust key naming scheme, especially where key caching is supported. The key name is how you refer to a key in a protocol so that every party knows which key is being referenced. Objects that can't be named can't be managed 🙃 All keys MUST be uniquely named, and the key name MUST NOT directly or indirectly disclose the keying material. If the key name isn't based on the keying material, you can be sure it can't be used to help 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 they don't directly or indirectly expose it 💜
Existing AAA server implementations don't distribute key names along with the transported keying material 😬 However, Diameter EAP [RFC4072] Section 4.1.4 defines the EAP-Key-Name AVP for transporting the EAP Session-Id. Since the EAP-Key-Name AVP is defined within the RADIUS attribute space, it can be used with either RADIUS or Diameter 🎀
Since existing backend authentication server implementations don't give the authenticator the name of the transported keying material, existing Secure Association Protocols don't use EAP key names 🙁 For example, [IEEE-802.11] supports PMK caching. To let the peer and authenticator figure out which cached PMK to use within the 4-way handshake, the PMK needs to be named, and [IEEE-802.11] uses a PMK naming scheme that's based on the key itself. Since IKEv2 [RFC4306] doesn't cache transported keying material, it doesn't need to refer to transported keying material at all ✨
5.10. Denial-of-Service Attacks 💥
Key caching can make you vulnerable 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. Not cute!
To address this, EAP methods that create 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 stops 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. It can do this by limiting each peer to persistent state for a few EAP conversations, distinguished by the EAP Session-Id 🌈
Whether creating new TSKs implies deleting previously derived TSKs depends on the EAP lower layer 🤔 Where there's no implied deletion, the authenticator can choose to limit the number of TSKs and associated state stored for each peer.
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.[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. 🧚[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. ✨[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. 🧚[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. 🔐[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. 🧚[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 ✨
Huge 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 all the useful feedback 🫶
Appendix A - Exported Parameters in Existing Methods 🧚
okay so this appendix is the part where we pin down Session-Id, Peer-Id, Server-Id and Key-Lifetime for EAP methods that were already published before this spec dropped 💅 Future EAP method specs MUST include a definition of the Session-Id, Peer-Id and Server-Id (those can be the null string, which is fine 😌). And in everything below, all the fields that make up the Session-Id are assumed to be in network byte order, so keep that in your back pocket 🔢
EAP-Identity
EAP-Identity is defined in [RFC3748]. It doesn't derive keys, so it doesn't define a Session-Id at all 🙈 Its Peer-Id and Server-Id are both the null string (zero length).
EAP-Notification
EAP-Notification is defined in [RFC3748]. It doesn't derive keys either, so no Session-Id here. The Peer-Id and Server-Id are the null string (zero length) 💤
EAP-MD5-Challenge
EAP-MD5-Challenge is defined in [RFC3748]. Same deal, no keys, no Session-Id, and the Peer-Id and Server-Id are the null string (zero length) 🌸
EAP-GTC
EAP-GTC is defined in [RFC3748]. It doesn't derive keys, so there's no Session-Id. Peer-Id and Server-Id are both the null string (zero length) 🦋
EAP-OTP
EAP-OTP is defined in [RFC3748]. No keys derived, no Session-Id defined, and the Peer-Id and Server-Id are the null string (zero length) ✨
EAP-AKA
EAP-AKA is defined in [RFC4187] and this one actually has a Session-Id 👑 It's the EAP Type Code (0x17) stuck together with the RAND field from the AT_RAND attribute, followed by the AUTN field from the AT_AUTN attribute:
Session-Id = 0x17 || RAND || AUTNThe Peer-Id is the Identity field from the AT_IDENTITY attribute, but you only take the first Actual Identity Length octets from the start. The contents get used exactly as they were transmitted, no matter whether the identity was permanent, a pseudonym, or a fast EAP re-authentication identity 🫶 The Server-Id is the null string (zero length).
EAP-SIM
EAP-SIM is defined in [RFC4186] and it's giving the same vibe as EAP-AKA 🔥 The Session-Id is the EAP Type Code (0x12) with the RAND field from the AT_RAND attribute, then the NONCE_MT field from the AT_NONCE_MT attribute:
Session-Id = 0x12 || RAND || NONCE_MTPeer-Id is the Identity field from AT_IDENTITY, again only the Actual Identity Length octets from the beginning. Same rule as before: the contents are used as transmitted, whether it's a permanent, pseudonym, or fast re-auth identity 💖 Server-Id is the null string (zero length).
EAP-PSK
EAP-PSK is defined in [RFC4764] 🧁 Its Session-Id is the EAP Type Code (0x2F) mashed together with the peer nonce (RAND_P) and the server nonce (RAND_S):
Session-Id = 0x2F || RAND_P || RAND_SFor this one, the Peer-Id is the contents of the ID_P field and the Server-Id is the contents of the ID_S field 🌈
EAP-SAKE
EAP-SAKE is defined in [RFC4763] and it has a little twist 👀 The Session-Id is the EAP Type Code (0x30) with the RAND_S field from the AT_RAND_S attribute, followed by the RAND_P field from the AT_RAND_P attribute:
Session-Id = 0x30 || RAND_S || RAND_PHeads up, bestie: the EAP-SAKE Session-Id is NOT the same thing as the "Session ID" parameter the Server picks and sends in its first message (and then repeats in later messages) 🙃 Don't mix them up. The Peer-Id lives in the value field of the AT_PEERID attribute, and the Server-Id, if there is one, lives in the value field of the AT_SERVERID attribute 💅
EAP-TLS
For EAP-TLS, the Peer-Id, Server-Id and Session-Id are all defined in [RFC5216] 🎀 No need to reinvent the wheel here, just go read that one.
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.comFull 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. It also doesn't claim to have made any independent effort to identify any such rights 🔍 Info on how rights work for RFC documents lives in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights can all be found in 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 required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌
📦 where this page comes from
- ietf: rfc5247 2008-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms