Huawei

lilun20@huawei.com

Huawei Singapore

liufei19@huawei.com

Security Post-Quantum Use In Protocols post-quantum cryptography PQC escape In this contribution, a design of escape message mechanism is proposed, where the service provider sends an escape message to the service consumer using existing non-PQC connection and then starts to re-establish the quantum-safe protocol. The proposed escape message can potentially be used in a variety of protocols, including IPsec, TLS, or between the air interface of a cellphone and a network device. We believe that for largely deployed networks and entities, escape messages can be provided as a plan B for always-live devices of service provider and consumer that cannot complete post-quantum migration in advance and mitigates negative impacts after potential Q-days occur. Different protocols and devices may be implemented escape mechanism in different sepcific ways.

The post-quantum transition should be gradual in largely deployed networks and entities since one of the important feature of these networks such as telecom network is that a large number of legacy entities and devices have been deployed on the always-live network. Meanwhile, Crypto agility is a basic requirents including incident responses and disaster recovery plans for rapid algorithm and protocol swaps. The transition may cause complex effects in terms of confusing interfaces and reference point. Considering the increased computational and payload burden of legacy equipment, many stakeholders may take risks and not be willing to embed a large number of equipments to complete the migration ahead of time. Considering billions of cellphones (aka., UE), hundreds of thousands of network entities, we propose to embed the post-quantum migration preparation gradually in advance, and to dynamically trigger and complete the post-quantum transition as required by extra messages and service mechanisms. Therefore, regarding future quantum attacks (aka, Q-day attacks such as Shor's algorithm ), one of the practical approaches is to notify entities to dynamically perform post-quantum using a new concept message, which we called the PQC escape message. The name was inspired by the history of ESC keys in the keyboard, when ESC key is originally used for switching different mode in vi family . An PQC escape message should be sent in a proper procedure, for example, periodically or broadcast. In addition, except sending the escape message as a simply notification, it can also contain additional usage. It will be discussed in the session of the message design. We believe that the need for escape messages exists widely in a variety of complex systems, not limit to largely deployed networks such as telecom networks. It is recommended to provide guidance of the format of the escape message. This concept is also important as the part of the cryptographic agility, different protocols and devices may be implemented in different sepcific ways.

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 .

The PQC escape message should be deployed between the service provider and the consumer. In general, the service provider and consumer are only concepts, multiple servers or consumers are also supported as long as having an established secure connection (e.g., IPsec , TLS , etc.).

| Provider| | | Communicate with current security | | | | Connection (tls, ipsec, etc.) | | +--------+ +---------+ Figure 1 System architecture applied escape message]]>

The service consumer for example can be a UE, an APP client, a security gateway. The service provider for example can be a network function, an APP server, or a security gateway.

Escape messages should be designed to be as simple and efficient between service providers and consumers. Some requirements are listed as follows: 1. the message shall be dedicated for instruction to complete a live quantum transition. A dedicated message format helps the device identify the message rapidly. In term of the implementation level, the device can enter a dedicated mode to improve the success rate and shorten the response time. 2. the escape message shall contain a common security protection design including the integrity protection. This prevents attackers from sending false indications and causing the device to enter the migration state accidently. 3. the message shall be a standardized message format. A pre-shared key may be configured on both sides of the device to be migrated, which can be used for the protection of migration and a furtherly negotiation a post-quantum algorithm key. The sepcific format can be discussed in dedicated working group which are not in the scope of this docuement. The pre-shared key can be either a dedicated pre-shared key. Optionally, it can also be the symmetric (pre-shared) key already used in the currently connection of TLS or IPsec, etc. Specifically, the following two mode can be used as options.

From the perspective of IETF PQUIP and this use case, the following analysis can be considered.

| | | Consumer | Response Escape message and start migration | Service | | | |Provider | | | +--------------------------------------+ | | | | | Negotiate new security context | | | | |---| to establish PQC secure connection |---| | | | +--------------------------------------+ | | +----------+ +---------+ Figure 2. Basic steps of escape message]]>

The following steps shall be performed between consumer and service provider: 1. The service provider sends escape message to the consumer. 2. The consumer responses the escape message and starts to PQC migration. Noted that before the begnining of the consumer migration, provider may also be required to send a comfirmation message to consumer to make sure the both service provider and consumer are in the same page to avoid any incosistances 3. The consumer and service provider negotiate the new PQC security context and to establish PQC security connection. There are several ways to negotiate with new PQC security context. For example, If the consumer and service provider have established an IPsec connection through traditional IKE , the multiple key exchanges of IKEv2 as defined in RFC 9370 can be used to re-negotiate a new quantum-safe security key after receiving the escape message. The consumer and service provider preconfigure the escape message. During the migration point (for example, service provider detected the quantum attack in Q-day, or as instructions of the system administrator). The service provider can send the escape message with above flows to consumer. Then, the consumer will response escape message to start the PQC migration. Finally, the consumer and the service provider shall start to negotiate new security context of including ML-KEM, ML-DSA or hybrid key exchanges, etc. The PQC escape message above is a concept, and its specific existence varies in different protocols and scenarios. It is expacted that this capability should be widely supported during PQC transitions. The following examples are some specific scenarios. Specifically, the IKEv2 indication is an already supported feature in RFC. Cellphone identifier is another transition example that could be done in future.

As it is already supported in RFC 9242 , the initiator indicates its support for Intermediate Exchange by including a notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in the IKE_SA_INIT request message. If the responder also supports this exchange, it includes this notification in the response message. The same functionality is also supported in RFC 9370, where the indication message INTERMEDIATE_EXCHANGE_SUPPORTED can be considered an escape message, triggered between the IKEv2 initiator and responder when post-quantum key negotiation needs to be triggered. According to the protocol requirements, if the indication message is not carried, any ADDKE Transform may be skipped or considered unreadable information. These ADDKEs can be used to negotiate payloads for post-quantum capabilities (i.e., key encapsulation using post-quantum algorithms). In other words, the indication message INTERMEDIATE_EXCHANGE_SUPPORTED corresponds to the send/response escape message in Figure 2 in IKE_SA_INIT stage of the PQC hybrid key exchange.

Regarding the post-quantum migration of UE (e.g., mobile phones), according to GSMA analysis, the UE SUPI (Subscription Permanent Identifier) may be related to post-quantum migration, where SUPI needs to be encrypted to Subscription Concealed Identifier (SUCI) using the non-PQC algorithm ECIES during access. It is expected to use a post-quantum way for protecting SUCI when accessing the network. Therefore, an example scenarios of PQC escape message is to let the UE receive a post-quantum escape indication, which can be sent from network equipment, e.g., periodically broadcasted. When the UE receives this indication (e.g., broadcast), it should encrypt the SUPI using the post-quantum cryptographic algorithm according to the indication to obtain a post-quantum secured SUCI. Then, use the post-quantum secure SCUI in the initial message for network access. Network equipment can authenticate the device through the post-quantum secure SUCI. Based on the discussion of emails, some exceptional situations may need to be handled, as following. Indication should be as a proper format, which if the legacy device receives, it can be discard and do nothing and continue use non-PQC way to access the network, but the network shall verify if it is legacy for example based on its subscription. This is to prevent any potential attacker jamming to use weak crypto in a non-legacy device access procedure If a device is already migrated and it still receives the escape message, the device shall know it has migrated successfully and may ignore any newly recived indication. It is suggested the escape message should be carried in broadcasting way. And may send to all reachable devices periodically, until the majority of the device has complete the migration. It is helpful to prevent any potential attackers that tries to block any escape messages.

IANA Considerations This document has no IANA considerations.

The escape message is a compromise approach for dynamic PQC migration, usually it is expected after an attack has been discovered. It is still recommended that quantum migration should be performed in advance. Escape can be a plan B. During the escape message procedure, Although basic steps can be implemented easily, it is worth to say that the key being used in non-PQC TLS or IPsec may already be leaked during the key exchange phase because of Q-day attacks. For example, assume that an attacker has captured the key during the establishement of non-PQC TLS or IPsec connection, and uses a quantum attack (e.g., HNDL attack). In this case, the attacker can obtain the information and data in the connection, including subsequent escape messages and PQC security context negotiation content, which potential brings security risks. /*TODO: Consideration of escape message enhancement when potential non quantum-safe keys already be leaked.

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. This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. This document utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs. This document updates RFC 7296 by renaming a Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment. The Intermediate Exchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established. AT and T Bell Laboratories

Acknowledgments TODO