Forward Secure Reauthentication in the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA')

EAP-AKA (Extensible Authentication Protocol method for 3rd Generation Authentication and Key Agreement) is a secure authentication method used for mobile devices connecting to networks (like Wi-Fi) 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 in EAP-AKA. EAP-AKA' (Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) , 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')" specifies the the protocol behavior for both 4G and 5G deployments using EAP-AKA'. For examples, how the Network Name field is constructed in the protocol; how EAP-AKA' use identifiers in 5G; how to define session identifiers and other exported parameters (including the case for fast reauthentication), and how to updates 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)" enhances the forward security for the session keys generated as a part of the authentication run in EAP-AKA', by introducing ephemeral Diffie-Hellman 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 , K_encr, the key for encrypting reauthentication pseudonym idenities, is not forward secure, as it is generated before 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 , reauthentication is much faster and then benefits to 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 (incluidng K_encr) in EAP-AKA' FS. Based on this, it is not feasible to link the executions of reauthentication within the session of a full authentication. When this extension is enabled, the privacy of mobile device users are protected against long-term key compromise. This udapte is applicable and optional to all standards specifed in , , , and . This extension is also applicable and optional to the drafts specified in and , where the ephemeral DH key exchange is replaced by post-quantum (PQ) KEM and hybrid KEMs , respectively.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here. Readers are assumed familiar with the terms in EAP-AKA , EAP-AKA' , and EAP-AKA' FS . The implication of forward security is discussed in Sections 1 and 4.3 of , and the usage of reauthentication is discussed in Section 5 of , and Sections 6.5.4 and 6.5.5 of .

The normal process of EAP-AKA' FS is briefly reviewd in Figure 1, where AD denotes the 3GPP Authentication Database. Details can be found in Section 5 of . | | | | |(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 ). Note that the TEKs, consisting both K_encr and K_aut, are parts 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. 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 info for the peer. And similiarly, they are generated after Step (7) by the peer and used to verify and decrypt ciphtertext sent in Step (5), and used in Step (8) to protect the info for the server. So, the ephemeral SHARED_SECRET is avaialbe 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 . 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 generates a pseudonym and uses K_encr to encrypt it in the optional attribute AT_NEXT_REAUTH_ID. At the same time, the authenticator uses integrity key K_aut to produce a MAC in the atttibute AT_MAC in Step (3). | | (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 Procedure (Section 5.4 of RFC 4187) ]]> As discussed above, K_encr and K_aut will be compromised if the long-term key is leaked. So, in such case, the 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 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. Morever, even without decrypting the reauthentication identities from the AT_NEXT_REAUTH_ID attributes, the attacker can also link two or more runs of reauthentication via using the integrity key K_aut. Namely, the attacker can check the AT_MAC attributes sent by either the authenticator in Step (3) or the peer in Step (4) to be sure that different runs belong to the same peer, if all these AT_MAC attributes are valid with respect to the given 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 a concrete key derivation process given in Figure 4. (EDITOR'S NOTE: Other variants are also available.) In this process, 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. And only K_encr' and K_aut' are used to protect the transmission and usage of reauthenticaton identities in reauthentication procedure in Figure 3. The whole process will be elaborated later.

Security condiderations will be added later.

At the time of writing, there are no IANA considerations that may need to be considered.

To be added later.