Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography

Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography Nokia

London United Kingdom aritra.banerjee@nokia.com

Nokia

Bangalore Karnataka India kondtir@gmail.com

Security EMU PQC EAP-AKA' Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in , providing updates to with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by using Post-Quantum/Traditional (PQ/T) hybrid Key Encapsulation Mechanisms (KEMs) to make it quantum-safe. About This Document Status information for this document may be found at . Discussion of this document takes place on the emu Working Group mailing list (), which is archived at . Subscribe at .

Introduction Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) defined in updates the improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') specified in , with an optional extension providing ephemeral key exchange. The ephemeral key exchange prevents an attacker who subsequently obtains the long-term key from recovering session keys established in previous EAP-AKA' FS authentication runs, provided that the corresponding ephemeral secrets and derived session keys have been deleted. EAP-AKA' FS mitigates passive attacks (e.g., large scale pervasive monitoring) against future sessions. Nevertheless, EAP-AKA' FS uses traditional public-key algorithms (e.g., ECDH) which will be broken by a Cryptographically Relevant Quantum Computer (CRQC) using Shor's algorithm. A CRQC would render commonly deployed traditional public-key algorithms based on factoring or discrete-logarithm problems insecure. The computational assumptions underlying these algorithms would no longer provide the intended security against an adversary with a sufficiently capable quantum computer. In particular, a CRQC could recover the ECDHE SHARED_SECRET from the exchanged public keys described in Section 6.3 of . If the adversary has also obtained knowledge of the long-term key, it could then compute CK', IK', and the SHARED_SECRET, and any derived output keys. This means that the CRQC would disable the forward security capability provided by . The migration to PQC is unique in the history of modern digital cryptography in that neither the traditional algorithms nor the post-quantum algorithms are fully trusted to protect data for the required data lifetimes. The post-quantum algorithms face uncertainty about the underlying mathematics, compliance issues, unknown vulnerabilities, hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs. During the transition from traditional to post-quantum algorithms, there is a desire or a requirement for protocols that use both algorithm types. This document specifies the use of the PQ/T hybrid KEMs defined in Section 4 of with EAP-AKA' FS. Only the KEM functions GenerateKeyPair(), Encap(), and Decap() are used; Hybrid Public Key Encryption (HPKE) encryption is not used. specifies the use of ML-KEM with EAP-AKA' FS. This document uses its fragmentation mechanism and the same negotiation approach.

Conventions and Definitions 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.

Terminology This document makes use of the terms defined in . For the purposes of this document, it is helpful to be able to divide cryptographic algorithms into two classes: "Traditional Algorithm": An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms or elliptic curve discrete logarithms. An example of a traditional key exchange algorithm is Elliptic Curve Diffie-Hellman (ECDH). "Post-Quantum Algorithm": An asymmetric cryptographic algorithm that is believed to be secure against attacks using quantum computers as well as classical computers. An example of a post-quantum KEM is ML-KEM . "Hybrid" key exchange, in this context, means the use of two key exchange algorithms based on different cryptographic assumptions, e.g., one traditional algorithm and one Post-Quantum algorithm, with the purpose of the final shared secret key being secure as long as at least one of the component key exchange algorithms remains unbroken. It is referred to as PQ/T Hybrid Scheme in . PQ/T Hybrid Key Encapsulation Mechanism: A Key Encapsulation mechanism (KEM) made up of two or more component KEM algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.

Background on EAP-AKA' with perfect forward secrecy In EAP-AKA', the authentication vector (AV) contains a random part RAND, an authenticator part AUTN used for authenticating the network to the USIM, an expected result part XRES, a 128-bit session key for integrity check IK, and a 128-bit session key for encryption CK. As described in , the server has the EAP identity of the peer. The server asks the Authentication Database (AD) to run AKA algorithm to generate RAND, AUTN, XRES, CK and IK. Further it also derives CK' and IK' keys which are tied to a particular network name. The server now generates the ephemeral key pair and sends the public key of that key pair and the first EAP method message to the peer. In this EAP message, AT_PUB_ECDHE (carries public key) and the AT_KDF_FS (carries other FS related parameters). Both of these are ignored by a peer that does not support the Forward Secrecy extension. The peer determines whether it supports and selects the EAP-AKA' FS extension offered by the server. If yes, then it will respond with AT_PUB_ECDHE and AT_MAC. If not, it will ignore AT_PUB_ECDHE. If the peer wants to participate in FS extension, it will then generate its ECDH key pair, calculate a shared key based on its private key and server public key. The server will receive the RES from peer and AT_PUB_ECDHE. The shared key will be generated both in the peer and the server with key pairs exchanged, and later master key is also generated.

Hybrid Enhancements by Design This specification defines the following extensions to EAP-AKA' FS:

A new attribute, AT_PUB_HYBRID, carries the hybrid KEM encapsulation key from the EAP server and the hybrid KEM ciphertext from the EAP peer.
New AT_KDF_FS values identify the hybrid KEMs () used to derive the Hybrid Master Key MK_HYBRID.
The server lists the hybrid KEM values after an ECDHE value in AT_KDF_FS and sends AT_PUB_HYBRID only after the peer selects a hybrid KEM ().

Message Fragmentation and Reassembly For all hybrid KEMs registered in this document, AT_PUB_HYBRID exceeds the 1020-octet limit for EAP-AKA extensions in Section 8 of . AT_PUB_HYBRID is therefore fragmented using AT_FRAGMENT, as specified in . AT_FRAGMENT MUST NOT be sent in an AKA'-Challenge message until the peer has selected a hybrid KEM (). AKA'-Identity messages are not protected by AT_MAC. If AT_FRAGMENT is used in any AKA'-Identity message, AT_CHECKCODE MUST be included in the EAP-Request/AKA'-Challenge carrying AT_PUB_HYBRID and in the EAP-Response/AKA'-Challenge carrying AT_RES. Section 10.13 of requires this because AT_FRAGMENT is an attribute not defined in .

Capability Negotiation AT_PUB_HYBRID and AT_FRAGMENT use a 2-octet Length field. Implementations that do not support this document parse a 1-octet Length field, as specified in , and reject a message containing these attributes, even though their Type values are in the skippable range. These attributes are therefore sent only after the peer has selected a hybrid KEM, using the AT_KDF_FS change procedure in Section 6.2 of :

In the first EAP-Request/AKA'-Challenge, the server lists an ECDHE value from as the first AT_KDF_FS attribute, followed by the hybrid KEM values, and includes AT_PUB_ECDHE. The server MUST NOT include AT_PUB_HYBRID or AT_FRAGMENT in this message.
A peer that does not support ignores AT_KDF_FS and AT_PUB_ECDHE and continues as specified in . A peer that supports but not this document continues as specified in .
A peer that supports this document and one of the offered hybrid KEMs MUST request it. Its EAP-Response/AKA'-Challenge contains only AT_KDF_FS with the selected value. The peer does not run the AKA algorithm on this message.
The server re-sends the EAP-Request/AKA'-Challenge with the selected value as the first AT_KDF_FS attribute, followed by the original list, and with AT_PUB_HYBRID instead of AT_PUB_ECDHE. The peer verifies the AT_KDF_FS list as specified in Section 6.2 of .

Either side MAY require a hybrid KEM by local policy. A server that requires a hybrid KEM and finds that the peer did not select one MUST behave as if authentication failed. A peer that requires a hybrid KEM and finds no hybrid KEM value in AT_KDF_FS MUST behave as if AUTN were incorrect. This follows Section 6.5.4 of .

Protocol Construction This section defines the construction for hybrid key exchange in EAP-AKA' FS. Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography.

Key Steps in Protocol Construction

After the peer selects a hybrid KEM (), the server generates an ephemeral key pair for that hybrid KEM: (skR, pkR) = GenerateKeyPair(), as defined in Section 4 of .
The server associates XRES and skR with the current EAP session and sends pkR in AT_PUB_HYBRID.
The peer runs the AKA algorithm, verifies AT_MAC, and computes (ss, enc) = Encap(pkR). It sends RES in AT_RES and enc in AT_PUB_HYBRID.
The server verifies RES and computes ss = Decap(enc, skR). If Decap() fails, the server MUST behave as if authentication failed.

The peer and the server derive the keys as follows: Length(X) is the length of X in octets, encoded as a 2-octet unsigned integer in network byte order. The label "EAP-AKA' FS Hybrid" separates MK_HYBRID from MK_ECDHE (Section 6.3 of ). For each authentication exchange, the server MUST generate a new hybrid KEM key pair. Key pairs MUST NOT be reused across authentication exchanges.

Extensions to EAP-AKA' FS

AT_PUB_HYBRID The format of the AT_PUB_HYBRID attribute is shown below. AT_PUB_HYBRID: Set to TBA1 by IANA. Reserved: 1 octet. MUST be set to 0 on transmission and ignored on receipt. Length: 2 octets. The length of the attribute in multiples of 4 octets, including the Type, Reserved, Length, and Value fields and any padding. This differs from , where the Length field is 1 octet, because hybrid KEM encapsulation keys and ciphertexts exceed the 1020-octet maximum of a 1-octet Length field. Value: In the EAP-Request, the hybrid KEM encapsulation key pkR. In the EAP-Response, the hybrid KEM ciphertext enc. Both are output by the hybrid KEM as defined in Section 4 of and are opaque to EAP-AKA'. The sender pads the Value field with zero octets to a multiple of 4 octets. The receiver removes the padding using the fixed encapsulation key or ciphertext length of the selected hybrid KEM.

Security Considerations The IND-CCA security of the hybrid KEMs is discussed in Section 7 of . Security levels and sizes of ML-KEM are discussed in . For the security properties of EAP-AKA' FS, see Section 7 of . Implementations MUST generate hybrid KEM key pairs using a cryptographically secure random number generator (). The server MUST delete skR, and both sides MUST delete ss, once MK_HYBRID has been derived. A retained skR allows anyone who obtains it, together with the long-term key, to recover the session keys of the corresponding recorded exchange. AT_MAC protects the AT_KDF_FS offer and the peer's selection, because the final EAP-Request/AKA'-Challenge carries both the selected value and the original list (Section 6.2 of ). An attacker that holds the long-term key can still remove the hybrid KEM offer. Deployments that need protection against this MUST require a hybrid KEM by local policy.

IANA Considerations

Attribute Type IANA is requested to assign one new value in the "Attribute Types (Skippable Attributes 128-255)" registry under the "EAP-AKA and EAP-SIM Parameters" group:

AT_KDF_FS Key Derivation Function Values IANA is requested to add the following entries to the "EAP-AKA' AT_KDF_FS Key Derivation Function Values" registry under the "EAP-AKA and EAP-SIM Parameters" group: The hybrid KEMs are defined in Section 4 of .

References Normative References Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA) This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card. EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. This memo provides information for the Internet community. Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') The 3GPP mobile network Authentication and Key Agreement (AKA) is an authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC 5448 (EAP-AKA') was an improved version of EAP-AKA. This document is the most recent specification of EAP-AKA', including, for instance, details about and references related to operating EAP-AKA' in 5G networks. EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' also updates the algorithm used in hash functions, as it employs SHA-256 / HMAC-SHA-256 instead of SHA-1 / HMAC-SHA-1, which is used in EAP-AKA. This version of the EAP-AKA' specification defines the protocol behavior for both 4G and 5G deployments, whereas the previous version defined protocol behavior for 4G deployments only. While EAP-AKA' as defined in RFC 5448 is not obsolete, this document defines the most recent and fully backwards-compatible specification of EAP-AKA'. This document updates both RFCs 4187 and 5448. Forward Secrecy Extension to the Improved Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) This document updates RFC 9048, "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')", and its predecessor RFC 5448 with an optional extension providing ephemeral key exchange. The extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated, provides forward secrecy for the session keys generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term key from obtaining session keys established in the past. In addition, EAP-AKA' FS mitigates passive attacks (e.g., large-scale pervasive monitoring) against future sessions. This forces attackers to use active attacks instead. Terminology for Post-Quantum Traditional Hybrid Schemes One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE Cisco Selkie Cryptography Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post- quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attacks by a quantum computer. Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime Nokia Nokia Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [RFC9678]. It updates [RFC9048] with an optional extension that provides ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm. This extension enables perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by making it quantum-safe using Post-Quantum Key Encapsulation Mechanisms (PQ KEMs). Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Randomness Requirements for Security Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Post-Quantum Cryptography for Engineers The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), and it details the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. FIPS-203: Module-Lattice-based Key-Encapsulation Mechanism Standard

Acknowledgements This draft leverages text from . The authors thank Wang Guilin, John Mattsson, Heikki Vatiainen and Alan DeKok for their contributions to this specification.