| Internet-Draft | Forward Secure Reauth. in EAP-AKA' | October 2026 |
| Wang & Lei | Expires 19 April 2027 | [Page] |
This draft specifies an update to RFC 9678, "Forward Secrecy Extension to the Improved Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)". This update enables forward security of the Transient EAP Keys (TEKs) for protecting EAP packets, which are not in EAP-AKA' FS. Based on this extension, the executions of reauthentication after a full authentication will be unlinkable to each other and then the privacy of end users is enhanced. This update is also applicable to the successors of RFC 9678, with post-quantum key encapsulation mechanisms (KEMs) or hybrid KEMs.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Changes made in version 03:¶
Changes made in version 02:¶
Changes made in version 01:¶
EAP-AKA (Extensible Authentication Protocol method for 3rd Generation Authentication and Key Agreement) [RFC4187] is a secure authentication method used for mobile devices connecting to networks using their credentials from SIM/USIM cards. It enables mutual authentication and key exchange between the mobile devices and their mobile network operator. After that, communication data can be securely transmitted between them by using various key materials agreed and dervied in EAP-AKA.¶
EAP-AKA' (Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) [RFC5448], introduces a new key derivation function, SHA-256, instead of SHA-1. This function is also used to bind the keys derived within the method to the name of the access network. This limits the effects of compromised access network nodes and keys.¶
Moreover, "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')" [RFC9048] specifies the protocol behavior for both 4G and 5G deployments using EAP-AKA'. For example, how the Network Name field is constructed in the protocol; how EAP-AKA' uses identifiers in 5G; how to define session identifiers and other exported parameters (including the case for fast reauthentication), and how to update the requirements on generating pseudonym usernames and fast reauthentication identities to ensure identity privacy.¶
"Forward Secrecy Extension to the Improved Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)" [RFC9678] enhances the forward security for the session keys generated as a part of the authentication run in EAP-AKA', by introducing ephemeral Diffie-Hellman (DH) key exchange. This prevents an attacker who has gained access to the long-term key from compromising session keys established in the past. However, as noted in Section 7.6 of [RFC9678], K_encr, the key for encrypting reauthentication pseudonym identities, is not forward secure, as it is generated before the execution of ephemeral DH. Therefore, "an adversary compromising the long-term key would be able to link reauthentication protocol runs when pseudonyms are used, within a sequence of runs followed after a full EAP-AKA' authentication. No such linking would be possible across different full authentication runs. If the pseudonym linkage risk is not acceptable, one way to avoid the linkage is to always require full EAP-AKA' authentication."¶
However, as discussed in [RFC4187], reauthentication is much faster and then benefits both mobile devices and the network operator. Having full EAP AKA' authentication defeats the purpose of fast reauthentication. This document specifies an update to enhance the forward security for TEKs (including K_encr) in EAP-AKA' FS. Based on this, it is not feasible to link different runs of reauthentication within a full authentication. When this extension is enabled, the privacy of mobile users is further enhanced against long-term key compromise. This update is applicable and optional to [RFC9678].¶
This extension is also applicable and optional to the drafts specified in [I-D.ietf-emu-pqc-eapaka] and [I-D.ietf-emu-hybrid-pqc-eapaka], where the ephemeral DH key exchange is replaced by post-quantum (PQ) KEM and hybrid KEMs [RFC9794], respectively.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Readers are assumed familiar with the terms in EAP-AKA [RFC4187], EAP-AKA' [RFC5448] [RFC9048], and EAP-AKA' FS [RFC9678]. The implication of forward security is discussed in Sections 1 and 4.3 of [RFC9678], and the usage of reauthentication is discussed in Section 5 of [RFC4187], and Sections 6.5.4 and 6.5.5 of [RFC9678].¶
The normal process of EAP-AKA' FS is briefly reviewed in Figure 1, where AD denotes the 3GPP Authentication Database. Details can be found in Section 5 of [RFC9678].¶
USIM Peer Server AD | | | | | | (1) EAP-Req/Identity | | | |<----------------------------| | | | (2) EAP-Resp/Identity | | | | (Privacy-Friendly) | | | |---------------------------->| | | | |(3) ID, KDF,network name| | | |----------------------->| | | |(4) RAND, AUTN, XRES, | | | | CK', IK' | | | |<-----------------------| | | (5) EAP-Req/AKA'-Challenge | | | | AT_RAND, AT_AUTN, AT_KDF, | | | | AT_KDF_FS, AT_KDF_INPUT, | | | | AT_PUB_ECDHE, AT_MAC | | | |<----------------------------| | |(6) RAND, AUTN | | | |<---------------| | | |(7) CK, IK, RES | | | |--------------->| | | | |(8) EAP-Resp/AKA'-Challenge | | | | AT_RES, AT_PUB_ECDHE, AT_MAC| | | |---------------------------->| | | | (9) EAP-Success | | | |<----------------------------| | Figure 1. EAP-AKA' FS Authentication Process (Section 5 of RFC 9678)¶
Key materials are derived in EAP-AKA' FS as shown in Figure 2 (Section 6.3 of [RFC9678]). Note that the TEKs, consisting of both K_encr and K_aut, are part of MK (Master Key). However, MK itself is derived from IK' and CK' without the ephemeral SHARED_SECRET, obtained via running ephemeral DH key exchange. Therefore, both K_encr and K_aut are not forward secure, as they just rely on the security of the long-term key, shared by the peer's USIM and the mobile network operator's AD. Note that IK' and CK' are derived from this long-term key.¶
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] Figure 2. Key Derivation in EAP-AKA' FS (Section 6.3 of RFC 9678)¶
In more detail, the ephemeral SHARED_SECRET is generated from ephemeral DH values available in two AT_PUB_ECDHE attributes, exchanged by the peer and server in Steps (5) and (8) in Figure 1. However, K_encr and K_aut are generated by the server after Step (4) and used in Step (5) to protect the information for the peer. And similarly, they are generated after Step (7) by the peer and used to verify and decrypt ciphertext sent in Step (5), and used in Step (8) to protect the information for the server. So, the ephemeral SHARED_SECRET is available later than when K_encr and K_aut are generated and used by the server and the peer. So, in case the long-term key is compromised, K_encr and K_aut will be compromised too.¶
Figure 3 is a brief review of the reauthentication procedure, which is specified in Section 5.4 of [RFC4187]. Here all attributes with '*' denote that they are encrypted using the encryption key K_encr, and encapsulated in the AT_ENCR_DATA attribute. For offering the peer a new reauthentication identity for the next run, the authenticator/server generates a pseudonym identity and uses K_encr to encrypt it in the optional attribute AT_NEXT_REAUTH_ID. At the same time, the authenticator/server uses integrity key K_aut to produce a MAC in the atttibute AT_MAC in Step (3).¶
Peer Authenticator/Server | | | (1) EAP-Request/Identity | |<----------------------------------------------------------| | (2) EAP-Response/Identity | | (Includes a fast reauthentication identity) | |---------------------------------------------------------->| | (3) EAP-Request/AKA-Reauthentication | | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, *AT_NONCE_S, | | *AT_NEXT_REAUTH_ID, AT_MAC) | |<----------------------------------------------------------| | (4) EAP-Response/AKA-Reauthentication | |(AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, AT_MAC) | |---------------------------------------------------------->| | (5) EAP-Succes | |<----------------------------------------------------------| Figure 3. Reauthentication Procedures (Section 5.4 of RFC 4187)¶
As discussed above, K_encr and K_aut can be compromised if the long-term key is leaked. So, in such case, an attacker with access to the long-term key will be able to decrypt all reauthentication identities delivered from the server to the peer. When these pseudonym identities are used for reauthentication, the attacker will be able to link these runs of reauthentication, even those reauthentication identities are pseudonyms generated by the server independently.¶
Moreover, even without decrypting the reauthentication identities from the AT_NEXT_REAUTH_ID attributes, the attacker can also link two or more runs of reauthentication by using the integrity key K_aut. Namely, the attacker can just check the AT_MAC attributes sent by either the authenticator/server in Step (3) or the peer in Step (4) to be sure that different runs are associated with the same peer, if all these AT_MAC attributes are verified as valid with respect to the same K_aut.¶
Therefore, to guarantee the privacy of mobile users running reauthentication with compromised long-term key, it is necessary to enhance the forward security of the TEKs, i.e, K_encr and K_aut.¶
To enable the forward security of K_encr and K_aut, this document specifies the concrete key derivation processes by straightforwardly extending the output of pseudorandom functions given in [RFC9678], and [I-D.ietf-emu-pqc-eapaka] and [I-D.ietf-emu-hybrid-pqc-eapaka].¶
To udpate [RFC9678] where ECDHE is used for achieving forward security, this document extends the output of MK_ECDHE (Section 6.3 of [RFC9678]; also reviewed in Section 4.1) such that the last two parts of output are used as the values for K_encr' and K_aut', as shown in Figure 4.¶
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] K_encr' = MK_ECDHE[1280..1407] K_aut' = MK_ECDHE[1408..1663] Figure 4. The Proposed Key Derivation Process When ECDHE Used¶
In this process, the initial non-forward secure K_encr and K_aut are updated after completing full EAP-AKA' FS authentication in Figure 1 to forward secure K_encr' and K_aut', which are derived from IK', CK' and SHARED_SECRET, the ephemeral secret. Namely, K_encr' and K_aut' are derived from the same pseudorandom function PRF' with the input of ephemeral SHARED_SECRET, as did in Section 6.3 of [RFC9678] for deriving K_re, MSK, and EMSK.¶
After that, only forward secure K_encr' and K_aut' will be used to protect the transmission and usage of reauthenticaton identities in reauthentication procedures. The procedure details about how to use these two keys are specifed in Section 6.¶
Regarding backend storage of the forward-secure TEKs (namely K_encr' and K_aut'), these keys only need to live in-memory for the duration of the active full authentication session. So, they are SUGGESTED being purged immediately upon the corresponding full authentication session expiration. This is imporant to maintain forward secrecy for running reauthentication. Namely, reauthentication forward secrecy may be compromised due to the compromise of ephemeral shared secret or the leakage of K_encr' and K_aut'. In cases these keys need to be stored for any reasons, it SHOULD be guranteed for secure storage prevening their leakage to potential attackers.¶
To update [I-D.ietf-emu-pqc-eapaka] where a PQ KEM is used for achieving forward security, this document extends the output of MK_PQ_SHARED_SECRET (Section 8.2 of [I-D.ietf-emu-pqc-eapaka]) such that the last two parts of output are used as the values for K_encr' and K_aut', as shown in Figure 5.¶
MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
ct, ss = kemEncaps(pk)
MK_PQ_SHARED_SECRET = PRF'(IK'|CK'|ss,"EAP-AKA' FS"|Identity|ct)
K_encr = MK[0..127]
K_aut = MK[128..383]
K_re = MK_PQ_SHARED_SECRET[0..255]
MSK = MK_PQ_SHARED_SECRET[256..767]
EMSK = MK_PQ_SHARED_SECRET[768..1279]
K_encr' = MK_PQ_SHARED_SECRET[1280..1407]
K_aut' = MK_PQ_SHARED_SECRET[1408..1663]
Figure 5. The Proposed Key Derivation Process When PQ KEMs Used
¶
After that, only forward secure K_encr' and K_aut' will be used to protect the transmission and usage of reauthenticaton identities in reauthentication procedures, as described in Section 6.¶
The storage security requiremnts on TEKs described in Section 5.2 apply here as well.¶
To update [I-D.ietf-emu-hybrid-pqc-eapaka] where a hybrid KEM is used for achieving forward security, this document extends the output of MK_HYBRID (Section 7.2 of [I-D.ietf-emu-hybrid-pqc-eapaka]) such that the last two parts of output are used as the values for K_encr' and K_aut', as shown in Figure 5.¶
MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
HYBRID_SHARED_SECRET, ct = Encapsulate(pKR)
MK_HYBRID = PRF'(IK'|CK'|HYBRID_SHARED_SECRET,"EAP-AKA' FS"|Identity)
K_encr = MK[0..127]
K_aut = MK[128..383]
K_re = MK_MK_HYBRID[0..255]
MSK = MK_MK_HYBRID[256..767]
EMSK = MK_MK_HYBRID[768..1279]
K_encr' = MK_MK_HYBRID[1280..1407]
K_aut' = MK_MK_HYBRID[1408..1663]
Figure 6. The Proposed Key Derivation Process When Hybrid KEMs Used
¶
After that, only forward secure K_encr' and K_aut' will be used to protect the transmission and usage of reauthenticaton identities in reauthentication procedures, as described in Section 6.¶
The storage security requiremnts on TEKs described in Section 5.2 apply here as well.¶
In the following, the protocol flows are described to explain how to enable the forward security of reauthentication by using the updated Transient EAP Keys (TEKs), namely, K_encr' and K_aut'. The protocols are integrated from the reauthentication procedure reviewed in Section 4.2, the procedure of EAP-AKA' FS reviewed in Section 4.1, and the description of message processing for reauthentication given in Sections 6.5.5 and 6.5.6 of [RFC9678].¶
For simplicity, only new attributes in Figure 7 are described here. Other attributes are the same as in [RFC9678] (and reviewed in Section 4.2). Note that * denotes an encrypted attribute. The NEXT_REAUTH_ID in message (5) is the reauthentication ID, which is newly generated by the server and encrypted with K_encr. Note that K_encr' is not used here, because at this moment the sever is not sure if the peer also supports this update for enhancing the forward security of the TEKs. To check if the peer has this capability, the server sends out the attribute AT_SUPPORT_TEKs_FS, which is a new attribute introduced in this draft. Its format is defined in Section 7.¶
In message (8), if the peer does support the forward security of the TEKs, it will reply the attribute AT_SUPPORT_TEKs_FS as well. On successfully received this attribute and other attributes, the sever will update K_encr to K_encr', and K_aut to K_aut'. The concrete key derivation is specifed in Section 5, where the ephemeral shared secret key is an input for the key derivation. Note that K_encr' and K_aut' are forward secure. Then, in message (9), the sever will send another new reauth-ID in the atrribute AT_NEXT_REAUTH_ID, which is encrypted by K_encr'. In this case, as the peer supports the update specified in this draft, it will obtain this new reauth-ID for the coming fast reauthentication, as shown in Figure 8.¶
In case the peer does not support or does not want to support this udpate for TEKs, it MUST NOT send AT_SUPPORT_TEKs_FS in message (8), the sever will not update K_encr and K_aut after receiving such a message. Correspondingly, the server will not send *AT_NEXT_REAUTH_ID in message (9). Therefore, the peer SHALL use the reauth-ID sent in message (5) for the coming fast reauthentication. Note that such a reauth-ID is encrypted by K_encr, without forward security. This is the fallback situation.¶
USIM Peer Server AD | | | | | | (1) EAP-Req/Identity | | | |<----------------------------| | | | (2) EAP-Resp/Identity | | | | (Privacy-Friendly) | | | |---------------------------->| | | | |(3) ID, KDF,network name| | | |----------------------->| | | |(4) RAND, AUTN, XRES, | | | | CK', IK' | | | |<-----------------------| | | (5) EAP-Req/AKA'-Challenge | | | | AT_RAND, AT_AUTN, AT_KDF, | | | | AT_KDF_FS, AT_KDF_INPUT, | | | | AT_PUB_ECDHE, | | | | *AT_NEXT_REAUTH_ID, | | | | AT_SUPPORT_TEKs_FS, AT_MAC | | | |<----------------------------| | |(6) RAND, AUTN | | | |<---------------| | | |(7) CK, IK, RES | | | |--------------->| | | | |(8) EAP-Resp/AKA'-Challenge | | | | AT_RES, AT_PUB_ECDHE, | | | | AT_SUPPORT_TEKs_FS, AT_MAC | | | |---------------------------->| | | | (9) EAP-Success, | | | | *AT_NEXT_REAUTH_ID | | | |<----------------------------| | Figure 7. EAP-AKA' FS Authentication Process with TEKs Foward Security¶
Figure 8 shows the procedures of reauthentication run by the peer and server, without the involvement of USIM and AD. In fact, the procedures take the same shape as specified in Figure 10 of Section 5.4 in [RFC4187] (also reviewed in Section 4.2). In particular, the attributes AT_NEXT_REAUTH_ID and AT_MAC in message (3) are still shown in the same shape as in the case without forward security (reviewed in Section 4.2). However, those two attributes now are cryptographically protected by forward secure keys K_encr' and K_aut', rather than by non-forward secure keys K_encr and K_aut. This applies to the attribute AT_MAC in message (4) too, which is sent from the peer to the server.¶
Peer Authenticator/Server | | | (1) EAP-Request/Identity | |<----------------------------------------------------------| | (2) EAP-Response/Identity | | (Include a reauth-ID) | |---------------------------------------------------------->| | (3) EAP-Request/AKA-Reauthentication | | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, *AT_NONCE_S, | | *AT_NEXT_REAUTH_ID, AT_MAC) | |<----------------------------------------------------------| | (4) EAP-Response/AKA-Reauthentication | |(AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, AT_MAC) | |---------------------------------------------------------->| | (5) EAP-Succes | |<----------------------------------------------------------| Figure 8. EAP-AKA' FS Reauthentication Procedure¶
To update [I-D.ietf-emu-pqc-eapaka] and [I-D.ietf-emu-hybrid-pqc-eapaka] to achieve forward security for TEKs, the above full authentication and fast reauthentication procedures SHALL be run similarly. Particular attention should pay on fragmentation manangement. Neither of EAP-AKA [RFC4187], EAP-AKA′ [RFC5448] [RFC9048] nor EAP-AKA′ FS [RFC9678] defines a native attribute-level fragmentation mechanism. However, the public keys and ciphertexts of PQ KEMs or hybrid KEMs may exceed the EAP MTU (Maximum Transit Unit), fragmentation management MUST be dealt as specified by [I-D.ietf-emu-pqc-eapaka] and [I-D.ietf-emu-hybrid-pqc-eapaka]. The specific attribute-level fragmentation mechanism is called AT_FRAGMENT, specified in Section 7 of [I-D.ietf-emu-pqc-eapaka], to support transport of large attribute values.¶
The format of the AT_SUPPORT_TEKs_FS attribute is defined as below.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_SUPPORT_ | Length = 1 | Reserved |
| TEKs_FS (TBA1)| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. The Format of the AT_SUPPORT_TEKs_FS Attribute
¶
Security considerations given in [RFC9678], [I-D.ietf-emu-pqc-eapaka] and [I-D.ietf-emu-hybrid-pqc-eapaka] all apply to this update for guaranteeing the security of full authentication and fast reauthentication procedures, as well as the forward security of key derivation functions.¶
Focusing on the derivation of TEKs, namely, K_encr' and K_aut', their forward security relies on the security of the followin primtives:¶
Those assumptions are the same as does by each of the above three documents.¶
Returing to the security of using TEKs in full authentication and fast reauthentication procedures, it relies on the security of the followin two primitives:¶
The assumption on the security of these two symmetric primitives is the same as does by EAP-AKA [RFC4187], EAP-AKA′ [RFC5448] [RFC9048] and EAP-AKA′ FS [RFC9678].¶
In addition, this update is secure against potential downgrade attacks that may try to strip the new attribute AT_SUPPORT_TEKs_FS in messages (5) and/or (8), with the aim to force the protocol to fallback to behavior specified in [RFC9678], [I-D.ietf-emu-pqc-eapaka] or [I-D.ietf-emu-hybrid-pqc-eapaka]. The reason is that such man-in-the-middle attacks cannot forge the corresponding MAC codes present in messages (5) and (8), which are shown as the attribute AT_MAC. Naturally, this holds under the assumptions that (a) the symmetric integrity algorithm is secure, (b) the key derivation funtion PRF' is secure, and (c) the corresponding ephemeral key exchange used is secure.¶
In summary, the update speficified in this document does not introduce or rely on any new cryptographic primitive or security assumption. Therefore, this update further offers forward security for the TEKs and their use in fast reauthentication when it applies to EAP-AKA′ FS [RFC9678] or its PQ successors [I-D.ietf-emu-pqc-eapaka] [I-D.ietf-emu-hybrid-pqc-eapaka].¶
One new Attribute Type value (TBA1) from the skippable range is requested from IANA for AT_SUPPORT_TEKs_FS (Section 7), in the "Attribute Types" registry under the "EAP-SIM/AKA/AKA'" group.¶
To be added later.¶