EAP Extensions for the EAP Re-authentication Protocol (ERP)
obsoletes
- rfc-5296 — EAP Extensions for EAP Re-authentication Protocol (ERP)
Extracted elements (28)
Co-location of the home EAP Re-authentication (ER) server and the EAP server is no longer required, relaxing a constraint from RFC 5296. The ER server is now defined as a logical entity that may not be physically part of a full EAP server, improving deployment flexibility.
ERP was designed to complete re-authentication in less than 2 round trips, preferably with a local server, to support low-latency handovers. Full EAP exchanges take several round trips; method-specific re-authentication requires at least 2 round trips with the original EAP server; and key sharing across authenticators risks compromise propagation, making a dedicated method-independent protocol necessary.
Lower-layer specifications (including IKEv2/RFC 5996) must be revised to carry EAP messages with code values higher than 4 and to support peer-initiated ERP. Some non-RFC-3748-compliant EAP implementations treat code values > 4 as errors rather than silently discarding them; lower layers SHOULD ensure both parties support ERP or fall back to full EAP authentication.
A given rMSK MUST NOT be shared by multiple authenticators. If a new rRK is derived, subsequent rMSKs MUST be derived from the new rRK. The rMSK lifetime MUST NOT be greater than the lifetime of the rRK.
For replay protection, the ER server MUST first verify the sequence number is equal to or greater than the expected sequence number before checking integrity. When the sequence number wraps back to zero, the peer MUST run full EAP authentication and the rIK MUST be changed.
HMAC-SHA256-128 is mandatory to implement and SHOULD be enabled in the default configuration. The defined cryptosuite values are: 0 (RESERVED), 1 (HMAC-SHA256-64), 2 (HMAC-SHA256-128), 3 (HMAC-SHA256-256).
If the authenticator receives an EAP-Initiate/Re-auth message after sending EAP-Request/Identity and supports ERP, it MUST proceed with the ERP exchange. If no response follows the required retransmissions of EAP-Initiate/Re-auth-Start, the authenticator MUST initiate EAP by sending EAP-Request/Identity.
The EAP-Finish/Re-auth Identifier MUST match that of the currently outstanding EAP-Initiate message; a mismatched Identifier MUST cause silent discard. If the authenticator receives a valid duplicate EAP-Initiate/Re-auth for which it already sent a finish, it MUST resend the stored EAP-Finish/Re-auth without reprocessing.
The home EAP server MUST NOT hand out a given DSRK to a local domain server more than once unless it can verify the receiving entity is the same one that received it originally. If authorization is verified, the server MAY hand out the DSRK again and SHOULD include the Authorization Indication TLV (Type=6) to assure the peer that delivery is secure.
The peer and server MUST use the same integrity algorithm with a given rIK for all ERP messages protected by that key. If the server's policy disallows the cryptosuite selected by the peer, the server SHALL reject the EAP-Initiate/Re-auth message and SHOULD send a list of acceptable cryptosuites in the EAP-Finish/Re-auth failure response.
The rIK MUST remain on the peer and the ER server and MUST NOT be transported to any other entity. The rIK MUST NOT be used to derive any keys other than as specified in this document, and MUST be expired when the EMSK expires.
The rRK MUST remain on the peer and the server that derived it and MUST NOT be transported to any other entity. The rRK MUST be removed from use when its parent key expires, and its lifetime MUST NOT exceed that of the parent key.
Upon receiving an EAP-Finish/Re-auth with Result flag set to '1', the peer MUST verify the sequence number and, if possible, the authentication tag. If the message contains a cryptosuite list TLV (Type=5), the peer SHOULD retry ERP using a cryptosuite from that list, deriving a new rIK (and rRK/DSRK if the PRF changes) before retrying.
Channel binding information is carried in TLV types 128–191 within ERP messages. Pre-defined attributes are: Called-Station-Id (128), Calling-Station-Id (129), NAS-Identifier (130), NAS-IP-Address (131), NAS-IPv6-Address (132). If the local ER server requires channel binding but the peer omitted it, the server SHALL send the CB attributes for peer verification.
rIK derivation: rIK = KDF(rRK, S) where S includes the label 'Re-authentication Integrity [email protected]', '\0', an 8-bit cryptosuite identifier, and length. The cryptosuite and length are included as KDF inputs to ensure cryptographic separation when multiple rIKs of different lengths are derived from the same rRK.
rMSK derivation: rMSK = KDF(rRK, S) where S includes the label 'Re-authentication Master Session [email protected]', '\0', SEQ (the 16-bit sequence number from the EAP-Initiate/Re-auth message encoded in network byte order), and length. Using SEQ as a KDF input produces a unique rMSK for each re-authentication.
rRK derivation: rRK = KDF(K, S) where K is the EMSK or DSRK, and S is the ASCII label 'EAP Re-authentication Root [email protected]' | '\0' | length. The KDF and algorithm agility follow RFC 5295. An rRK derived from DSRK is referred to as a DS-rRK.
The ER key hierarchy derives three key types from the EMSK or DSRK: the re-authentication Root Key (rRK) serves as the root; the re-authentication Integrity Key (rIK) is derived from the rRK for per-exchange message integrity; and per-authenticator re-authentication MSKs (rMSKs) are derived from the rRK using the sequence number, ensuring a fresh key per exchange.
The keyName-NAI TLV (Type=1) identifies the rIK protecting an ERP message. The username part contains the 64-bit EMSKname encoded as 16 hexadecimal octets; the realm identifies the ER server's domain. Exactly one keyName-NAI attribute SHALL be present in each EAP-Initiate/Re-auth and EAP-Finish/Re-auth packet.
Two new EAP code values are defined for ERP: EAP-Initiate (code 5) and EAP-Finish (code 6). Two Type values are defined under these codes: Re-auth-Start (Type=1) carried in EAP-Initiate, and Re-auth (Type=2) carried in both EAP-Initiate and EAP-Finish.
This document registers EAP codes 5 (EAP-Initiate) and 6 (EAP-Finish) in the EAP Code registry, and registers two USRK Key Labels ('EAP Re-authentication Root [email protected]' and 'Re-authentication Integrity [email protected]') in the USRK Key Labels name space per RFC 5295 policy. Channel binding TLV types 128–132 are assigned, with types 128–191 reserved for channel binding under IETF Review.
ERP does not provide forward secrecy. Compromise of a DSRK retroactively compromises all ERP keys derived from it. The AAA protocol carrying DSRKs and rMSKs is RECOMMENDED to be protected using IPsec or TLS, but hop-by-hop protection means compromise of any AAA proxy in the path can expose key material.
ERP prevents the domino effect by scoping each rMSK to a single authenticator: compromise of one authenticator does not compromise sessions or keys held by any other authenticator. However, if a DSRK is delivered to a local ER server via a compromised proxy, all domain-specific keys for that domain are at risk.
ERP provides mutual authentication via proof of possession of the rIK. Both EAP-Initiate/Re-auth and EAP-Finish/Re-auth messages are integrity-protected. When no valid rIK exists for the peer, a cryptosuite rejection EAP-Finish/Re-auth message is unauthenticated, meaning an attacker could tamper with the offered cryptosuite list without detection.
ERP bootstrapping has two modes: explicit (peer sets bootstrap flag B=1 in EAP-Initiate/Re-auth to obtain rRK/domain name from home ER server) and implicit (local ER server requests DSRK from home EAP server during the initial full EAP exchange). The authenticator/local ER server MUST verify current possession of root keys before deciding which path to take.
The EAP-Finish/Re-auth packet (Type=2, Code=6) mirrors the EAP-Initiate/Re-auth structure: Code, Identifier, Length, Type, a flags byte (R=Result: 0 success / 1 failure, B=Bootstrap, L=Lifetime present), 16-bit SEQ in network byte order, TV/TLV attributes, Cryptosuite, and Authentication Tag.
The EAP-Initiate/Re-auth packet (Type=2) contains: standard EAP header (Code=5, Identifier, Length), a flags byte with bits R (reserved, set 0), B (bootstrap), L (request lifetimes), a 16-bit unsigned SEQ in network byte order, one or more TV/TLV attributes, an 8-bit Cryptosuite field, and a variable-length Authentication Tag covering the entire packet excluding the tag itself.
The EAP-Initiate/Re-auth-Start packet (Type=1, Code=5) contains the standard EAP header, a Reserved byte (MUST be zero), and optional TV/TLV attributes. The Domain name TLV (Type=4, variable length up to NAI realm limits) SHOULD be present so the peer can learn the local domain without lower-layer support.