Extensible Authentication Protocol (EAP) Key Management Framework
updated by
- rfc-8940 — Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP)
updates
- rfc-3748 — Extensible Authentication Protocol (EAP)
Extracted elements (26)
Ciphersuite independence is maintained because lower-layer ciphersuites vary between media, so EAP methods export ciphersuite-independent keying material. This avoids requiring method updates when new ciphersuites are introduced and eliminates ciphersuite-specific code from EAP methods, reducing complexity and enabling use with any compliant lower layer.
Mode independence requires that the EAP method conversation between peer and server is identical regardless of whether the authenticator operates in pass-through mode. All key derivation and parameter export are unaffected by authenticator mode; the authenticator identity is treated as opaque channel binding data within EAP.
The Initialization Vector (IV) export is deprecated because in methods like EAP-TLS the IV is a known value, making it unsuitable alone for computing quantities that must remain secret. When an IV is generated it MUST be unpredictable, but generation is OPTIONAL for EAP methods.
PPP derives TSKs directly from the MSK without a Secure Association Protocol, which is NOT RECOMMENDED because if caching were enabled, TSK reuse would result; EAP keying material MUST be discarded when a PPP session terminates. IKEv2 uses the MSK only for authentication (not key derivation), so TSKs are cryptographically independent of EAP keying material and IPsec SA re-key does not require EAP re-authentication.
Algorithms for deriving TSKs MUST NOT depend on the EAP method, to maintain method independence. Algorithms for TEK derivation MAY be method-specific.
An EAP method supporting key derivation MUST export an MSK of at least 64 octets and an EMSK of at least 64 octets. The EMSK MUST be at least as long as the MSK in size.
EAP method specifications developed after RFC 5247 MUST define the Peer-Id, Server-Id, and Session-Id for that method. Methods supporting key derivation and mutual authentication SHOULD export a Session-Id and Peer-Id(s); Server-Id(s) MAY also be exported.
EAP methods that transport channel binding parameters MUST treat this data as opaque octets to avoid introducing media dependencies. Channel binding parameters are only interpreted by the lower layer, not by the EAP method.
Lower layers MUST NOT export EAP keys passed down by EAP methods; EAP keying material passed to a lower layer MUST NOT be used within another lower layer or transported to another entity. The EAP layer and peer/authenticator layers MUST NOT modify or cache keying material (including channel bindings) passing between the method layer and the lower or AAA layer in either direction.
MSK and EMSK MUST be named using the EAP Session-Id and a binary or textual indication of the specific key type. TSK naming is specified by the lower layer; TEK naming MAY be specified by the EAP method.
New lower-layer specifications MUST describe key caching behavior. Unless explicitly specified by the lower layer, the EAP peer, server, and authenticator MUST assume that peers and authenticators do not cache keying material.
Physical authenticators implementing virtual authenticators are REQUIRED to cache associated authorizations along with EAP keying material and apply them on each network access regardless of which virtual authenticator is accessed. It is RECOMMENDED that physical authenticators maintain separate key caches per virtual authenticator to prevent cross-authenticator key reuse attacks.
The AAA layer MUST delete transported keys once sent and MUST NOT retain keys it has previously sent. A AAA layer that has transported the MSK MUST delete it, and no keys MUST be derived from the MSK from that point forward by the AAA layer.
The EMSK MUST NOT be provided to any entity outside the EAP server or peer. It is not permitted to pass any quantity to an outside entity from which the EMSK could be computed without breaking a cryptographic assumption, such as inverting a one-way function.
The NAS-Identifier Attribute is RECOMMENDED for explicit identification of the EAP authenticator in both the AAA protocol exchange and the Secure Association Protocol conversation, rather than using endpoint addresses or ports, since a NAS can have multiple IP addresses and authenticators can have multiple ports.
The Secure Association Protocol MUST operate directly between the peer and authenticator and MUST NOT be passed through to the backend authentication server or include additional parties, since TSKs need be known only by the peer and authenticator.
The Secure Association Protocol MUST support: mutual proof of possession of EAP keying material (e.g., MSK); secure capabilities negotiation with integrity and replay protection of all negotiation messages; and explicit naming of keys used in the proof-of-possession exchange to prevent confusion when multiple key sets exist. Use of the key naming mechanism in Section 1.4.1 is RECOMMENDED.
Where lower layers support key caching, the Secure Association Protocol phase is REQUIRED and MUST support derivation of fresh unicast and multicast TSKs even when the transported keying material from the backend authentication server is not fresh. This is typically accomplished via a nonce or counter exchange that is mixed with the keying material.
After phase 1b, transported keying material is bound to the EAP peer and authenticator but not to a specific port. TSKs MAY be bound to particular ports by the SAP, or MAY be used on multiple ports if TSK freshness is guaranteed (e.g., via per-port replay counters). The backend authentication server and authenticator MAY apply additional attributes (e.g., Called-Station-Id, SSID filters) to further restrict key scope.
Child key lifetimes (TSKs derived from or wrapped by EAP keying material) cannot exceed the parent MSK/EMSK lifetime. Compromise of exported EAP keying material implies compromise of TSKs derived from it; when EAP keying material is considered stale, EAP re-authentication SHOULD be initiated and all child keys SHOULD be replaced.
EAP key derivation proceeds in four phases: Phase 0 (Discovery), Phase 1a (EAP authentication), Phase 1b (optional AAA key transport from backend server to authenticator), and Phase 2 (Secure Association Protocol for unicast and optional multicast security associations). Phases 0, 1b, and 2 are handled external to EAP.
Multiple Peer-Ids may be exported by a single EAP method (e.g., from multiple certificate identities or from inner and outer tunnel exchanges). Where a key-deriving EAP method does not provide a Peer-Id, the EAP server cannot authenticate the peer identity; where a method does not generate keys, the Peer-Id MUST be the null string.
Multiple Server-Ids may be exported by a single EAP method (e.g., from inner and outer tunnel exchanges). Because authenticators can fail over between EAP servers dynamically, the EAP peer may communicate with a different EAP server on reconnection, which can cause fast reconnect failures if the new server lacks access to the prior session's TLS Master Key.
The EAP key hierarchy derives from long-term credentials through TEKs (used internally by the method, not exported), MSK (≥64 octets, exported), EMSK (≥64 octets, exported, never shared), and optional IV (deprecated). Lower layers derive Transient Session Keys (TSKs) from the MSK. Peer-Id(s), Server-Id(s), Session-Id, and channel binding parameters are also exported by the method.
EAP security goals require that after phase 1a, EAP keying material is known only to the identified peer and EAP server; after phase 1b, keying material is transported to the intended authenticator without disclosure. The backend authentication server is trusted not to derive TSKs or act as a man-in-the-middle despite possessing the MSK, and the authenticator is trusted not to distribute keying material outside the authorized scope.
For non-expanded EAP type codes, Session-Id = Type-Code (1 octet) || Method-Id. For expanded type codes: Session-Id = 0xFE || Vendor-Id (3 octets, network byte order) || Vendor-Type (4 octets, network byte order) || Method-Id. The Method-Id is typically constructed from nonces or counters used in the EAP method exchange.