Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime

Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime Nokia

Bangalore Karnataka India kondtir@gmail.com

Nokia

London United Kingdom aritra.banerjee@nokia.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 making it quantum-safe using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs). 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. This prevents an attacker who has gained access to the long term key from obtaining session keys established in the past, assuming these have been properly deleted. EAP-AKA' FS mitigates passive attacks (e.g., large scale pervasive monitoring) against future sessions. Nevertheless, EAP-AKA' FS uses traditional algorithms public-key algorithms (e.g., ECDH) which will be broken by a Cryptographically Relevant Quantum Computer (CRQC) using Shor's algorithm. The presence of a CRQC would render state-of-the-art, traditional public-key algorithms deployed today obsolete and insecure, since the assumptions about the intractability of the mathematical problems for these algorithms that offer confident levels of security today no longer apply in the presence of a CRQC. A CRQC could recover the SHARED_SECRET from the ECDHE public keys (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 . Researchers have developed Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) to provide secure key establishment resistant against an adversary with access to a quantum computer. At the time of writing, NIST has standardized three PQC algorithms, with more expected to be standardized in the future (). As these algorithms are secure against both quantum and classical computers, this document proposes a PQ-KEM for achieving perfect forward secrecy in EAP-AKA'. Although the proposed mechanism is applicable to any post-quantum Key Encapsulation Mechanism (PQ-KEM), this document specifies its use with Module-Lattice-based Key Encapsulation Mechanisms (ML-KEMs). ML-KEM provides a one-pass (store-and-forward) cryptographic method for an originator to securely transmit keying material to a recipient using the recipient’s ML-KEM public key. Three parameter sets for ML-KEM are defined in , namely ML-KEM-512, ML-KEM-768, and ML-KEM-1024, listed in order of increasing security strength and decreasing performance.

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 . The following terms are repeately used in this specification:

KEM: Key Encapsulation Mechanism
PQ-KEM: Post-Quantum Key Encapsulation Mechanism
CEK: Content Encryption Key
ML-KEM: Module-Lattice-based Key Encapsulation Mechanism

For the purposes of this document, it is helpful to be able to divide cryptographic algorithms into two classes: "Asymmetric Traditional Algorithm": An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms or elliptic curve discrete logarithms, or related mathematical problems. "Post-Quantum Algorithm": An asymmetric cryptographic algorithm that is believed to be secure against attacks using quantum computers as well as classical computers. Post-quantum algorithms can also be called quantum-resistant or quantum-safe algorithms. Examples of Post-Quantum Algorithm include ML-KEM.

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 draft , the server has the EAP identity of the peer. The server asks the 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 might be ignored if USIM doesn’t support the Forward Secrecy extension. The peer checks if it wants to have a Forward extension in EAP AKA'. If yes, then it will eventually respond with AT_PUB_ECDHE and 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.

Key Encapsulation Mechanisms For the purposes of this document, we consider a Key Encapsulation Mechanism (KEM) to be any asymmetric cryptographic scheme comprised of algorithms satisfying the following interfaces .

def kemKeyGen() -> (pk, sk)
def kemEncaps(pk) -> (ct, ss)
def kemDecaps(ct, sk) -> ss

where pk is public key, sk is secret key, ct is the ciphertext representing an encapsulated key, and ss is shared secret. KEMs are typically used in cases where two parties, hereby refereed to as the "encapsulater" and the "decapsulater", wish to establish a shared secret via public key cryptography, where the decapsulater has an asymmetric key pair and has previously shared the public key with the encapsulater.

Design Rationales It is essential to note that in the PQ-KEM, one needs to apply Fujisaki-Okamoto transform or its variant on the PQC KEM part to ensure that the overall scheme is IND-CCA2 secure, as mentioned in . The FO transform is performed using the KDF such that the PQC KEM shared secret achieved is IND-CCA2 secure. Note that during the transition from traditional to post-quantum algorithms, there may be a desire or a requirement for protocols that incorporate both types of algorithms until the post-quantum algorithms are fully trusted. HPKE is an KEM that can be extended to support hybrid post-quantum KEMs and the specifications for the use of HPKE with EAP-AKA prime is described in .

PQC KEM Enhancements by Design We suggest the following changes and enhancements:

A new attribute, AT_PUB_KEM, is defined to carry the PQC KEM public key from the EAP server.
A new attribute, AT_KEM_CT, is defined to carry the ciphertext (ct) generated by the PQC KEM Encapsulation function from the EAP peer.
The AT_KDF_FS attribute is updated to indicate the PQC KEM for generating the Master Key MK_PQ_SHARED_SECRET.
Multiple AT_KDF_FS attributes are included in the EAP-Request to handle the EAP peer not supporting PQC KEM.
The PQC KEM can be included first in the AT_KDF_FS attribute in the EAP-Request to indicate a higher priority for its use compared to the traditional key derivation functions.
EAP-AKA and EAP-AKA′ FS do not define a native attribute-level fragmentation mechanism. As PQC public keys and ciphertexts may exceed the EAP MTU, this specification defines an explicit attribute-level fragmentation mechanism (AT_FRAGMENT) to support transport of large attribute values.

Message Fragmentation and Reassembly EAP-AKA and EAP-AKA' FS do not natively define fragmentation. This specification therefore defines attribute-level fragmentation for attributes whose total length may exceed the EAP MTU. This specification defines an attribute-level fragmentation mechanism similar to the lock-step acknowledgment model used by EAP-TLS . Fragmentation applies to the entire attribute, including the attribute header and value. Only one fragmented attribute exchange (i.e., one fragmented attribute transmission in progress in either direction) MUST be active at any time.

Fragmentation Attribute When an attribute is fragmented, each fragment carries a Fragmentation attribute. The Fragment Data field carries a contiguous portion of the original attribute, treated as an opaque sequence of octets. The first fragment MUST begin with the attribute Type and Length fields. Subsequent fragments carry the next contiguous octets of the attribute. The receiver MUST reconstruct the original attribute by concatenating the Fragment Data fields, in the order received, excluding any per-fragment alignment padding. The reassembled attribute MUST be bitwise identical to the original, unfragmented attribute and MUST NOT be processed until reassembly has completed. The Fragmentation attribute has the following format: 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_FRAGMENT | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Total Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Fragment Data (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: A 2-octet unsigned integer indicating the length of this AT_FRAGMENT attribute in multiples of 4 octets, including the Type, Reserved, Length, Flags, Total Attribute Length, Fragment Data, and any alignment padding. The total length of the attribute in octets is obtained by multiplying this field by 4. Each AT_FRAGMENT attribute MUST have a Length that is a multiple of 4 octets. Flags (1 octet): The Flags field contains the following bits: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S|M| Reserved | +-+-+-+-+-+-+-+-+

S (First Fragment) Indicates that this is the first fragment of a fragmented attribute. This bit MUST be set on the first fragment and MUST NOT be set on subsequent fragments.
M (More Fragments) Indicates that additional fragments follow.
This bit MUST be set on all fragments except the last.
Reserved
MUST be set to zero on transmission and ignored on receipt.

Total Attribute Length (2 octets) The Total Attribute Length field specifies the total length, in octets, of the unfragmented attribute, including its Type, Length, and Value fields. It is encoded as an unsigned 16-bit integer in network byte order. This field MUST be present in all fragments belonging to the same fragmented attribute. In fragments other than the first, the value of Total Attribute Length MUST be identical to that of the first fragment. If a mismatch is detected, the receiver MUST treat this as a protocol error and abort the authentication exchange.

Fragmentation Procedure

When an EAP peer receives an EAP-Request containing an attribute fragment with the M bit set, it MUST respond with an EAP-Response of the same EAP type containing no attributes. This response serves as a fragment acknowledgment.
When an EAP server receives an EAP-Response containing an attribute fragment with the M bit set, it MUST respond with an EAP-Request of the same EAP type containing no attributes. This request serves as a fragment acknowledgment.
The sender MUST NOT transmit the next fragment until the corresponding acknowledgment has been received.

Use of the EAP Identifier The EAP Identifier field is used to correlate fragments and acknowledgments:

The Identifier in an EAP-Response MUST match the Identifier of the immediately preceding EAP-Request.
Fragment acknowledgments MUST echo the Identifier of the fragment being acknowledged.
Retransmitted fragments MUST reuse the same Identifier value as the original transmission.
For fragmented exchanges initiated by the EAP server, the Identifier in each EAP-Request carrying a fragment MUST be incremented relative to the previous EAP-Request.

Reassembly The receiver MUST reassemble attribute fragments strictly in the order received and MUST NOT process the fragmented attribute until all fragments have been successfully received and validated. The final fragment is identified by the M bit being cleared (M = 0). The receiver MUST acknowledge each fragment, including the final fragment, using the lock-step procedure defined for fragmentation. The sender MUST wait for acknowledgment of the final fragment before considering the fragmented attribute exchange complete. During the fragmentation phase (i.e., while the M bit is set in AT_FRAGMENT), the EAP peer MUST respond to each EAP-Request/AKA'-Challenge fragment with an EAP-Response/AKA'-Challenge message containing a zero-length attribute payload. These responses serve solely as transport-level acknowledgments and MUST NOT trigger any AKA' cryptographic processing. The EAP peer MUST NOT initiate USIM processing (e.g., passing RAND and AUTN to the USIM) while attribute fragmentation is in progress. USIM processing has to occur only after the final fragment (M = 0) has been received and the complete attribute set has been successfully reassembled and validated. At that point, the peer will invoke the AKA' algorithm using the RAND and AUTN values contained in the reassembled message. If a fragment is lost or corrupted, normal EAP retransmission procedures apply. Retransmitted fragments MUST use the same EAP Identifier value as the original transmission. The receiver MUST verify that:

The first fragment has the S bit set and subsequent fragments do not; and
The cumulative length of all received Fragment Data fields equals the Total Attribute Length.

Any inconsistency in fragmentation state (including unexpected S bit usage, receipt of a new initial fragment while reassembly is in progress, length mismatch, or malformed sequencing) MUST be treated as a protocol error, and the authentication exchange MUST be aborted. If reassembly cannot be successfully completed after a bounded number of retransmissions, the authentication exchange MUST be aborted. Fragmentation does not modify the AT_MAC calculation rules defined in . AT_MAC is calculated over the EAP packet exactly as transmitted on the wire, including any AT_FRAGMENT attributes. Processing of data contained in reassembled fragmented attributes MUST occur only after successful AT_MAC verification. Fragmentation therefore does not alter the integrity protection scope of the EAP packet.

Applicability This fragmentation mechanism applies to any attribute within this EAP method whose encoded length exceeds the EAP MTU. (e.g., AT_PUB_KEM, AT_KEM_CT, or AT_IDENTITY carrying a large SUCI). Attributes that fit within a single EAP packet MUST be sent unfragmented. The following diagram details how the fragmentation works for both request and response: Peer Server | | | <- EAP-Request / Identity (Id=1) | | | | EAP-Response / Identity (Id=1) -> | | | | <- EAP-Request / AKA'-Challenge (Id=2) | | (unfragmented attributes) | | | | EAP-Response / AKA'-Challenge (Id=2) -> | | | |================ Server-Initiated Fragmentation ===============| | | | <- EAP-Request / AKA'-Challenge (Id=3) | | (Fragment 1: S=1, M=1) | | | | EAP-Response / AKA'-Challenge (Id=3) -> | | (ACK, no attributes) | | | | <- EAP-Request / AKA'-Challenge (Id=4) | | (Fragment 2: M=1) | | | | EAP-Response / AKA'-Challenge (Id=4) -> | | (ACK, no attributes) | | | | <- EAP-Request / AKA'-Challenge (Id=5) | | (Fragment 3: M=0, last fragment) | | | | EAP-Response / AKA'-Challenge (Id=5) -> | | (ACK, no attributes — final fragment) | | | |================ Peer-Initiated Fragmentation =================| | | | <- EAP-Request / Identity (Id=6) | | | | EAP-Response / AKA'-Challenge (Id=6) -> | | (Fragment 1: S=1, M=1) | | | | <- EAP-Request / AKA'-Challenge (Id=7) | | (ACK, no attributes) | | | | EAP-Response / AKA'-Challenge (Id=7) -> | | (Fragment 2: M=0, last fragment) | | | | <- EAP-Request / AKA'-Challenge (Id=8) | | (ACK, no attributes — final fragment)| | | | <- EAP-Success (Id=9) | | | The term “ACK” in the above figure is used for illustrative purpose to describe an EAP-Request or EAP-Response of the same EAP method type that contains no attributes and is sent solely to acknowledge receipt of a fragment.

Protocol Construction The above section outlines how the fragmentation works. This section defines the construction for PQC KEM in EAP-AKA' FS and the other params that are sent via EAP Req/Resp AKA'-Challenge.

Key Steps in protocol construction We outline the following key steps in the protocol:

Server generates the PQC KEM public key(pk), private key (sk) pair. The server will generate the Authentication Vector (AV). The server PQC KEM key pair is derived as:

The server will store the expected response XRES, the PQC KEM private key sk. The server will forward the authenticator part (AUTH) of the AV to peer along with pk.
The USIM will validate the AUTN received, also verifies the MAC. After the verification is successful and if the peer also supports the Forward secrecy, peer will invoke kemEncaps using pk:

"ct" is the ciphertext from kemEncaps whereas "ss" is shared secret key.

The peer will send the Authentication result RES and ct to the server.
The server will verify the RES with XRES. The server will use the ct and PQC KEM private key sk to generate shared secret:

The generated ss from kemDecaps is the shared secret key derived from kemEncaps. The peer and the server first generate the MK_PQ_SHARED_SECRET and subsequently generate MSK, EMSK as shown below: where, pk is PQC KEM public key from the EAP server, ct is the ciphertext from the kemEncaps and it is triggered by the EAP peer only. The pseudo-random function (PRF') binds the shared secret to the ciphertext (ct), achieving MAL-BIND-K-CT. The ML-KEM already achieves MAL-BIND-K-PK as the hash of the PQC KEM public key is an input to the computation of the shared secret (ss) (line 2 of ML-KEM.Encaps algorithm in ). These computational binding properties for KEMs are defined in .

Extensions to EAP-AKA' FS

AT_PUB_KEM The format of the AT_PUB_KEM attribute is shown below. The fields are as follows: AT_PUB_KEM: This is set to TBA1 BY IANA. Reserved: A 1-byte field reserved for future use. Including this field ensures that the fixed header (Type, Reserved, Length) is 4 bytes long, maintaining 4-byte alignment for the following Value field. The Reserved field MUST be set to 0 on transmission and ignored on receipt. Length: A 2-byte unsigned integer indicating the length of this attribute in multiples of 4 octets, including the Type, Reserved, Length, and Value fields, as well as any padding. The total length of the attribute in octets is obtained by multiplying this field by 4. This differs from the attribute format used in EAP-AKA , where the Length field is 1 byte.The modification is necessary because PQC KEM public keys, such as those defined in ML-KEM-1024, will be 1568 bytes, which would exceed the 1024-byte limit imposed by the original EAP-AKA format. Value: Because the length of the attribute must be a multiple of 4 bytes, the sender pads the Value field with zero bytes when necessary. To retain the security of the keys, the sender SHALL generate a fresh value for each run of the protocol.

AT_KEM_CT The format of the AT_KEM_CT attribute is shown below. The fields are as follows: AT_KEM_CT: This is set to TBA2 BY IANA. Reserved: A 1-byte field reserved for future use. The Reserved field MUST be set to 0 on transmission and ignored on receipt. Length: A 2-byte unsigned integer indicating the length of this attribute in multiples of 4 octets, including the Type, Reserved, Length, and Value fields, as well as any padding. The total length of the attribute in octets is obtained by multiplying this field by 4. This differs from the format used in EAP-AKA , where the Length field is 1 byte. The change is necessary because ciphertexts produced by PQC KEM algorithms,such as 1568 bytes in ML-KEM-1024 will exceed the 1024 byte limit imposed by the original EAP-AKA attribute format. Value: Because the length of the attribute must be a multiple of 4 bytes, the sender pads the Value field with zero bytes when necessary. To retain the security of the keys, the sender SHALL generate a fresh value for each run of the protocol.

Capability Negotiation Support for PQC KEM is negotiated using the AT_KDF_FS attribute. AT_PUB_KEM and AT_KEM_CT use an extended attribute header format that is incompatible with legacy EAP-AKA and EAP-AKA' implementations. Therefore, these attributes MUST NOT be sent unless a mutually supported PQC KEM has been successfully negotiated via AT_KDF_FS.

ML-KEM ML-KEM offers several parameter sets with varying levels of security and performance trade-offs. This document specifies the use of the ML-KEM algorithm at three security levels: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. The main security property for KEMs standardized in the NIST Post-Quantum Cryptography Standardization Project is indistinguishability under adaptive chosen ciphertext attacks (IND-CCA2) (see Section 10.2 of ). The public/private key sizes, ciphertext key size, and PQ security levels of ML-KEM are detailed in Section 12 of .

Security Considerations The security of the PQ-KEM algorithm depends on a high-quality pseudo-random number generator. For further discussion on random number generation, see . In general, good cryptographic practice dictates that a given PQ-KEM key pair should be used in only one EAP session. This practice mitigates the risk that compromise of one EAP session will not compromise the security of another EAP session and is essential for maintaining forward security. Implementations MUST enforce a locally configured maximum Total Attribute Length for fragmented attributes. If the Total Attribute Length exceeds this limit, the attribute MUST be rejected and the authentication exchange aborted. This limit has to be chosen to mitigate DoS attack with support for large PQC key material.

Selecting ML-KEM Variants ML-KEM is believed to be IND-CCA2 secure based on multiple analyses. The ML-KEM variant and its underlying components should be selected consistently with the desired security level. For further clarity on the sizes and security levels of ML-KEM variants, please refer to the tables in Sections 12 and 13 of .

IANA Considerations Three new Attribute Type values (TBA1, TBA2, and TBA3) from the skippable range are requested from IANA for AT_PUB_KEM (), AT_KEM_CT (), and AT_FRAGMENT () in the "Attribute Types" registry under the "EAP-SIM/AKA/AKA'" group. IANA is requested to update the registry "EAP-AKA' AT_KDF_FS Key Derivation Function Values" with the PQC KEM algorithm entries:

References Normative References 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. Extensible Authentication Protocol (EAP) This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK] The EAP-TLS Authentication Protocol The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK] PPP EAP TLS Authentication Protocol The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community. 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. 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. Informative References PQC - API notes Secure Integration of Asymmetric and Symmetric Encryption Schemes A Modular Analysis of the Fujisaki-Okamoto Transformation FIPS-203: Module-Lattice-based Key-Encapsulation Mechanism Standard Keeping Up with the KEMs: Stronger Security Notions for KEMs and automated analysis of KEM-based protocols NIST Releases First 3 Finalized Post-Quantum Encryption Standards n.d. Terminology for Post-Quantum Traditional Hybrid Schemes UK National Cyber Security Centre UK National Cyber Security Centre Naval Postgraduate School 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. Hybrid key exchange in TLS 1.3 University of Waterloo Cisco Systems University of Haifa and Meta Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way is found to defeat the encryption for all but one of the component algorithms. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography Nokia Nokia Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [RFC9678], providing updates to [RFC9048] 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 leveraging PQ/T Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology] algorithms to make it quantum-safe. Post-Quantum Cryptography for Engineers Nokia Nokia Nokia DigiCert Entrust Limited 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), detailing 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. 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.

Acknowledgements This draft leverages text from .