EAP Extensions for EAP Re-authentication Protocol (ERP)
obsoleted by
- rfc-6696 — EAP Extensions for the EAP Re-authentication Protocol (ERP)
Extracted elements (29)
ERP provides algorithm agility but not true negotiation: the peer picks a cryptosuite and the server accepts or rejects it with alternatives. A full negotiation cannot be achieved in a single round-trip protocol, so the design trades negotiation completeness for latency.
The rMSK is derived using the SEQ sequence number as an additional KDF input. This simultaneously provides replay protection for ERP and binds each rMSK to a specific exchange, ensuring that multiple simultaneous re-authentications produce distinct, non-reusable session keys.
The rRK is derived as a Usage-Specific Root Key (USRK) from the EMSK, or as a Domain-Specific USRK (DSUSRK) from a DSRK for local ER servers. This dual derivation path allows a single prior EAP exchange to bootstrap both home-domain and visited-domain re-authentication while keeping each domain's keys cryptographically isolated.
Lower-layer specifications require updates to support ERP: IEEE 802.1x must be revised to carry EAP messages with code values higher than 4, and RFC 4306 (IKEv2) must be updated to accept EAP code values above 4 and to support peer-initiated ERP. Other lower layers may require similar revisions.
Some EAP implementations are not RFC 3748 compliant and may treat EAP packets with code values higher than 4 as errors rather than silently discarding them. Lower layers SHOULD verify that both parties support ERP before sending ERP messages, or mandate falling back to full EAP when ERP support cannot be confirmed.
A given rMSK MUST NOT be shared by multiple authenticators. Its lifetime MUST NOT be greater than the lifetime of the rRK. If a new rRK is derived, subsequent rMSKs MUST be derived from the new rRK.
Exactly one keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth packet and exactly one SHALL be present in an EAP-Finish/Re-auth message.
HMAC-SHA256-128 (cryptosuite value 2) is mandatory to implement and should be enabled in the default configuration. The defined cryptosuites are: 1=HMAC-SHA256-64, 2=HMAC-SHA256-128, 3=HMAC-SHA256-256.
If an authenticator supports ERP and receives an EAP-Initiate/Re-auth message after having sent an EAP-Request/Identity message, it MUST proceed with the ERP exchange. It MUST NOT close the connection if an ERP exchange is in progress or has already succeeded in establishing an rMSK.
The AAA protocol carrying keys between ER servers and authenticators is RECOMMENDED to be protected using IPsec or TLS. Without such protection, AAA proxies in the path may have access to keys being transported.
The home ER server MUST NOT hand out a given DSRK to a local domain server more than once, unless it can verify that the receiving entity is the same as the original recipient. The Authorization Indication TLV (Type 6) may be included to assure the peer that DSRK delivery is secure.
The rIK MUST NOT be used to derive any other keys and MUST NOT be transported to any entity other than the peer and server. Its length MUST equal the length of the rRK, and it 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. Its lifetime is never greater than that of its parent key, and it MUST be removed from use when the parent key expires.
The server MUST verify that the received sequence number is equal to or greater than the expected sequence number before verifying the cryptosuite and message integrity. On any verification failure, it MUST send an EAP-Finish/Re-auth with Result flag set to '1' (Failure), and MUST integrity-protect that failure message if it has a valid rIK for the peer.
When the SEQ sequence number rotates (reaches its maximum), the peer MUST run full EAP authentication. The peer MUST increment the sequence number after each ERP exchange, even when retransmitting.
ERP (EAP Re-authentication Protocol) is a single round-trip, EAP method-independent re-authentication protocol between a peer and an ER server, executed through an authenticator acting as a pass-through. It requires prior full EAP authentication to derive root keys (rRK, rIK) that are then used to authenticate re-authentication without repeating the full EAP method exchange.
The ER key hierarchy consists of three derived keys: the re-authentication Root Key (rRK) derived from the EMSK or DSRK; the re-authentication Integrity Key (rIK) derived from the rRK for integrity-protecting ERP messages; and per-authenticator re-authentication MSKs (rMSK) derived from the rRK using the sequence number as input.
The keyName-NAI identifies the rIK used to protect an ERP message. The username part contains the EMSKname (64-bit value encoded as 128 hex octets), and the realm identifies the ER server domain. The realm is the home domain when using the home ER server, or the local domain name when using a local ER server.
Two new EAP codes are defined: EAP-Initiate (code 5) and EAP-Finish (code 6). Two type values are assigned: Re-auth-Start (Type 1, applies to Initiate only) and Re-auth (Type 2, applies to both Initiate and Finish).
A new 'EAP Initiate and Finish Attributes' table is created with: 0=Reserved, 1=keyName-NAI (TLV), 2=rRK Lifetime (TV), 3=rMSK Lifetime (TV), 4=Domain name (TLV), 5=Cryptosuite list (TLV), 6=Authorization Indication (TLV), 7-127=IANA/IETF Consensus, 128-132=channel binding (Called-Station-Id through NAS-IPv6-Address), 133-191=channel binding IANA, 192-255=Private use.
A new 'Re-authentication Cryptosuites' registry is created with: 0=Reserved, 1=HMAC-SHA256-64, 2=HMAC-SHA256-128, 3=HMAC-SHA256-256, 4-191=IANA/IETF Consensus, 192-255=Private use. Also registers the USRK key label 'EAP Re-authentication Root [email protected]' and the rIK label 'Re-authentication Integrity [email protected]'.
Two new EAP Packet Codes are registered: 5 (Initiate) and 6 (Finish). A new 'Message Types' table is created in the EAP registry with: 0=Reserved, 1=Re-auth-Start (Initiate only), 2=Re-auth (Initiate and Finish), 3-191=IANA/IETF Consensus, 192-255=Private use.
A DoS attack is possible via bogus EAP-Initiate/Re-auth messages: an attacker can trigger the server to issue an EAP-Finish/Re-auth failure, which may cause link-layer connections to be terminated. To prevent this, an ERP failure MUST NOT result in deletion of any authorization state established by a prior full EAP exchange.
The rIKname (EMSKname) in the keyName-NAI is not changed across ERP exchanges, making it possible to correlate multiple ERP runs for the same peer, which has privacy implications. There was no consensus at the time of publication to require per-exchange rIKname rotation.
There is no forward secrecy within ERP. Compromise of a DSRK retroactively compromises all ERP keys derived from it (DS-rRK, DS-rIK, and all rMSKs). Keys may also be exposed to AAA proxies along the path when hop-by-hop protection is used.
ERP bootstrapping has two modes: implicit (local ER server requests DSRK from home AAA during initial EAP exchange) and explicit (peer sends EAP-Initiate/Re-auth with bootstrap flag 'B' set to obtain domain name and key lifetimes from home ER server). After receiving a bootstrap response with a domain name TLV, the peer MUST derive DSRK, DS-rRK, DS-rIK, and initialize the replay counter for the DS-rIK.
The EAP-Finish/Re-auth packet (Type=2) mirrors the Initiate/Re-auth format: 1-octet flags (R=result, B=bootstrap, L=lifetime present), 16-bit SEQ, TV/TLV attributes (keyName-NAI, optionally rRK Lifetime Type=2 as 32-bit seconds, rMSK Lifetime Type=3 as 32-bit seconds, Domain-Name Type=4, cryptosuite list Type=5, Authorization Indication Type=6), 1-octet cryptosuite, and Authentication Tag.
The EAP-Initiate/Re-auth packet (Type=2) contains: 1-octet flags field with R/B/L bits; 16-bit SEQ field for replay protection; one or more TV/TLV attributes (including mandatory keyName-NAI TLV); 1-octet cryptosuite field; and a variable-length Authentication Tag over the entire packet excluding the tag itself.
The EAP-Initiate/Re-auth-Start packet (Type=1) contains a 1-octet Reserved field (MUST be zero) followed by one or more TV or TLV attributes. TLV attributes have a 1-octet Type, 1-octet Length (length of value in octets), and variable-length Value. TV attributes have a 1-octet Type and a type-specific-length Value with no explicit length field.