| Internet-Draft | PQ KEMs in EAP-AKA prime | October 2026 |
| Reddy & Banerjee | Expires 29 April 2027 | [Page] |
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).¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-emu-pqc-eapaka/.¶
Discussion of this document takes place on the emu Working Group mailing list (mailto:emu@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/emu/. Subscribe at https://www.ietf.org/mailman/listinfo/emu/.¶
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 29 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.¶
The Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') is specified in [RFC9048]. Forward Secrecy for EAP-AKA' (EAP-AKA' FS), defined in [RFC9678], adds an optional ephemeral key exchange. This prevents an attacker who subsequently obtains the long-term key from deriving session keys established in previous protocol runs from previously recorded protocol messages. EAP-AKA' FS also mitigates passive attacks, such as large-scale pervasive monitoring, against future sessions after compromise of the long-term key. An adversary that has obtained the long-term key may still attempt active attacks by participating in or modifying subsequent protocol exchanges.¶
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. 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 [RFC9678]). 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 [RFC9678].¶
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.¶
NIST has standardized PQC algorithms, with more expected to be standardized in the future ([NISTFINAL]). As these algorithms are designed to provide security against both classical and quantum adversaries, this document specifies the use of a PQ KEM instead of ECDHE for establishing the additional shared secret used to provide post-quantum forward secrecy in EAP-AKA'.¶
The protocol construction can be used with other post-quantum Key Encapsulation Mechanisms (PQ KEMs). However, the public key and ciphertext must each fit within 65,535 octets, which is the maximum attribute size supported by the fragmentation mechanism. This excludes PQ KEMs such as Classic McEliece. This document specifies its use with ML-KEM. 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 [FIPS203], namely ML-KEM-512, ML-KEM-768, and ML-KEM-1024, listed in order of increasing security strength and decreasing performance.¶
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.¶
This document makes use of the terms defined in [RFC9794]. The following terms are repeatedly used in this specification:¶
KEM: Key Encapsulation Mechanism¶
PQ KEM: Post-Quantum Key Encapsulation Mechanism¶
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:¶
"Traditional asymmetric cryptographic algorithm": An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms or elliptic curve discrete logarithms, or related mathematical problems.¶
"Post-quantum asymmetric cryptographic 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.¶
For brevity, this document may use "traditional algorithm" and "post-quantum algorithm", respectively, when the context is unambiguous.¶
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 [RFC9678], 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 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.¶
MK_ECDHE = PRF'(IK'| CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)¶
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 [PQCAPI].¶
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 referred to as the "encapsulator" and the "decapsulator", wish to establish a shared secret via public key cryptography, where the decapsulator has an asymmetric key pair and has previously shared the public key with the encapsulator.¶
The PQ KEM used in this document MUST be IND-CCA2 secure (As discussed in Section 9.2.1 in [RFC9958]).¶
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 can be extended to support hybrid post-quantum KEMs and the specifications for the use of HPKE with EAP-AKA' are described in [I-D.draft-ietf-emu-hybrid-pqc-eapaka].¶
This document specifies the following changes and enhancements to enable the use of PQ KEMs in EAP-AKA':¶
A new attribute, AT_PUB_KEM, is defined to carry the PQ KEM public key from the EAP server.¶
A new attribute, AT_KEM_CT, is defined to carry the ciphertext (ct) generated by the PQ KEM Encapsulation function from the EAP peer.¶
The AT_KDF_FS attribute is updated to indicate the PQ 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 PQ KEM.¶
The PQ 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.¶
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 [RFC2716]. 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.¶
When an attribute is fragmented, the sender divides the unfragmented attribute into two or more fragments. Each fragment contains a consecutive, non-overlapping sequence of octets from the original attribute. The first fragment contains the first octets of the attribute and MUST begin with the attribute Type and Length fields. Each subsequent fragment contains the next sequence of octets from the original attribute.¶
The receiver reconstructs the original attribute by concatenating the Fragment Data fields from all fragments in the order received, excluding any per-fragment alignment padding. The reassembled attribute MUST NOT be processed until reassembly has completed and its length equals Total Attribute Length.¶
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 AT_FRAGMENT 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, Reserved, Length, Value fields, and any padding. 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. The value of Total Attribute Length MUST be identical in all fragments. If the Total Attribute Length value differs across fragments, does not correspond to the length indicated by the Length field of the attribute being fragmented (e.g., AT_PUB_KEM), or exceeds a locally configured limit, the receiver MUST treat this as a protocol error and abort the authentication exchange.¶
Note that Length and Total Attribute Length use different units. Length is encoded in units of four octets following EAP-AKA conventions, whereas Total Attribute Length is encoded directly in octets.¶
Total Attribute Length MUST be at least large enough to contain the minimal header of the fragmented attribute. Total Attribute Length MUST NOT exceed the locally configured maximum fragment reassembly size.¶
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. This EAP-Response MUST NOT contain any attributes and 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. This EAP-Request MUST NOT contain any attributes and serves as a fragment acknowledgment.¶
The sender MUST NOT transmit the next fragment until the corresponding acknowledgment has been received.¶
The EAP Identifier field is used to correlate fragments and acknowledgments, as specified in Section 4.1 of [RFC3748]:¶
The Identifier in an EAP-Response MUST match the Identifier of the EAP-Request it responds to (Section 4.1 of [RFC3748]).¶
Fragment acknowledgments sent by the EAP peer MUST echo the Identifier of the fragment being acknowledged (Section 4.1 of [RFC3748]).¶
Retransmitted fragments MUST reuse the same Identifier value as the original transmission (Sections 4.1 and 4.3 of [RFC3748]).¶
Each new EAP-Request carrying a fragment or a fragment acknowledgment MUST use a new Identifier value (Section 4.1 of [RFC3748]).¶
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 or M 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 [RFC9048]. For a fragmented message, AT_MAC is carried only in the packet containing the final fragment and is calculated over all packets carrying fragments of that message, concatenated in transmission order, 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.¶
Fragment transmission follows a lock-step request/response model. The sender MUST NOT transmit fragment N+1 until the EAP exchange acknowledging fragment N has completed. Consequently, at most one unacknowledged fragment exists in a fragmented attribute exchange at any time.¶
Explicit fragment sequence numbers are therefore not required. The receiver determines fragment ordering from the current reassembly state and the EAP Request/Response exchange. Loss of a fragment or its acknowledgment is handled using the EAP retransmission procedures defined in [RFC3748].¶
This specification intentionally does not support pipelining multiple fragments or cumulative acknowledgments. Such mechanisms would require additional sequencing, buffering, loss-recovery, and flow-control procedures and would introduce an additional transport mechanism within EAP. The lock-step mechanism instead follows the EAP Request/Response model and limits the amount of unacknowledged fragmented data maintained by either endpoint.¶
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.¶
The above section outlines how the fragmentation works. This section defines the construction for PQ KEM in EAP-AKA' FS and the other params that are sent via EAP Req/Resp AKA'-Challenge.¶
USIM Peer Server AD | | | | | | EAP-Req/Identity | | | |<---------------------------+ | | | | | | | EAP-Resp/Identity | | | | (Privacy-Friendly) | | | +--------------------------->| | | +-------+----------------------------+----------------+--+ | | Server now has an identity for the peer. The server | | | then asks the help of AD to run AKA algorithms, | | | generating RAND, AUTN, XRES, CK, IK. Typically, the | | | AD performs the first part of key derivations so that | | | the authentication server gets the CK' and IK' keys | | | already tied to a particular network name. | | +-------+----------------------------+----------------+--+ | | | | | | | ID, key deriv. | | | | function, | | | | network name | | | +--------------->| | | | | | | | RAND, AUTN, | | | | XRES, CK', IK' | | | |<---------------+ | +-------+----------------------------+----------------+--+ | | Server now has the needed authentication vector. It | | | generates a PQ KEM key pair, sends the public key | | | of that key pair and the first EAP method message | | | to the peer. In the message the AT_PUB_KEM attribute | | | carries the PQ KEM public key and the AT_KDF_FS | | | attribute carries PQ KEM algorithm. Both of | | | these are skippable attributes that can be ignored | | | if the peer does not support this extension. | | +-------+----------------------------+----------------+--+ | | | | | | EAP-Req/AKA'-Challenge, | | | | AT_RAND, AT_AUTN, AT_KDF, | | | | AT_KDF_FS, AT_KDF_INPUT, | | | | AT_PUB_KEM, AT_MAC | | | |<---------------------------+ | +--+--------------+----------------------------+---------+ | | The peer checks if it wants to do the FS extension. If | | | yes, it will eventually respond with AT_KEM_CT and | | | AT_MAC. If not, it will ignore AT_PUB_KEM and | | | AT_KDF_FS and base all calculations on basic EAP-AKA' | | | attributes, continuing just as in EAP-AKA' per RFC | | | 9048 rules. In any case, the peer needs to query the | | | auth parameters from the USIM card. | | +--+--------------+----------------------------+---------+ | | | | | | RAND, AUTN | | | |<-------------+ | | | | | | | CK, IK, RES | | | +------------->| | | +--+--------------+----------------------------+---------+ | | The peer now has everything to respond. If it wants to | | | participate in the FS extension, it will calculate a | | | PQ KEM shared secret key based on the server's PQC | | | KEM public key. Finally, it proceeds to derive all | | | EAP-AKA' key values and constructs a full response. | | +--+--------------+----------------------------+---------+ | | | | | | |EAP-Resp/AKA'-Challenge | | | | AT_RES, AT_KEM_CT, | | | | AT_MAC | | | +--------------------------->| | | +-------+----------------------------+----------------+--+ | | The server now has all the necessary values. It | | | generates the PQ KEM shared secret and checks the RES | | | and MAC values received in AT_RES and AT_MAC, | | | respectively. Success requires both to be found | | | correct. Note that when this document is used, | | | the keys generated from EAP-AKA' are based on CK, IK, | | | and PQ KEM shared secret value. When the PQ KEM | | | extension is successfully negotiated, compromise of | | | the AKA long-term key alone does not enable an | | | adversary to derive MK_PQ_SHARED_SECRET from a | | | previously recorded protocol exchange. Deriving this | | | key additionally requires the PQ KEM shared secret ss, | | | whose confidentiality relies on the security of the | | | negotiated PQ KEM. | | +-------+----------------------------+----------------+--+ | | | | | | EAP-Success | | | |<---------------------------+ | | | | |¶
We outline the following key steps in the protocol:¶
Server generates the PQ KEM public key(pk), private key (sk) pair. The server will generate the Authentication Vector (AV). The server PQ KEM key pair is derived as:¶
(pk, sk) = kemKeyGen()¶
The server will store the expected response XRES, the PQ 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, ss) = kemEncaps(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 uses the ciphertext ct and the PQ KEM private key sk to decapsulate the shared secret:¶
ss = kemDecaps(ct, sk)¶
The decapsulated 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:¶
MK = PRF'(IK'|CK',"EAP-AKA'"|Identity) (ct, ss) = kemEncaps(pk) MK_PQ_SHARED_SECRET = PRF'(IK'|CK'|ss,"EAP-AKA' FS"| Length(Identity) | Identity | Length(ct) | 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]¶
where, pk is PQ KEM public key from the EAP server, ct is the ciphertext from the kemEncaps and it is triggered by the EAP peer only. Length(X) is the length of X in octets, encoded as a 2-octet unsigned integer in network byte order.¶
The format of the AT_PUB_KEM attribute is shown 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_PUB_KEM | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
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 [RFC4187], where the Length field is 1 byte. The modification is necessary because PQ 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:¶
* EAP-Request: It contains the public key, which is the PQ KEM public key from the EAP server.¶
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.¶
The format of the AT_KEM_CT attribute is shown 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_KEM_CT | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
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 [RFC4187], where the Length field is 1 byte. The change is necessary because ciphertexts produced by PQ 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:¶
* EAP-Response: It contains the ciphertext (ct) from the PQ KEM Encapsulation function from the EAP peer.¶
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.¶
The AT_KDF_FS attribute is defined in Section 6.2 of [RFC9678] and is used to negotiate the forward-secrecy key derivation function. This document reuses the AT_KDF_FS attribute without modifying its attribute format. This document extends the "EAP-AKA' AT_KDF_FS Key Derivation Function Values" registry with values identifying the ML-KEM-based key derivation functions defined in this specification.¶
The server indicates its supported forward-secrecy key derivation functions using AT_KDF_FS as specified in [RFC9678]. When multiple AT_KDF_FS attributes are included, their ordering indicates the server's preference, as specified by [RFC9678].¶
A peer supporting this specification selects a mutually supported ML-KEM-based key derivation function according to the negotiation procedure defined in [RFC9678]. Selection of an ML-KEM-based value indicates use of the corresponding ML-KEM parameter set and the MK_PQ_SHARED_SECRET key derivation defined in this document.¶
If no mutually supported ML-KEM-based value is selected, the endpoints follow the negotiation and fallback behavior defined by [RFC9678] and [RFC9048], as applicable.¶
Support for PQ 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 PQ KEM has been successfully negotiated via AT_KDF_FS.¶
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 [RFC9958]). The public/private key sizes, ciphertext sizes, and PQ security levels of ML-KEM are detailed in Section 12 of [RFC9958].¶
The security of the PQ KEM algorithm depends on a high-quality pseudo-random number generator. For further discussion on random number generation, see [RFC4086].¶
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.¶
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 PQ KEM public key is an input to the computation of the shared secret (ss) (line 1 of ML-KEM.Encaps_Internal algorithm in [FIPS203]). These computational binding properties for KEMs are defined in [CDM].¶
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 [RFC9958].¶
Three new Attribute Type values (TBA1, TBA2, and TBA3) from the skippable range are requested from IANA for AT_PUB_KEM (Section 9.1), AT_KEM_CT (Section 9.2), and AT_FRAGMENT (Section 7.1) 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 PQ KEM algorithm entries:¶
+=========+===============================+=========================+ | Value | Description | Reference | +=========+===============================+=========================+ | TBA4 | EAP-AKA' with MLKEM512 | [TBD BY IANA: THIS RFC] | +=========+===============================+=========================+ | TBA5 | EAP-AKA' with MLKEM768 | [TBD BY IANA: THIS RFC] | +=========+===============================+=========================+ | TBA6 | EAP-AKA' with MLKEM1024 | [TBD BY IANA: THIS RFC] | +=========+===============================+=========================+¶