Post-Quantum Use In Protocols L. Li Internet-Draft F. Liu Intended status: Standards Track Huawei Expires: 3 September 2025 2 March 2025 PQC migration use cases for the telecom network draft-li-pquip-teleco-pqc-migration-00 Abstract Telecommunications (Telecom) networks are important infrastructure. 3rd Generation Partnership Project (3GPP) provides security specifications for telecom networks, including network devices and user terminals. Meanwhile, the security protocols from IETF widely used in telecom systems. In the docuemnt, we present some post- quantum risks and assessments that exist in current telecom network based on the sepcifiction. From the perspective of RFC, this document analyzes possible post-quantum migration cases and potential strategy in typical telecom network scenarios. The strategy includes the suggestion of related IETF protocols and profiles, which can also provide guidance for other similar communication systems. 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 3 September 2025. Copyright Notice Copyright (c) 2025 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. Li & Liu Expires 3 September 2025 [Page 1] Internet-Draft teleco PQC migration March 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Document Organization . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Typical Telecom Scenarios and Potential Risks . . . . . . . . 4 3.1. Certificate Enrollment Procedure of the Base station . . 4 4. Reference Migration Use Cases . . . . . . . . . . . . . . . . 6 4.1. Overview of Telecom network . . . . . . . . . . . . . . . 6 4.2. N2/N3 migration between base station and security gateway . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Migration Suggestion . . . . . . . . . . . . . . . . 9 4.2.3. Other Information . . . . . . . . . . . . . . . . . . 9 4.3. Concealment of the Cellphone's Subscription Permanent Identifier . . . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Consideration . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Cryptographic technologies are used throughout ICT(Information and communications technology) industry to authenticate the source and protect the confidentiality and integrity of information that we communicate and store. However, quantum computing technology poses significant threats to classical cryptography, especially to widely- used cryptographic algorithms that secure much of today's data, rendering electronic secrets vulnerable to discovery. Today's 5G network widely uses both symmetric and asymmetric cryptography above across different layers of the network to ensure the security, privacy, and integrity of communications. The permanent identity of device (named Subscription Permanent Identifier, SUPI) is protected by asymmetric key encryption algorithms when the UE initially accesses the 5G systems. Then, symmetric key encryption (e.g., AES) is used to protect the signaling control and data when the UE (e.g., the cellphone) communicates with Li & Liu Expires 3 September 2025 [Page 2] Internet-Draft teleco PQC migration March 2025 the network. In addition, a network entity (for example, a base station) uses IPsec tunnels to protect the user data and control plane. network functions in the core network use TLS connection for security transmission. The PRINS [RFC8784] can be used to protect communications between different operator domains through SEPP. These are all related to both symmetric and asymmetric key cryptography In fact, servral procedures should considered be migrated to quantum- safe, becase quantum computers endanger both symmetric and asymmetric cryptography: * For asymmetric encryption schemes, for example, ECIES (based on Elliptic Curve Cryptography), and IKEv2 (Dbased on iffie-Hellman key exchanges), Shor's algorithm [shor], running on a sufficiently powerful quantum computer, can break these systems by making these hard mathematical problems easy to solve (e.g., ECC used in ECIES and Diffie-Hellman used in IKEv2 relying the difficulty of solving discrete logarithm problems). As a result, public-key cryptosystems that secure digital signatures, encrypted communications, and key exchanges would become vulnerable to quantum attacks. * For symmetric encryption schemes, for example, AES (Advanced Encryption Standard) / SNOW-5G / ZUC and SHA-256 (hash functions), their vulnerability to quantum computing algorithm (e.g., Grover's algorithm) is still in active discussions in post-quantum cryptography research community. The major concern is that quantum computer can speed up the process of brute-forcing symmetric keys. In the document, we propose the telecom use case for PQC migration. The structure of the documents can be seen in 2 sections. First, the current telecom scenarios are proposed to show the potential PQC risk and the assessment. Then, the migration use case related to the scenario is proposed and present the migration strategy. Some of the cases are referred from the guideline of GSMA [PQ03]. Further, this document points out the connections between the IETF protocols and the telecom system for the information of each WG in contributing the PQC protocol current design as well as in future. 1.1. Document Organization The remainder of this document is organized as follows: * Section 3 analyses typical telecom scenarios and potential tisks and the assessment. Li & Liu Expires 3 September 2025 [Page 3] Internet-Draft teleco PQC migration March 2025 * Section 4 introduces the reference miagration use cases including the migration stretegy. * Section 6 describes the analysis of security characteristics 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Typical Telecom Scenarios and Potential Risks This section is the core of this document. each introduced telecom scenarios may contain more than one risks and threats and it will link to the reference use cases in the next section. 3.1. Certificate Enrollment Procedure of the Base station Given the standardized process of certificate enrolment for base stations defined in 3GPP TS 33.310[TS33310], we consider the procedure where a base station (e.g., 5G base station = gNB, or 4G base station = eNodeB) bootstraps and tries to apply a certificate from the operator's CA with a preconfigured certificate from the vendor CA. Li & Liu Expires 3 September 2025 [Page 4] Internet-Draft teleco PQC migration March 2025 +-------------+ +--------------+ +----------------+ |Base Station | | Operator | |Security Gateway| | | | CA | | | +-------------+ +--------------+ +----------------+ | | | |--------------------------------->| | |1a.Request for a | | | operator certificate | | | Atteching vendor certificate. | +------------------------------+| | | |1b.Verify atteched vendor cert|+ | | +------------------------------+| |<---------------------------------| | | 1c.Issue a operator | | | certificate to BS. | | |--------------------------------------------------------------------| | 2a.Communicate with Core netowrk and security | | GW with Operator certificate. | | | | +-----------------------------+ | | | |2b.authenticate the base | | | | |station using operator +-+ | | |cert and response the | | | | |request. | | | | +-----------------------------+ | | | | Figure 1 Scenario of the certificate enrolment of the base station As shown in Figure 1, the following steps are performed by gNB/eNodeB to initially establish a secure connection and apply the certificate, which can be an example to show the quantum risk in the current telecom system: * 0. The base station pre-installs vendor certificate from vendor CA (out of bound). Then, the base station pre-establishes the IPsec tunnel connection with operator CA. * 1. The base station request to apply the operator certificate through the IPsec Tunnel. * 2. The base station communicate to core network through IPsec tunnel and the operator certificate. There are two risks related to the quantum computation attack that need to be considered in the above steps. Risk A: Attacker attacking the IPsec tunnel Li & Liu Expires 3 September 2025 [Page 5] Internet-Draft teleco PQC migration March 2025 * 1. The base station establishes the security connection with operator CA through IPsec Tunnel. During the establishment, the base station exchanges the session protection key with operator ca using IKEv2/IPsec. * 2. An attacker in risk A eavesdropping and storing the traffic of IPsec tunnel and tries to analyzed and corrupted the key exchange packet in IKEv2 with quantum computing capabilities. * 3. If the traffic is protected by quantum-resistant approaches, the type 1 attacker will fail to derive the IPsec session key used for base station and operator CA. Risk B: Attacker attacking the certificate * 1.The attacker in risk B establishes a connection with the operator CA and obtains the X.509 profile of a stolen vendor certificate from other entities. * 2.The attacker attempts to forge a valid X.509 profile (including the certificate signature) of a vendor certificate. * 3.If a quantum-resistant signature approaches is used in certificate; the attacker will fail to forge a valid vendor certificate with a valid signature. Risk A is non-quantum safe protocols such as the CMPv2 and IPsec (e.g., secure key exchange procedure). Risk B is the non-quantum safe X.509 certificate (e.g., ECC signatures in the certificate). Two possible quantum risks threaten the security of base station and requires PQC migration to defense the potential attacker. 4. Reference Migration Use Cases This section is the core of this document. For each use case, we present a concise overview and highlight the features that can help to categorize it. This list is not exhaustive, and if you think we have missed some important use case please consider contributing to it. 4.1. Overview of Telecom network In today's the 5G Telecom network, a variety of cryptographic algorithms and IETF protocols are used across different layers of the network to ensure the security, privacy, and integrity of communications. Both symmetric and asymmetric cryptography play crucial roles, where their main telecom usages and related IETF WG can be summarized in Table 1. Li & Liu Expires 3 September 2025 [Page 6] Internet-Draft teleco PQC migration March 2025 +===============+==============+============+============+================+========+ |Migration |Usage in 5G |Symmetric |Asymmetric |Reference in |Relative| |Protocols | |Cryptography|Cryptography|Existing 3GPP |IETF WG | | | | | |specifications | | +===============+==============+============+============+================+========+ |Key Derivation |Key agreement |KDF based on|N/A |Annex A.1 in |N/A | | |between UE and|symmetric | |3GPP TS | | | |individual NF |cryptography| |33.501[TS33501],| | | |(e.g., K_AMF) | | |TS | | | | | | |33.220[TS33220] | | +---------------+--------------+------------+------------+----------------+--------+ |Secure Key |Two entities |Integrity |Diffie- |Clause 9 in 3GPP|IPSECME | |Exchange |(e.g., NF/RAN/|and |Hellman (DH)|TS 33.501 | | | |Security |confidential|or Elliptic | | | | |gateway, etc.)|protection |Curve | | | | |to securely |in IPsec |Diffie- | | | | |exchange keys | |Hellman | | | | |over an | |(ECDH) | | | | |insecure | | | | | | |channel for | | | | | | |deriving | | | | | | |symmetric | | | | | | |session keys | | | | | +---------------+--------------+------------+------------+----------------+--------+ |Authentication |UE |5G-AKA and |EAP-TLS |Annex I.2 in |EMU | | |registration |EAP-AKA' | |3GPP TS 33.501 | | | |and | | | | | | |authentication| | | | | +---------------+--------------+------------+------------+----------------+--------+ |Authentication |Two NFs mutual|N/A |Digital |Clause 13 in |Lamps | |for Network |authentication| |Certificate |3GPP TS 33.501 | | |function | | |and PKI | | | +---------------+--------------+------------+------------+----------------+--------+ |Identity |Concealing |N/A |Public key |Clause 6.12 in |N/A | |Protection |SUPI by | |encryption |TS 33.501, 3GPP | | | |generating | |(ECIES) |TS 23.003 | | | |SUCI | | |[TS23003] | | +---------------+--------------+------------+------------+----------------+--------+ |Data |Encryption to |AES / SNOW- |N/A |Clause 5.11 in |CFRG | |Confidentiality|protect user |5G / ZUC | |3GPP TS 33.501, | | |and integrity |plane data | | |TS | | | |and/or control| | |35.215[TS35215],| | | |plane | | |TS | | | |signaling | | |35.221[TS35221] | | +---------------+--------------+------------+------------+----------------+--------+ |Public key |Signature of |N/A |Signature |3GPP TS |ACME | |Infrastructure |the | |algorithm, |33.310[TS33310] |/Lamps | | |certificate | |for example,| | | Li & Liu Expires 3 September 2025 [Page 7] Internet-Draft teleco PQC migration March 2025 | |for security | |ECC, etc. | | | | |establishment,| | | | | | |such as | | | | | | |transport | | | | | | |layer security| | | | | +---------------+--------------+------------+------------+----------------+--------+ Table 1: Summary of symmetric and asymmetric cryptography in 5G Telecom network As shown in the table, some common issues have been discussing in the relevant IETF WGs, but there are some unique characteristics, in terms of the deployment of telecom networks. Specific use cases are discussed in the following sections, which are proposed based on the scenario in section 3 to address the identified risks. 4.2. N2/N3 migration between base station and security gateway 4.2.1. Description In the current telecom network, the base station and the core network need to transmit control signaling and the user's data. Control signaling is for example non-access stratum information of the UE, including important messages such as user authentication and authorization information. The user's data is for example, the communication data between the UE and the website of data network (aka., user plane data). The foregoing content is transmitted through reference points N2 and N3 respectively. Generally, it can be concluded that N2 is used for control plane signaling, and N3 is used for user plane data. As described in the threat analysis in Section 2, both the secure connection of the N2 and the N3 reference points use the IPsec protocol. Specifically, the core network uses a security gateway (SEG) as the endpoint of the IPSec tunnel. And the other end point is base station. As specified if 3GPP TS 33.501, When an IPsec tunnel is established, IKEv2 is executed and authenticated by the certificate with specified profile. For post-quantum migration of N2/N3, Although IPsec itself uses symmetric encryption for transmission, the current 3GPP recommended IKEv2 protocol version and certificate format do not include post- quantum considerations. In this use case of N2/N3, the post-quantum migration of IKEv2 should be considered. Li & Liu Expires 3 September 2025 [Page 8] Internet-Draft teleco PQC migration March 2025 4.2.2. Migration Suggestion From the perspective of IETF PQUIP and this use case, the following analysis can be considered. About key exchange: * A pre-shared key may be considered as a way, for example, as specified in RFC 8784[RFC8784], which includes the pre-shared hybrid key, and the non-hybrid key (e.g, AES only). The reason is same as hybrid key exchange. Moreover, considering that base stations and SEGs are usually provided by different vendors, extra coordination may be required or the key pre-configuration can be implemented by operators during the deployment. * Directly use the post-quantum algorithm to negotiate keys, which can be considered when the post-quantum algorithm is mature. Besides, some additional issues also need to be considered, such as increased payload size and IKE fragmentation. About authentication: * PKIs that support post-quantum signatures need to be considered. Otherwise, certificate-based authentication may be risky between the base station and the SEG. 4.2.3. Other Information For other SDOs, 3GPP has not yet proposed post-quantum migration considerations. The GSMA proposed post-quantum migration guideline[PQ03] partially including the use case. 4.3. Concealment of the Cellphone's Subscription Permanent Identifier TODO 5. IANA Considerations This document has no IANA considerations. 6. Security Consideration TODO 7. References 7.1. Normative Reference Li & Liu Expires 3 September 2025 [Page 9] Internet-Draft teleco PQC migration March 2025 [PQ03] GSMA, "Post Quantum Cryptography Guidelines for Telecom Use Cases v2.0", PQ 03, Task Force PQTN, October 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, "Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security", RFC 8784, DOI 10.17487/RFC8784, June 2020, . [TS23003] 3GPP, "Numbering, addressing and identification", TS 23.003, Group 3GPP/CT4, January 2025, . [TS33220] 3GPP, "Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA)", TS 33.220, Group 3GPP/SA3, March 2024, . [TS33310] 3GPP, "Network Domain Security (NDS); Authentication Framework (AF)", TS 33.310, Group 3GPP/SA3, January 2025, . [TS33501] 3GPP, "Security architecture and procedures for 5G System", TS 33.501, Group 3GPP/SA3, January 2025, . [TS35215] 3GPP, "Specification of the 3GPP Confidentiality and Integrity Algorithms UEA2 and UIA2; Document 1: UEA2 and UIA2 specifications", TS 35.215, Group 3GPP/SA3, April 2024, . Li & Liu Expires 3 September 2025 [Page 10] Internet-Draft teleco PQC migration March 2025 [TS35221] 3GPP, "Specification of the 3GPP Confidentiality and Integrity Algorithms UEA2 and UIA2; Document 1: UEA2 and UIA2 specifications", TS 35.221, Group 3GPP/SA3, April 2024, . 7.2. Informative References [PRINS] Green, G., "5G Security when Roaming Part 2", 21 May 2021, . [shor] Shor, P.W., "Algorithms for Quantum Computation: Discrete Logarithms and Factoring", DOI 10.1109/SFCS.1994.365700, 6 August 2002, . Acknowledgments TODO Authors' Addresses Lun Li Huawei Email: lilun20@huawei.com Faye Liu Huawei Email: liufei19@huawei.com Li & Liu Expires 3 September 2025 [Page 11]