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

Status of This Memo

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 24 January 2025.¶

Copyright Notice

Copyright (c) 2024 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.¶

Table of Contents

1. Introduction

Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) defined in [I-D.ietf-emu-aka-pfs] updates the improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') specified in [RFC9048], 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 [I-D.ietf-emu-aka-pfs]). 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 [I-D.ietf-emu-aka-pfs].¶

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.¶

As the National Institute of Standards and Technology (NIST) is still in the process of selecting the new post-quantum cryptographic algorithms that are secure against both quantum and classical computers, the purpose of this document is to propose a PQ-KEM for achieving perfect forward secrecy in EAP-AKA'.¶

Although this mechanism could thus be used with any PQ-KEM, this document focuses on Module-Lattice-based Key Encapsulation Mechanisms (ML-KEMs). ML-KEM is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's ML-KEM public key. Three parameters sets for ML-KEMs are specified by [FIPS203-ipd]. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Terminology

This document makes use of the terms defined in [I-D.ietf-pquip-pqt-hybrid-terminology]. 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, 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.¶

4. 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 [I-D.draft-ietf-emu-aka-pfs-11], 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.¶

MK_ECDHE = PRF'(IK'| CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)

5. Design Rationales

It is essential to note that in the PQ-KEM, one needs to apply Fujisaki-Okamoto [FO] transform or its variant [HHK] on the PQC KEM part to ensure that the overall scheme is IND-CCA2 secure, as mentioned in [I-D.ietf-tls-hybrid-design]. 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 [I-D.draft-ar-emu-pqc-eapaka].¶

6. 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 is 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.¶

7. KEM PQC Algorithms

The National Institute of Standards and Technology (NIST) started a process to solicit, evaluate, and standardize one or more quantum-resistant public-key cryptographic algorithms, as seen here. Said process has reached its first announcement in July 5, 2022, which stated which candidates to be standardized for KEM:¶

• Key Encapsulation Mechanisms (KEMs): CRYSTALS-Kyber: ML-KEM, previously known as Kyber, is a module learning with errors (MLWE)-based KEM. Three security levels have been defined in the NIST PQC Project, namely Level 1, 3, and 5. These levels correspond to the hardness of breaking AES-128, AES-192 and AES-256, respectively.¶

NIST announced as well that they will be opening a fourth round to standardize an alternative KEM, and a call for new candidates for a post-quantum signature algorithm.¶

8. Protocol Construction

This section defines the construction for PQC KEM in EAP-AKA' FS.¶

 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 an a PQC 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 PQC KEM public key and the AT_KDF_FS       |
  |      | attribute carries PQC 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   |     |
| PQC 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 PQC 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 PQC KEM shared secret value. Even if there was an  |
  |      | attacker who held the long-term key, only an active    |
  |      | attacker could have determined the generated session   |
  |      | keys; additionally an attacker with a cryptographically|
  |      | relevant quantum computer cannot get access to the     |
  |      | server KEM private key and decrypt the data.           |
  |      +-------+----------------------------+----------------+--+
  |              |                            |                |
  |              |                EAP-Success |                |
  |              |<---------------------------+                |
  |              |                            |                |

   sk, pk = kemKeyGen()

   ct, ss = kemEncaps(pk)

   ss = kemDecaps(ct, sk)

   MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
   ct, ss = kemEncaps(pKR)
   MK_PQ_SHARED_SECRET = PRF'(IK'|CK'|ss,"EAP-AKA' FS"| Identity | ct)
   K_encr = MK[0..127]
   K_aut = MK[128..383]
   K_re = MK_PQ_SHARED_SECRET [0..255]
   MSK = MK_PQ_SHARED_SECRET [256..767]
   EMSK = MK_PQ_SHARED_SECRET [768..1279]

9. Extensions to EAP-AKA' FS

      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    | Length        | Value                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  *  EAP-Request: It contains the public key, which is the PQC KEM public key from the EAP server.

      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     | Length        | Value                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  *  EAP-Response: It contains the ciphertext (ct) from the PQC KEM Encapsulation function from the EAP peer.

10. Security Considerations

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 [I-D.ietf-pquip-pqc-engineers].¶

The security of the ML-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 ML-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.¶

11. IANA Considerations

Two new values (TBA1, TBA1) in the skippable range need to be assigned by IANA for AT_PUB_KEM (Section 9.1) and AT_KEM_CT (Section 9.2) in the "Attribute Types" registry under the "EAP-AKA and EAP-SIM Parameters" group.¶

IANA is requested to update the registry "EAP-AKA' AT_KDF_FS Key Derivation Function Values" with the PQC KEM algorithm entries:¶

   +=========+===============================+=========================+
   | Value   | Description                   | Reference               |
   +=========+===============================+=========================+
   | TBA2    | EAP-AKA' with MLKEM512        | [TBD BY IANA: THIS RFC] |
   +=========+===============================+=========================+
   | TBA3    | EAP-AKA' with MLKEM768        | [TBD BY IANA: THIS RFC] |
   +=========+===============================+=========================+
   | TBA4    | EAP-AKA' with MLKEM1024       | [TBD BY IANA: THIS RFC] |
   +=========+===============================+=========================+

12. References

Appendix A. Acknowledgements

This draft leverages text from [I-D.draft-ietf-emu-aka-pfs-11].¶

Authors' Addresses