Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')
updated by
- rfc-9678 — Forward Secrecy Extension to the Improved Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)
updates
Extracted elements (29)
AT_KDF negotiation is designed so that the peer accepts the server's first-choice silently, but can propose an alternative by sending back only one AT_KDF. The server's re-sent challenge carries the selected alternative at the front plus the full original list, and a deliberate duplicate is the only legal form of duplication. This prevents a MITM from silently substituting a KDF without either party being aware.
EAP-AKA' uses a separate EAP Type code (0x32 vs 0x17) rather than negotiating within EAP-AKA, because any change to key derivation must be unambiguous to both sides — accidental connection of old and new equipment must not silently produce wrong keys. Explicit method type negotiation via EAP makes this unambiguous.
EAP-AKA' in 5G does not use the leading '6' character prefix for IMSI-based permanent usernames that is required in 4G; identifier handling follows 3GPP TS 33.501 Annex F. A server implementing only EAP-AKA (not EAP-AKA') may not recognize the '6', '7', or '8' leading characters used by EAP-AKA' peers.
RFC 9048 updates the network name reference from 3GPP TS 24.302 Release 8 (used in RFC 5448) to Release 16, ensuring EAP-AKA' key derivation is compatible with 5G deployments. This reference change does not alter the TS number, only the version, but is critical for correct key computation.
If both the EAP-AKA server and peer would have been able to use EAP-AKA' (as indicated by AT_BIDDING with D=1 on both sides), the peer SHOULD abort the EAP-AKA authentication, as a bidding down attack may have occurred.
If the peer performs a comparison of its locally determined network name against the AT_KDF_INPUT value, it MUST use a prefix-match algorithm: break each name into colon-separated fields, ignore extra fields in the longer name, and compare remaining fields character by character. If the peer chooses to proceed despite discrepancy, it MUST use the network name from AT_KDF_INPUT.
In 5G deployments, when AT_KDF_INPUT contains the prefix '5G:' and AT_KDF=1 with full authentication, the peer identity used in key derivation MUST be as specified in 3GPP TS 33.501 Annex F.3 and TS 23.003 Clause 2.2, not the NAI used in EAP. EAP-AKA' in 5G does not use the '0' or '6' prefix.
On fast re-authentication, the peer SHOULD NOT attempt fast re-authentication when it knows the network name in the current access network differs from the one used in the initial full authentication, and the server SHOULD fall back to full authentication upon detecting a changed network name.
Pseudonym usernames and fast re-authentication identities MUST be generated in a cryptographically secure way such that it is computationally infeasible to differentiate two identities belonging to the same user from two belonging to different users. They MUST NOT include substrings that can be related to a particular entity or permanent identity.
Servers MUST send one or more AT_KDF attributes in EAP-Request/AKA'-Challenge, ordered by preference. If the peer receives multiple EAP-Request/AKA'-Challenge messages with differing AT_KDF attributes without having requested negotiation, the peer MUST behave as if AT_MAC were incorrect and fail the authentication.
SUPI MUST NOT be communicated in EAP-AKA' messages when authenticating to a 5G network; its use is only internal (as key derivation input). When SUCI is used in EAP-AKA', its format MUST be as specified in 3GPP TS 23.003 Section 28.7.3.
The AT_KDF_INPUT attribute value sent by the server MUST be non-empty (Actual Network Name Length > 0). If the attribute is empty, the peer MUST treat it as if AUTN were incorrect and fail the authentication.
When a privacy-friendly identifier used only once is employed in an EAP-AKA' exchange, the EAP-AKA' peer MUST NOT use a pseudonym provided in that exchange in subsequent exchanges more than once.
When creating an AKA challenge, the server MUST set the AMF separation bit to 1 in the AKA algorithm. The peer MUST check that the AMF separation bit is set to 1; if not, the peer fails the authentication as if AUTN were incorrect.
Use of permanent identifiers (IMSI, SUPI) in EAP-AKA' is strongly NOT RECOMMENDED as it enables subscriber tracking. Privacy-friendly identifiers (5G GUTI, SUCI, pseudonyms, fast re-authentication identities) are strongly RECOMMENDED. The SUCI null-scheme is also NOT RECOMMENDED where identity privacy matters.
AT_KDF negotiation allows the peer to reject the server's first-choice KDF by responding with an EAP-Response/AKA'-Challenge containing only one AT_KDF attribute set to its preferred alternative. The server then re-sends the challenge with the selected alternative prepended to the AT_KDF list, resulting in a deliberate duplication that signals the agreed change.
AT_MAC in EAP-AKA' uses HMAC-SHA-256-128: the full 32-byte HMAC-SHA-256 output is truncated to the first 16 bytes, yielding a 16-byte MAC. EAP-AKA uses HMAC-SHA-1 instead.
EAP-AKA' key hierarchy (AT_KDF=1): MK = PRF'(IK'|CK', "EAP-AKA'"|Identity), yielding K_encr (bits 0–127, 128-bit encryption key), K_aut (128–383, 256-bit auth key), K_re (384–639, 256-bit re-auth key), MSK (640–1151, 512 bits), and EMSK (1152–1663, 512 bits).
EAP-AKA' Session-Id for full authentication is: 0x32 || RAND || AUTN. For fast re-authentication: 0x32 || NONCE_S || MAC (from EAP-Request/AKA-Reauthentication). Peer-Id is the AT_IDENTITY contents or EAP Identity Response; Server-Id is the null string.
EAP-AKA' uses Type code 0x32 (not 0x17 used by EAP-AKA), carries AT_KDF_INPUT and AT_KDF attributes, derives keys using CK'/IK' with SHA-256/HMAC-SHA-256, and uses IMSI-based permanent usernames with leading character '6' for 4G networks.
PRF' is defined as T1|T2|T3|... where T1=HMAC-SHA-256(K,S|0x01), T2=HMAC-SHA-256(K,T1|S|0x02), etc. K is 256 bits; S is arbitrary-length. This construction is identical to the one used in IKEv2 (RFC 7296, Section 2.13).
IANA updated the 'EAP-AKA and EAP-SIM Parameters' registry: AT_KDF_INPUT (23) and AT_KDF (24) in the Non-Skippable Attributes subregistry, and AT_BIDDING (136) in the Skippable Attributes subregistry, now reference RFC 9048. The 'EAP-AKA' AT_KDF Key Derivation Function Values' subregistry defines value 0 (Reserved) and value 1 (EAP-AKA' with CK'/IK'), with new values requiring Specification Required policy.
EAP-AKA' binds derived keys to the access network name via CK'/IK', preventing keys stolen from one network from being used on another. The server verifies that the claimed access network name matches what it should be, and the peer compares it with its own local observation, preventing 'lying NAS' attacks. The AMF separation bit MUST be set to 1 and checked by the peer.
EAP-AKA' does not provide Perfect Forward Secrecy (PFS). Long-term key theft (as reported in [Heist2015]) can expose past sessions to passive attackers. Use of a PFS-capable mechanism (e.g., tunneled EAP or the separately defined EAP-AKA' PFS extension) is recommended.
The AKA resynchronization protocol can be exploited to detect subscriber presence in an area (Arapinis et al.) or to predict authentication frequency via SQN leakage (Borgaonkar et al.). EAP-AKA' implementations should provide means to track, detect, and limit excessive authentication attempts.
AT_BIDDING attribute (type 136) is a 4-byte attribute used only in EAP-AKA messages. Fields: 1-byte type, 1-byte length (MUST be 1), 1-bit D flag (set to 1 if sender supports and prefers EAP-AKA'), 15-bit Reserved (MUST be zero on send, ignored on receipt).
AT_CHECKCODE in EAP-AKA' carries a 256-bit (32-byte) SHA-256 hash over the same data as specified in RFC 4187 Section 10.13, or 0 bytes if no identity attributes were exchanged. The field is 0 or 32 bytes.
AT_KDF attribute (type 24) carries a 2-byte Key Derivation Function enumeration value. Fields: 1-byte type, 1-byte length (MUST be 1), and 2-byte Key Derivation Function value. Value 1 indicates the default EAP-AKA' KDF using CK'/IK'.
AT_KDF_INPUT attribute (type 23) carries the access network name as a UTF-8 string. Fields: 1-byte type, 1-byte length (multiples of 4), 2-byte Actual Network Name Length, and a variable-length Network Name padded to a 4-byte boundary.