Forward Secrecy Extension to the Improved Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)
updates
Extracted elements (30)
AT_KDF is retained for deriving K_encr and K_aut because these keys must be available before the ECDHE exchange completes (K_aut protects the AT_PUB_ECDHE attribute itself). AT_KDF_FS separately governs K_re, MSK, and EMSK, which incorporate SHARED_SECRET and thus gain the forward secrecy property.
The ECDHE computation runs in the mobile phone rather than the USIM card, so no new credentials, no USIM card updates, and no changes to the USIM-terminal interface are required. Existing subscribers can benefit from forward secrecy without reissuing SIMs.
The extension is implemented as optional, skippable EAP attributes (AT_KDF_FS and AT_PUB_ECDHE) so legacy implementations can ignore them. However, these attributes are covered by AT_MAC in the base EAP-AKA' integrity check, making bidding-down attacks detectable to any party holding the long-term key.
The two initially registered ECDHE groups (X25519 and P-256) are chosen to align with the elliptic curves and wire formats used for SUCI encryption in 3GPP TS 33.501 Appendix C.3.4, facilitating implementation reuse in 5G deployments.
A Peer that does not recognize the FS extension ignores AT_KDF_FS and AT_PUB_ECDHE and proceeds with base EAP-AKA' as specified in RFC 9048. The Server makes a policy decision on whether to allow such fallback; allowing it maintains backward compatibility with legacy equipment.
AT_KDF_FS and AT_PUB_ECDHE MUST NOT be added to EAP-Request/AKA'-Identity, EAP-Response/AKA'-Identity, EAP-Response/AKA'-Synchronization-Failure, EAP-Response/AKA'-Authentication-Reject, or EAP-Response/AKA'-Client-Error messages. Any appearance of these attributes in those messages MUST be ignored.
For P-256, at least partial public key validation MUST be performed on received ephemeral public keys, as required by NIST SP 800-56A Sections 5.6.2.3.4, 5.6.3.1, and 5.6.3.3.
If the Server proposes the FS extension but the Peer ignores it and the Server's policy does not allow fallback, the Server MUST behave as if authentication failed.
If validation of the other party's ephemeral public key or the computed shared secret fails, a party MUST behave as if the current EAP-AKA' process starts again from the beginning.
In EAP-Request/AKA'-Challenge, AT_KDF_FS and AT_PUB_ECDHE MUST be included when the Server wishes to use the extension. If either is missing on reception, the Peer MUST treat it as if neither was sent and fall back to base EAP-AKA'.
In EAP-Response/AKA'-Challenge, if the Peer is participating in the FS extension, AT_PUB_ECDHE MUST be included carrying the Peer's ephemeral public key. AT_MAC MUST be included and checked as specified in RFC 9048.
Servers MUST send one or more AT_KDF_FS attributes in the EAP-Request/AKA'-Challenge message, ordered by preference with the most preferred first. Only the most preferred function has a corresponding AT_PUB_ECDHE attribute.
Support for both the X25519 group and the P-256 group is REQUIRED; the term 'support' means the group MUST be implemented.
The AT_KDF_FS Length field MUST be set to 1 (4 bytes total for the attribute).
The Peer identifier sent in EAP-Response/AKA'-Identity SHALL comply with the privacy-friendly requirements of RFC 9190. A non-null SUCI is given as an example of a compliant identifier.
The Peer MUST fail authentication if it receives an AT_KDF_FS list containing duplicate values, except when the duplication arises legitimately from a Peer-requested KDF change (in which case the selected alternative appears twice at the head of the list).
The sender SHALL generate a fresh AT_PUB_ECDHE value for each run of the protocol. Reusing ephemeral keys would undermine the forward secrecy property.
When a connection is closed, each endpoint MUST destroy not only the ephemeral keys used by the connection but also any information that could be used to recompute those keys, in order to realize the forward secrecy property.
When the Peer receives a new EAP-Request/AKA'-Challenge after requesting a KDF change, it MUST check that exactly the requested change, and only that change, occurred in the AT_KDF_FS list. If multiple unsolicited AT_KDF_FS changes arrive, the Peer MUST fail authentication as if AT_MAC were incorrect.
AT_KDF, AT_KDF_FS, and AT_PUB_ECDHE are transmitted without protection and reveal the cryptographic algorithms in use; if algorithm choice depends on the Peer identity, they leak information about the Peer. AT_KDF_INPUT reveals the network name. An observer can use these for traffic flow analysis or endpoint tracking.
Two ECDHE groups are specified: X25519 (Curve25519, RFC 7748) identified by FS KDF value 1, and P-256 (NIST secp256r1 / SEC group secp256r1) identified by FS KDF value 2. The group selection is implicit in the AT_KDF_FS value; no separate group negotiation is needed.
When the FS extension is active (AT_KDF=1, AT_KDF_FS=1 or 2), key derivation proceeds as: MK=PRF'(IK'|CK',"EAP-AKA'"|Identity); MK_ECDHE=PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity). K_encr=MK[0..127], K_aut=MK[128..383], K_re=MK_ECDHE[0..255], MSK=MK_ECDHE[256..767], EMSK=MK_ECDHE[768..1279]. AT_KDF governs K_encr and K_aut; AT_KDF_FS governs K_re, MSK, and EMSK.
New 'EAP-AKA' AT_KDF_FS Key Derivation Function Values' registry created. Initial values: 0=Reserved, 1='EAP-AKA' with ECDHE and X25519', 2='EAP-AKA' with ECDHE and P-256', 3-65535=Unassigned. New allocations require Specification Required policy (RFC 8126).
Two new values assigned in the 'Attribute Types (Skippable Attributes 128-255)' registry under 'EAP-AKA and EAP-SIM Parameters': 152 for AT_PUB_ECDHE and 153 for AT_KDF_FS.
DoS risk from ECDHE computation is mitigated by requiring the AKA authentication (demonstrating possession of the long-term key) to succeed before FS calculations begin. This limits amplification attacks to identified subscribers and makes bulk attacks identifiable for blocking.
EAP-AKA' FS provides forward secrecy: an attacker who gains the AKA long-term key cannot recover session keys from ended past sessions, provided those sessions destroyed all ephemeral key material. The ECDHE exchange also forces any attacker with the long-term key to be on-path during each authentication run, preventing passive mass surveillance.
If a Cryptographically Relevant Quantum Computer (CRQC) is built, it could recover SHARED_SECRET from the ECDHE public keys. Combined with long-term key compromise, this would eliminate the forward secrecy property. Symmetric algorithms (HMAC-SHA-256, AT_AUTN, AT_RES) remain secure. Future documents can add PQC KEM support through the same AT_PUB_ECDHE/AT_KDF_FS framework.
K_encr and K_aut are derived before the ECDHE shared secret is available. Consequently, data encrypted in AT_ENCR in the EAP-Request/AKA'-Challenge (e.g., re-authentication pseudonyms) is not forward secret. An adversary compromising the long-term key can link re-authentication runs within a sequence following a single full authentication.
AT_KDF_FS (type=153) is a fixed-length attribute carrying a 2-byte enumerated FS Key Derivation Function value. The Length field MUST be set to 1 (indicating 4 bytes total). Its namespace is distinct from the AT_KDF attribute defined in RFC 9048.
AT_PUB_ECDHE (type=152) carries the sender's ECDHE ephemeral public key. For X25519 the value is 32 bytes encoded per RFC 7748 Section 5; for P-256 it is 33 bytes in compressed form per SEC1 Section 2.3.3. The Value field is zero-padded to the next multiple of 4 bytes. Length is expressed in multiples of 4 bytes and includes the type, length, and value fields.