Post-Quantum Use In Protocols                                      L. Li
Internet-Draft                                                    F. Liu
Intended status: Standards Track                                  Huawei
Expires: 3 September 2025                                   2 March 2025


                PQC Escape Message for Dynamic Migration
                    draft-li-pquip-escape-message-00

Abstract

   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 cellpohone and a network
   device.  We believe that for largely deployed networks and entities,
   escape messages can be provided as a plan B for legacy devices of the
   service provider and consumer that may not able to complete post-
   quantum migration in advance.  It can mitigate negative migration
   impacts when potential Q-day occurs.

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                 PQC escape                     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
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  System Architecture . . . . . . . . . . . . . . . . . . . . .   3
   4.  Message and Mechanism Design  . . . . . . . . . . . . . . . .   4
     4.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Basic steps of escape message . . . . . . . . . . . . . .   4
   5.  Escape message example: the UE and Network in teleco
           network . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Escape message example: IPsec/IKEv2 . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Consideration  . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative Reference . . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The post-quantum migration 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.
   The migration 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 migration as required by extra
   messages and service mechanisms.









Li & Liu                Expires 3 September 2025                [Page 2]

Internet-Draft                 PQC escape                     March 2025


   Therefore, regarding future quantum attacks (aka, Q-day attacks such
   as Shor's algorithm [shor]), one of the practical approaches is to
   notify entities to dynamically perform post-quantum migration using a
   new message, which we called the PQC escape message.  The name was
   inspired by the history of the ESC key [ISO9995] in the keyboard,
   when ESC key is originally used for switching different mode of vi
   family [ESCKEY].

   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.

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.  System Architecture

   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 [RFC4301], TLS [RFC8446], etc.).


     +--------+                                             +---------+
     |        |                                             |         |
     |Service |                                             | Service |
     |Consumer|<------------------------------------------->| 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.





Li & Liu                Expires 3 September 2025                [Page 3]

Internet-Draft                 PQC escape                     March 2025


4.  Message and Mechanism Design

4.1.  Requirements

   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 migration.  A dedicated message format helps the
      device identify the message rapidly.  In term of the
      implementation level, the device can enter a dedicated migration
      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.

4.2.  Basic steps of escape message

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
















Li & Liu                Expires 3 September 2025                [Page 4]

Internet-Draft                 PQC escape                     March 2025


        +----------+                                              +---------+
        |          |  <----------------------------------------   |         |
        |          |           1. Send Escape message             |         |
        |          |                                              |         |
        |          |   --------------------------------------->   |         |
        | Consumer |2. Response Escape message and start migration| Service |
        |          |                                              |Provider |
        |          |   +--------------------------------------+   |         |
        |          |   |  3.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.

   *  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 [RFC7296], the multiple
      key exchanges of IKEv2 as defined in RFC 9370 [RFC9370] 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.

5.  Escape message example: the UE and Network in teleco network

   /*TODO

6.  Escape message example: IPsec/IKEv2

   /*TODO




Li & Liu                Expires 3 September 2025                [Page 5]

Internet-Draft                 PQC escape                     March 2025


7.  IANA Considerations

   This document has no IANA considerations.

8.  Security Consideration

   Escape messages are 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., Harvest Now,
   Decrypt Later" (HNDL) attack 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 security enhancement when potential non
   quantum-safe keys already be leaked before triggering escape.

9.  References

9.1.  Normative Reference

   [ISO9995]  ISO/IEC, "Information technology — Keyboard layouts for
              text and office systems", ISO/IEC 9995-1:2009, ISO/IEC JTC
              1/SC 35, October 2009,
              <https://www.iso.org/standard/51645.html>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.




Li & Liu                Expires 3 September 2025                [Page 6]

Internet-Draft                 PQC escape                     March 2025


   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9370]  Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
              Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
              Key Exchanges in the Internet Key Exchange Protocol
              Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May
              2023, <https://www.rfc-editor.org/info/rfc9370>.

9.2.  Informative References

   [ESCKEY]   Wikipedia, "the ESC key", 10 February 2025,
              <https://en.wikipedia.org/wiki/Esc_key#References>.

   [shor]     Shor, P.W., "Algorithms for Quantum Computation: Discrete
              Logarithms and Factoring", DOI 10.1109/SFCS.1994.365700, 6
              August 2002, <https://ieeexplore.ieee.org/document/365700/
              authors#authors>.

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 7]