EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)
Extracted elements (29)
ERP/AAK extends ERP to allow cryptographic keying material to be established on one or more Candidate Attachment Points (CAPs) prior to handover, reusing ERP packet formats with a new 'E' flag to differentiate early authentication from re-authentication. This avoids a full EAP exchange after handover by pre-positioning keys via the AAA infrastructure.
The pRK is derived from the DSRK (not EMSK) when the peer is in a visited realm, and if the peer has previously authenticated via ERP or ERP/AAK the DSRK SHOULD be directly reused. This avoids redundant key derivation while preserving domain isolation when roaming.
ERP/AAK reuses the cryptosuites defined for 'Re-authentication Cryptosuites' in RFC 5296 and reuses ERP packet formats. Lower-layer specifications may need revision to support ERP/AAK, analogous to the guidance in Section 6 of RFC 5296.
Different sequence numbers for each CAP MUST be used to derive a unique pMSK, preventing the compromise of one pMSK from affecting others (domino effect prevention).
Exactly one keyName-NAI attribute SHALL be present in both EAP-Initiate/Re-auth and EAP-Finish/Re-auth packets. The NAI MUST NOT exceed 253 octets, and the realm part SHOULD follow internationalized domain name conventions per RFC 5890.
HMAC-SHA256-128 is REQUIRED to implement as the cryptosuite and SHOULD be enabled in the default configuration. If the chosen algorithm is unacceptable, the server returns EAP-Finish/Re-auth with a Failure indication.
If an EAP-Initiate/Re-auth message fails Authentication Tag verification or the tag is not included, the message SHOULD be discarded silently by both the SAP (for inbound) and the peer (for EAP-Finish/Re-auth).
If the 'L' flag is set in EAP-Initiate/Re-auth, both pMSK Lifetime and pRK Lifetime attributes MUST be present in the EAP-Finish/Re-auth response. The rIK SHOULD share the same lifetime as the pMSK.
The 'E' flag in the EAP-Initiate/Re-auth-Start packet MUST be set to '1' if early authentication is in use and MUST be set to '0' otherwise. The remaining 7 reserved bits MUST be set to 0 and ignored on reception.
The ERP/AAK server MUST derive a pMSK from the pRK for the CAP specified in the CAP-Identifier TLV using the associated sequence number as a KDF input, then MUST transport the pMSK to the authorized CAP via AAA.
The peer MUST maintain retransmission timers for reliable transport of EAP-Initiate/Re-auth. If no response is received after the necessary retransmissions, the peer MUST assume ERP/AAK is not supported by the SAP.
Upon receiving EAP-Initiate/Re-auth, the ERP/AAK server MUST use the keyName from the keyName-NAI to look up the rIK, check message integrity and freshness, verify the peer's identity via the username portion, and authorize the specified CAP. Any failure MUST result in EAP-Finish/Re-auth with Result flag set to '1' (Failure).
CAP-Identifier TLV (Type 11) carries the Fully Qualified Domain Name (FQDN) of a Candidate Attachment Point encoded as specified in Section 8 of RFC 3315 (DHCPv6). It appears in EAP-Initiate/Re-auth, as a sub-TLV of ERP/AAK-Key in EAP-Finish/Re-auth, and optionally in EAP-Initiate/Re-auth-Start.
ERP/AAK-Key TLV (Type 8) is a key container carried in EAP-Finish/Re-auth containing sub-TLVs for CAP-Identifier, pMSK Lifetime, pRK Lifetime, and List of Cryptosuites. Exactly one ERP/AAK-Key SHALL be present per EAP-Finish/Re-auth packet.
The Authentication Tag field contains an integrity checksum over the entire ERP/AAK packet from the first bit of Code through the last bit of the Cryptosuite field (excluding the tag itself), computed using the algorithm from the Cryptosuite field with rIK as the secret key.
The Cryptosuite field (1 octet) indicates the integrity algorithm. Defined values: 0-1 RESERVED, 2 = HMAC-SHA256-128, 3 = HMAC-SHA256-256. HMAC-SHA256-128 denotes HMAC-SHA256 with output truncated to 128 bits.
The ERP/AAK exchange involves five high-level steps: (a) optional EAP-Initiate/Re-auth-Start from SAP with CAP identities, (b) EAP-Initiate/Re-auth with E flag from peer, (c) AAA encapsulation to EA server, (d) CA authorization and key derivation, (e) pMSK transport to CAP via AAA, (f/g) EAP-Finish/Re-auth with E flag returned to peer.
The pre-established Master Session Key (pMSK) is derived from the pRK as: pMSK = KDF(pRK, 'EAP Early-Authentication Master Session [email protected]' | '\0' | SEQ | length). SEQ is the 16-bit sequence number from the ERP/AAK message and makes each pMSK unique per CAP.
The pre-established Root Key (pRK) is derived from either the EMSK (when the peer is in the home AAA realm) or the DSRK (when in a visited realm). pRK = KDF(K, S) where S = 'EAP Early-Authentication Root [email protected]' | '\0' | length.
IANA added the label 'EAP Early-Authentication Root [email protected]' to the 'User Specific Root Keys (USRK) Key Labels' sub-registry of the EMSK Parameters registry, enabling the pRK derivation defined in Section 4.1.
IANA assigned five new TLV types in the 'EAP Initiate and Finish Attributes' registry: Type 7 (Sequence number, TV), Type 8 (ERP/AAK-Key, TLV), Type 9 (pRK Lifetime, TLV), Type 10 (pMSK Lifetime, TLV), Type 11 (CAP-Identifier, TLV).
Three new IANA flag registries were created: 'EAP Initiate/Re-auth-Start Flags' (E flag = 0x80); 'EAP Initiate/Re-auth Flags' (R=0x80, B=0x40, L=0x20 from RFC 5296; E=0x10 new); 'EAP Finish/Re-auth Flags' (R=0x80, B=0x40, L=0x20 from RFC 5296; E=0x10 new). New values require Standards Action or IESG Approval.
ERP/AAK satisfies cryptographic algorithm independence: the peer indicates the chosen algorithm in EAP-Initiate/Re-auth; if unacceptable the server rejects with failure. Strong, fresh per-CAP session keys are always derived on demand, and compromise of one pMSK does not compromise any other pMSK.
Key scope is well-defined and restricted: pRK is used only to derive pMSK for CAPs, domain-specific keys are restricted to their domain, and all derived key lifetimes are bounded by the parent key lifetime or server policy.
Mutual authentication is inherited from ERP: the peer and server authenticate via ERP, the peer and SAP authenticate via ERP, and the CAP is authenticated and trusted by the SAP. Keying material confidentiality is maintained because peer and server derive keys independently using shared parameters without disclosing them.
Replay protection is achieved via a sequence number associated with each pMSK. The peer increments the sequence number after each ERP/AAK message; the server sets the expected sequence number to received+1 after verifying the message.
EAP-Finish/Re-auth extension adds the 'E' flag (0x10) and TLVs including keyName-NAI (Type 1) and ERP/AAK-Key (Type 8). The ERP/AAK-Key TLV is a container with sub-TLVs: CAP-Identifier (Type 11), pMSK Lifetime (Type 10, unsigned 32-bit seconds), pRK Lifetime (Type 9, unsigned 32-bit seconds), and List of Cryptosuites (Type 5).
EAP-Initiate/Re-auth extension adds the 'E' flag (bit 4 of the flags byte, value 0x10), a 16-bit SEQ field for replay protection, and TLVs including keyName-NAI (Type 1), CAP-Identifier (Type 11), Sequence number (Type 7). A Cryptosuite byte and variable-length Authentication Tag trail the TLVs.
EAP-Initiate/Re-auth-Start extension adds a 1-bit 'E' flag (early authentication indicator) in the flags byte after the Type field, with the remaining 7 bits reserved and set to 0. It may carry a CAP-Identifier TLV (at most one) advertising the SAP-adjacent CAP.