Internet Engineering Task Force (IETF)                          C.                         CJ. Tjhai
Internet-Draft
Request for Comments: 9370                                  M. Tomlinson
Updates: 7296 (if approved)                                               Post-Quantum
Intended status:
Category: Standards Track                                    G. Bartlett
Expires: 4 June 2023
ISSN: 2070-1721                                           Quantum Secret
                                                              S. Fluhrer
                                                           Cisco Systems
                                                            D. Van Geest
                                                       ISARA Corporation
                                                       O. Garcia-Morchon
                                                                 Philips
                                                              V. Smyslov
                                                              ELVIS-PLUS
                                                         1 December 2022
                                                                May 2023

 Multiple Key Exchanges in IKEv2
                draft-ietf-ipsecme-ikev2-multiple-ke-12 the Internet Key Exchange Protocol Version 2
                                (IKEv2)

Abstract

   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.

   The primary application of this feature in IKEv2 is the ability to
   perform one or more post-quantum key exchanges in conjunction with
   the classical (Elliptic Curve) Diffie-Hellman (EC)DH key exchange, so
   that the resulting shared key is resistant against quantum computer
   attacks.  Since there is currently no post-quantum key exchange that
   is as well-studied as (EC)DH, performing multiple key exchanges with
   different post-quantum algorithms along with the well-established
   classical key exchange algorithms addresses this concern, since the
   overall security is at least as strong as each individual primitive.

   Another possible application for this extension is the ability to
   combine several key exchanges in situations when no single key
   exchange algorithm is trusted by both initiator and responder.

   This document utilizes the IKE_INTERMEDIATE exchange, by means of
   which where multiple
   key exchanges are performed when an IKE SA is being established.  It
   also introduces a new IKEv2 exchange exchange, IKE_FOLLOWUP_KE, which is used
   for the same purpose when the IKE SA is up (during rekeys being rekeyed or is creating
   additional Child SAs). SAs.

   This document updates RFC7296 RFC 7296 by renaming a transform type 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 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.

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 an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 4 June 2023.
   https://www.rfc-editor.org/info/rfc9370.

Copyright Notice

   Copyright (c) 2022 2023 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)
   (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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Problem Description . . . . . . . . . . . . . . . . . . .   3
     1.2.  Proposed Extension  . . . . . . . . . . . . . . . . . . .   4
     1.3.  Document Organization . . . . . . . . . . . . . . . . . .   7
   2.  Multiple Key Exchanges  . . . . . . . . . . . . . . . . . . .   8
     2.1.  Design Overview . . . . . . . . . . . . . . . . . . . . .   8
     2.2.  Protocol Details  . . . . . . . . . . . . . . . . . . . .  10
       2.2.1.  IKE_SA_INIT Round: Negotiation  . . . . . . . . . . .  10
       2.2.2.  IKE_INTERMEDIATE Round: Additional Key Exchanges  . .  15
       2.2.3.  IKE_AUTH Exchange . . . . . . . . . . . . . . . . . .  16
       2.2.4.  CREATE_CHILD_SA Exchange  . . . . . . . . . . . . . .  16
       2.2.5.  Interaction with IKEv2 Extensions . . . . . . . . . .  19
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     3.1.  Additional Considerations and Changes . . . . . . . . . .  21
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  24
     5.2.  Informative References  . . . . . . . . . . . . . . . . .  25
   Appendix A.  Sample Multiple Key Exchanges  . . . . . . . . . . .  26
     A.1.  IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange
           Payloads  . . . . . . . . . . . . . . . . . . . . . . . .  26
     A.2.  No Additional Key Exchange Used . . . . . . . . . . . . .  28
     A.3.  Additional Key Exchange in the CREATE_CHILD_SA Exchange
           only  . . . . . . . . . . . . . . . . . . . . . . . . . .  29
           Only
     A.4.  No Matching Proposal for Additional Key Exchanges . . . .  31
   Appendix B.  Design Criteria  . . . . . . . . . . . . . . . . . .  31
   Appendix C.  Alternative Design . . . . . . . . . . . . . . . . .  33
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  36
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

1.  Introduction

1.1.  Problem Description

   The Internet Key Exchange Protocol (IKEv2) version 2 (IKEv2), as specified in [RFC7296]
   [RFC7296], uses the Diffie-Hellman (DH) or the Elliptic Curve Diffie-Hellman Diffie-
   Hellman (ECDH) algorithm, which shall be referred to as (EC)DH "(EC)DH"
   collectively, to establish a shared secret between an initiator and a
   responder.  The security of the (EC)DH algorithms relies on the
   difficulty to solve a discrete logarithm problem in multiplicative (and respectively
   (and, respectively, elliptic curve) groups when the order of the
   group parameter is large enough.  While solving such a problem
   remains infeasible with current computing power, it is believed that general purpose
   general-purpose quantum computers will be able to solve this problem,
   implying that the security of IKEv2 is compromised.  There are,
   however, a number of cryptosystems that are conjectured to be
   resistant against quantum
   computer attack. to quantum-computer attacks.  This family of cryptosystems
   is known as post-
   quantum cryptography (PQC). "post-quantum cryptography" (or "PQC").  It is sometimes
   also referred to as
   quantum-safe cryptography (QSC) "quantum-safe cryptography" (or "QSC") or quantum-resistant cryptography
   (QRC).
   "quantum-resistant cryptography" (or "QRC").

   It is essential to have the ability to perform one or more post-
   quantum key exchanges in conjunction with an (EC)DH key exchange so
   that the resulting shared key is resistant to quantum-computer
   attacks.  Since there is currently no post-quantum key exchange that
   is as well-studied as (EC)DH, performing multiple key exchanges with
   different post-quantum algorithms along with the well-established
   classical key-exchange algorithms addresses this concern, since the
   overall security is at least as strong as each individual primitive.

1.2.  Proposed Extension

   This document describes a method to perform multiple successive key
   exchanges in IKEv2.  It  This method allows integration of PQC in IKEv2,
   while maintaining backwards backward compatibility, to derive a set of IKE keys
   that is resistant to quantum computer quantum-computer attacks.  This extension allows
   the negotiation of one or more PQC algorithm algorithms to exchange data, in
   addition to the existing (EC)DH key exchange data.  It is believed
   that the feature of using more than one post-quantum algorithms algorithm is
   important
   important, as many of these algorithms are relatively new new, and there
   may be a need to hedge the security risk with multiple key exchange
   data from several distinct PQC algorithms.

   IKE peers perform multiple successive key exchanges to establish an
   IKE Security Association (SA). SA.  Each exchange produces a piece of
   secret some shared secret, and these secrets
   are combined in a way such that:

   (a)  the final shared secret is computed from all of the component
        key exchange secret; secrets;

   (b)  the shared secret as specified in [RFC7296] is obtained  unless both peers support and agree to use the additional key
        exchanges introduced in this specification; specification, the final shared
        secret equivalent to the shared secret specified in [RFC7296] is
        obtained; and

   (c)  if any part of the component key exchange method is a post-quantum post-
        quantum algorithm, the final shared secret is post-quantum
        secure.

   Some post-quantum key exchange payloads may have sizes larger than
   the standard maximum transmission unit (MTU) size, and therefore size.  Therefore, there
   could be issues with fragmentation at the IP layer.  In order to
   allow using the use of those larger payload sizes, this mechanism relies on
   the IKE_INTERMEDIATE exchange as specified in [RFC9242].  With this
   mechanism, the key exchange is initiated using a smaller, possibly
   classical primitive, such as (EC)DH.  Then, before the IKE_AUTH
   exchange, one or more IKE_INTERMEDIATE exchanges are carried out,
   each of which contains an additional key exchange.  As the
   IKE_INTERMEDIATE exchange is encrypted, the IKE fragmentation
   protocol [RFC7383] can be used.  The IKE SK_* values are updated
   after each exchange exchange, as described in Section 2.2.2, and so 2.2.2; thus, the final
   IKE SA keys depend on all the key exchanges, hence they exchanges.  Hence, the keys are
   secure if any of the key exchanges are secure.

   While this extension is primarily aimed for at IKE SAs due to the
   potential fragmentation issue discussed above, it also applies to
   CREATE_CHILD_SA exchanges as illustrated in Section 2.2.4 for
   creating/rekeying of Child SAs and rekeying of IKE SAs.

   Note that readers should consider the approach defined in this
   document as providing a long term long-term solution in upgrading the IKEv2
   protocol to support post-quantum algorithms.  A short term short-term solution
   to make IKEv2 key exchange quantum secure is to use post-quantum pre-
   shared keys as specified in [RFC8784].

   Note also that the proposed approach of performing multiple
   successive key exchanges in such a way that way, when the resulting session
   keys depend on all of them them, is not limited to only addressing the
   threat of quantum computer. computers.  It can also be used when all of the
   performed key exchanges are classical (EC)DH primitives, where where, for some
   various reasons
   (e.g. (e.g., policy requirements) requirements), it is essential to
   perform multiple of
   them. key exchanges.

   This specification does not attempt to address key exchanges with KE
   payloads longer than 64 Kbytes; KB; the current IKE payload format does not
   allow such as a possibility.  At the time of writing, it appears likely
   that there are a number of key exchanges available that would not
   have such a requirement.  However, if such a requirement is
   needed, [I-D.tjhai-ikev2-beyond-64k-limit]  [BEYOND-64K] discusses approaches that
   could be taken to exchange huge payloads. payloads if such a requirement were
   needed.

1.3.  Document Organization

   The remainder of this document is organized as follows.  Section 2
   describes how multiple key exchanges are performed between two IKE
   peers and how keying materials are derived for both SAs and Child
   SAs.  Section 3 discusses IANA considerations for the namespaces
   introduced in this document, and document.  Section 4 discusses security
   considerations.  In the Appendices sections, Appendices, some examples of multiple key
   exchanges are illustrated in Appendix A, A.  Appendix B summarizes
   design criteria and a summary of alternative approaches that have been considered, but considered.
   These approaches are later discarded, are as described in Appendix C.

   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.

2.  Multiple Key Exchanges

2.1.  Design Overview

   Most post-quantum key agreement algorithms are relatively new, and
   thus new.  Thus,
   they are not fully trusted.  There are also many proposed algorithms,
   with algorithms
   that have different trade-offs and relying that rely on different hard
   problems.  The concern is that some of these hard problems may turn
   out to be easier to solve than anticipated and thus anticipated; thus, the key agreement
   algorithm may not be as secure as expected.  A hybrid solution, when
   multiple key exchanges are performed and the calculated shared key
   depends on all of them, allows us to deal with this uncertainty by
   combining a classical key exchange with a post-quantum one, as well
   as leaving open the possibility of combining it with multiple post-quantum post-
   quantum key exchanges.

   In order to be able to use IKE fragmentation [RFC7383] for those key
   exchanges that may have long public keys, this specification utilizes
   the IKE_INTERMEDIATE exchange defined in [RFC9242].  The initial
   IKE_SA_INIT messages do not have any inherent fragmentation support
   within IKE; however, IKE.  However, IKE_SA_INIT messages can include a relatively
   short KE payload.  The additional key exchanges are performed using
   IKE_INTERMEDIATE messages that follow the IKE_SA_INIT exchange.  This
   is to allow the standard IKE fragmentation mechanisms (which cannot
   be used in IKE_SA_INIT) to be available for the potentially large Key
   Exchange payloads with post-quantum algorithm data.

   Note that this document assumes, assumes that each key exchange method
   requires one round trip and consumes exactly one IKE_INTERMEDIATE
   exchange.  This assumption is valid for all classic key exchange
   methods defined so far and for all post-quantum methods currently
   known.  For hypothetical future key exchange methods requiring that require
   multiple round trips to complete, a separate document should define
   how such methods are split into several IKE_INTERMEDIATE exchanges.

   In order to minimize communication overhead, only the key shares that
   are agreed to be used upon are actually exchanged.  To negotiate additional key exchanges
   exchanges, seven new Transform Types are defined.  These transforms
   and Transform Type 4 share the same Transform IDs.

   It is assumed that new Transform Type 4 identifiers will be assigned
   later for various post-quantum key exchanges [IKEV2TYPE4ID].  This
   specification does not make a distinction between classical (EC)DH
   and post-quantum key exchanges, nor between post-quantum algorithms which
   that are true key exchanges versus and post-quantum algorithms that act as
   key transport mechanisms; mechanisms: all are treated equivalently by the
   protocol.  This document renames a field in the Key Exchange Payload
   from "Diffie-Hellman Group Num" to "Key Exchange Method".  It  This
   document also renames Transform Type 4 from "Diffie-Hellman Group
   (D-H)" to "Key Exchange Method (KE)"; the (KE)".  The corresponding renaming to
   the IANA registry is described in Section 3.

   The fact that newly defined transforms share the same registry for
   possible Transform IDs with Transform Type 4, 4 allows additional key
   exchanges to be of any type - type: either post-quantum or classical (EC)DH
   one. (EC)DH.
   This approach allows any combination of the defined key exchange
   methods to take place.  This also allows IKE peers to perform a
   single post-quantum key exchange in the IKE_SA_INIT without
   additional key exchanges, provided that the IP fragmentation is not
   an issue and that hybrid key exchange is not needed.

   The SA payload in the IKE_SA_INIT message includes one or more newly
   defined transforms which that represent the extra key exchange policy
   required by the initiator.  The responder follows the usual IKEv2
   negotiation rules: it selects a single transform of each type, type and
   returns all of them in the IKE_SA_INIT response message.

   Then, provided that additional key exchanges are negotiated, the
   initiator and the responder perform one or more IKE_INTERMEDIATE
   exchanges.  Following that, the IKE_AUTH exchange authenticates peers
   and completes IKE SA establishment.

   Initiator                             Responder
   ---------------------------------------------------------------------
   <-- IKE_SA_INIT (additional key exchanges negotiation) -->

   <-- {IKE_INTERMEDIATE (additional key exchange)} -->

                            ...

   <-- {IKE_INTERMEDIATE (additional key exchange)} -->

   <-- {IKE_AUTH} -->

2.2.  Protocol Details

   In the simplest case, the initiator starts a single key exchange (and
   has no interest in supporting multiple), and it is not concerned with
   possible fragmentation of the IKE_SA_INIT messages (either because (because either
   the key exchange that it selects is small enough not to fragment, fragment or
   the initiator is confident that fragmentation will be handled either
   by IP fragmentation, fragmentation or by transport via TCP).

   In this case, the initiator performs the IKE_SA_INIT for a single key
   exchange using a Transform Type 4 (possibly with a post quantum
   algorithm), post-quantum
   algorithm) and including the initator initiator KE payload.  If the responder
   accepts the policy, it responds with an IKE_SA_INIT response, and IKE
   continues as usual.

   If the initiator desires wants to negotiate multiple key exchanges, then the
   initiator uses the protocol behavior listed below.

2.2.1.  IKE_SA_INIT Round: Negotiation

   Multiple key exchanges are negotiated using the standard IKEv2
   mechanism,
   mechanism via SA payload.  For this purpose purpose, seven new transform
   types, namely
   types are defined: Additional Key Exchange 1 (with IANA (ADDKE1) with IANA-
   assigned value 6), 6, Additional Key Exchange 2 (ADDKE2) (7), Additional
   Key Exchange 3 (ADDKE3) (8), Additional Key Exchange 4 (ADDKE4) (9),
   Additional Key Exchange 5 (ADDKE5) (10), Additional Key Exchange 6 (11)
   (ADDKE6) (11), and Additional Key Exchange 7 (12) are
   defined. (ADDKE7) (12).  They are
   collectively called Additional "Additional Key Exchange
   transforms (ADDKE) Transform Types"
   in this document and have slightly different semantics than the
   existing IKEv2 transform types. Transform Types.  They are interpreted as an
   indication of additional key exchange methods that peers agree to
   perform in a series of IKE_INTERMEDIATE exchanges following the
   IKE_SA_INIT exchange.  The allowed transform Transform IDs for these transform
   types are the same as the IDs for Transform Type 4, so they all share
   a single IANA registry for transform Transform IDs.

   Key

   The key exchange method negotiated via Transform Type 4 always takes
   place in the IKE_SA_INIT exchange, as defined in [RFC7296].
   Additional key exchanges negotiated via newly defined transforms MUST
   take place in a series of IKE_INTERMEDIATE exchanges following the
   IKE_SA_INIT exchange, performed in an order of the values of their
   transform types,
   Transform Types.  This is so that the key exchange negotiated using
   Additional Key Exchange i always precedes that of Additional Key
   Exchange i + 1.  Each additional key exchange method MUST be fully
   completed before the next one is started.

   Note that with

   With these semantics, Additional Key Exchange transforms note that ADDKE Transform Types are not
   associated with any particular type of key exchange and do not have
   any Transform IDs that are specific per transform type transform IDs Transform Type IANA registry.

   Instead
   Instead, they all share a single registry for transform Transform IDs, namely
   "Key
   "Transform Type 4 - Key Exchange Method Transform IDs", which are also shared by
   Transform Type 4. IDs".  All key
   exchange algorithms (both classical or post-quantum) should be added
   to this registry.  This approach gives peers flexibility in defining
   the ways they want to combine different key exchange methods.

   When forming a proposal proposal, the initiator adds transforms for the
   IKE_SA_INIT exchange using Transform Type 4.  In most cases cases, they
   will contain classical (EC)DH key exchange methods, however it but that is not a
   requirement.  Additional key exchange methods are proposed using
   Additional Key Exchange transform types.
   ADDKE Transform Types.  All of these transform types are optional, optional;
   the initiator is free to select any of them for proposing additional
   key exchange methods.  Consequently, if none of the Additional Key Exchange transforms is ADDKE Transform
   Types are included in the proposal, then this proposal indicates the
   performing of standard IKEv2, as defined in [RFC7296].  On the other
   hand, if the initiator includes any
   Additional Key Exchange transform ADDKE Transform Type in the
   proposal, the responder MUST select one of the algorithms proposed
   using this type.  Note that this is not a new requirement, but that requirement; this
   behavior is already specified in Section 2.7 of [RFC7296].  A transform
   Transform ID NONE MAY be added to those transform types which that contain
   key exchange methods
   that which the initiator believes is are optional
   according to its local policy.

   The responder performs the negotiation using the standard IKEv2
   procedure described in Section 3.3 of [RFC7296].  However, for the
   Additional Key Exchange types,
   ADDKE Transform Types, the responder's choice MUST NOT contain
   duplicated algorithms (those with an identical Transform ID and
   attributes), except for the transform Transform ID of NONE.  An algorithm is
   represented as a transform, in transform.  In some cases cases, the transform could
   include a set of associated attributes that define details of the
   algorithm.  In this case, two transforms can be the same, but the
   attributes must be different.  Additionally, the order of the
   attributes does not affect the equality of the algorithm, so the
   following two transforms
   (ID=alg1,ATTR1=attr1,ATTR2=attr2) and
   (ID=alg1,ATTR2=attr2,ATTR1=attr1) define the same algorithm. algorithm: "ID=alg1,
   ATTR1=attr1, ATTR2=attr2" and "ID=alg1, ATTR2=attr2, ATTR1=attr1".
   If the responder is unable to select non-duplicated algorithm algorithms that are not
   duplicated for each proposed key exchange (either because the
   proposal contains too few choices or due to the local policy
   restrictions on using the proposed algorithms), then the responder
   MUST reject the message with an error notification of type
   NO_PROPOSAL_CHOSEN.  If the responder's message contains one or more
   duplicated choices, the initiator should log the error and MUST treat
   the exchange as failed.  The initiator MUST NOT initiate any
   IKE_INTERMEDIATE (or IKE_FOLLOWUP_KE) exchanges, exchanges so that no new SA is
   created.  If this happens in the CREATE_CHILD_SA exchange, then the
   initiator MAY delete the IKE SA, SA over which the invalid message was received,
   received by sending a Delete payload.

   If the responder selects NONE for some Additional Key Exchange types ADDKE Transform Types
   (provided they are proposed by the initiator), then the any corresponding
   Additional Key Exchange(s) in the IKE_INTERMEDIATE exchange(s)
   additional key exchanges MUST NOT take place.  Therefore  Therefore, if the
   initiator includes NONE in all of the Additional Key Exchange transforms ADDKE Transform Types and the
   responder selects this value for all of them, then no
   IKE_INTERMEDIATE messages exchanges performing additional key exchanges will
   take place between the peers.  Note that the IKE_INTERMEDIATE
   exchanges may still take place for other purposes.

   The initiator MAY propose non-consecutive Additional Key Exchange
   transforms, ADDKE Transform Types that are not
   consecutive, for example example, proposing Additional Key Exchange 2 ADDKE2 and
   Additional Key Exchange 5 transforms ADDKE5 Transform Types
   only.  The responder MUST treat all of the omitted Additional Key Exchange ADDKE transforms
   as if they are were proposed with Transform ID NONE.

   Below is an example of the SA payload in the initiator's IKE_SA_INIT
   request message.  Here  Here, the abbreviation AKEi "KE" is used to denote the
   i-th Additional Key Exchange transform defined in this document, and
   an abbreviation KE for the Key
   Exchange transform, that which this document renames from the Diffie-Hellman Diffie-
   Hellman Group transform.  Additionally, the notations PQ_KEM_1, PQ_KEM_2
   PQ_KEM_2, and PQ_KEM_3 are used to represent some
   not-yet defined Transform IDs that have
   yet to be defined of some popular post-quantum key exchange methods.

    SA Payload
       |
       +--- Proposal #1 ( Proto ID = IKE(1), SPI size Size = 8,
             |            9 transforms,      SPI = 0x35a1d6f22564f89d )
             |
             +-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
             |     +-- Attribute ( Key Length = 256 )
             |
             +-- Transform KE ( ID = 4096-bit MODP Group )
             |
             +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
             |
             +-- Transform AKE2 ADDKE2 ( ID = PQ_KEM_1 )
             |
             +-- Transform AKE2 ADDKE2 ( ID = PQ_KEM_2 )
             |
             +-- Transform AKE3 ADDKE3 ( ID = PQ_KEM_1 )
             |
             +-- Transform AKE3 ADDKE3 ( ID = PQ_KEM_2 )
             |
             +-- Transform AKE5 ADDKE5 ( ID = PQ_KEM_3 )
             |
             +-- Transform AKE5 ADDKE5 ( ID = NONE )

   In this example, the initiator proposes to perform performing the initial key
   exchange using a 4096-bit MODP group Group followed by two mandatory
   additional key exchanges (i.e.  Transforms AKE2 (i.e., ADDKE2 and AKE3) ADDKE3 Transform Types)
   using PQ_KEM_1 and PQ_KEM_2 methods in any order, then order followed by an
   additional key exchange (i.e. (i.e., ADDKE5 Transform AKE5) Type) using the
   PQ_KEM_3 method that may be omitted.

   The responder might return the following SA payload, indicating that
   it agrees to perform two additional key exchanges exchanges, PQ_KEM_2 followed
   by PQ_KEM_1 PQ_KEM_1, and that it does not want to additionally perform PQ_KEM_3 additionally.
   PQ_KEM_3.

    SA Payload
       |
       +--- Proposal #1 ( Proto ID = IKE(1), SPI size Size = 8,
             |            6 transforms,      SPI = 0x8df52b331a196e7b )
             |
             +-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
             |     +-- Attribute ( Key Length = 256 )
             |
             +-- Transform KE ( ID = 4096-bit MODP Group )
             |
             +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
             |
             +-- Transform AKE2 ADDKE2 ( ID = PQ_KEM_2 )
             |
             +-- Transform AKE3 ADDKE3 ( ID = PQ_KEM_1 )
             |
             +-- Transform AKE5 ADDKE5 ( ID = NONE )

   If the initiator includes any Additional Key Exchange transform types ADDKE Transform Types into the SA
   payload in the IKE_SA_INIT exchange request message, then it MUST
   also negotiate the use of the IKE_INTERMEDIATE exchange exchange, as described
   in [RFC9242], [RFC9242] by including an INTERMEDIATE_EXCHANGE_SUPPORTED
   notification in the same message.  If the responder agrees to use
   additional key exchanges while establishing an initial IKE SA, it
   MUST also return this notification in the IKE_SA_INIT response
   message,
   thus confirming that IKE_INTERMEDIATE exchange is supported and
   will be used for transferring additional key exchange data.  If the
   IKE_INTERMEDIATE exchange is not negotiated, then the peers MUST
   treat any Additional Key Exchange transforms ADDKE Transform Types in the IKE_SA_INIT exchange messages
   as unknown transform types and skip the proposals they appear in.  If
   no other proposals are present in the SA payload, the peers will
   proceed as if no proposal is has been chosen (i.e. (i.e., the responder will
   send a NO_PROPOSAL_CHOSEN notification).

   Initiator                          Responder
   ---------------------------------------------------------------------
   HDR, SAi1(.. AKE*...), ADDKE*...), KEi, Ni,
   N(INTERMEDIATE_EXCHANGE_SUPPORTED)    --->
                                      HDR, SAr1(.. AKE*...), ADDKE*...), KEr, Nr,
                                      [CERTREQ],
                              <---    N(INTERMEDIATE_EXCHANGE_SUPPORTED)

   It is possible that for an attacker manages to manage to send a response to the
   initiator's IKE_SA_INIT request before the legitimate responder does.
   If the initiator continues to create the IKE SA using this response,
   the attempt will fail.  Implementers may wish to consider a possible
   defense technique strategies
   as described in Section 2.4 of [RFC7296]. [RFC7296] to handle such an attack.

2.2.2.  IKE_INTERMEDIATE Round: Additional Key Exchanges

   For each additional key exchange agreed to in the IKE_SA_INIT
   exchange, the initiator and the responder perform an IKE_INTERMEDIATE
   exchange, as described in [RFC9242].

   Initiator                          Responder
   ---------------------------------------------------------------------
   HDR, SK {KEi(n)}    -->
                               <--    HDR, SK {KEr(n)}

   The initiator sends key exchange data in the KEi(n) payload.  This
   message is protected with the current SK_ei/SK_ai keys.  The notation
   KEi(n)
   "KEi(n)" denotes the n-th IKE_INTERMEDIATE KE payload from the
   initiator and
   initiator; the integer n "n" is sequential starting from 1.

   On receiving this, the responder sends back key exchange payload
   KEr(n), which
   KEr(n); "KEr(n)" denotes the n-th IKE_INTERMEDIATE KE payload from
   the responder.  As before,  Similar to how the request is protected, this message
   is protected with the current SK_er/SK_ar keys.

   The former "Diffie-Hellman Group Num" (now called "Key Exchange
   Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th
   negotiated additional key exchange.

   Once this exchange is done, both sides compute an updated keying
   material:

               SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr)

   where

   From this exchange, SK(n) is the resulting shared secret of this key exchange, secret.  Ni and Nr
   are nonces from the IKE_SA_INIT exchange and exchange.  SK_d(n-1) is the last
   generated SK_d, SK_d (derived from IKE_SA_INIT for the first use of
   IKE_INTERMEDIATE, otherwise
   IKE_INTERMEDIATE and, otherwise, from the previous IKE_INTERMEDIATE
   exchange).  The other keying materials materials, SK_d, SK_ai, SK_ar, SK_ei,
   SK_er, SK_pi, SK_pr and SK_pr, are generated from the SKEYSEED(n) as
   follows:

     {SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) |
      SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr)

   Both the initiator and the responder use these updated key values in
   the next exchange (IKE_INTERMEDIATE or IKE_AUTH).

2.2.3.  IKE_AUTH Exchange

   After all IKE_INTERMEDIATE exchanges have completed, the initiator
   and the responder perform an IKE_AUTH exchange.  This exchange is the
   standard IKE exchange exchange, as described in [RFC7296] [RFC7296], with the
   modification of AUTH payload calculation described in [RFC9242].

2.2.4.  CREATE_CHILD_SA Exchange

   The CREATE_CHILD_SA exchange is used in IKEv2 for the purposes of
   creating additional Child SAs, rekeying these Child SAs, and rekeying
   IKE SA itself.  When creating or rekeying Child SAs, the peers may
   optionally perform a key exchange to add a fresh entropy into the
   session keys.  In the case of an IKE SA rekey, the key exchange is
   mandatory.  Peers supporting this specification may want to use
   multiple key exchanges in these situations.

   Using multiple key exchanges with a CREATE_CHILD_SA exchange is
   negotiated similarly as in a similar fashion to the initial IKE exchange, see
   Section 2.2.1.  If the initiator includes any Additional Key Exchange
   transform ADDKE Transform Types
   in the SA payload (along with Transform Type 4) 4), and if the responder
   agrees to perform additional key exchanges, then the additional key
   exchanges are performed in a series of new IKE_FOLLOWUP_KE exchanges
   that follows follow the CREATE_CHILD_SA exchange.  The IKE_FOLLOWUP_KE
   exchange is introduced as a dedicated exchange especially for transferring data of additional
   key exchanges following the key
   exchange one performed in the CREATE_CHILD_SA.
   Its Exchange Type value is 44.

   Key

   The key exchange negotiated via Transform Type 4 always takes place
   in the CREATE_CHILD_SA exchange, as per the IKEv2 specification. specification
   [RFC7296].  Additional key exchanges are performed in an order of the
   values of their
   transform types, Transform Types so that the key exchange negotiated
   using Transform Type
   n Additional Key Exchange i always precedes the key exchange
   negotiated using Transform Type n Additional Key Exchange i + 1.  Each additional key
   exchange method MUST be fully completed before the next one is
   started.  Note,  Note that this document assumes, assumes that each key exchange
   method consumes exactly one IKE_FOLLOWUP_KE exchange.  For the
   methods requiring that require multiple round trips, a separate document should
   define how such methods are split into several IKE_FOLLOWUP_KE
   exchanges.

   After an IKE SA is created created, the window size may be greater than one
   and one;
   thus, multiple concurrent exchanges may be in progress, progress.  Therefore,
   it is essential to link the IKE_FOLLOWUP_KE exchanges together with
   the corresponding CREATE_CHILD_SA exchange.  Due to the fact that once  Once an IKE SA is
   created, all IKE exchanges are independent and do not IKEv2 doesn't have a
   built-in
   means mechanism to link one an exchange with another, a another one.  A new
   status type notification
   ADDITIONAL_KEY_EXCHANGE called "ADDITIONAL_KEY_EXCHANGE" is
   introduced for this purpose.  Its Notify Message Type value is 16441,
   and the Protocol ID and SPI Size are both set to 0.  The data
   associated with this notification is a blob meaningful only to the responder,
   responder so that the responder can correctly link successive
   exchanges.  For the initiator initiator, the content of this notification is an
   opaque blob.

   The responder MUST include this notification in a CREATE_CHILD_SA or
   IKE_FOLLOWUP_KE response message in case the next IKE_FOLLOWUP_KE
   exchange is expected, filling it with some data that would allow
   linking the current exchange to the next one.  The initiator MUST
   send back this notification intact in the request message of the next
   IKE_FOLLOWUP_KE exchange.

   Below is an example of CREATE_CHILD_SA exchange followed by three
   additional key exchanges.

   Initiator                             Responder
   ---------------------------------------------------------------------
   HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->
                             <--  HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr,
                                      N(ADDITIONAL_KEY_EXCHANGE)(link1)}

   HDR(IKE_FOLLOWUP_KE), SK {KEi(1),
    N(ADDITIONAL_KEY_EXCHANGE)(link1)} -->
                                  <--  HDR(IKE_FOLLOWUP_KE), SK {KEr(1),
                                      N(ADDITIONAL_KEY_EXCHANGE)(link2)}

   HDR(IKE_FOLLOWUP_KE), SK {KEi(2),
    N(ADDITIONAL_KEY_EXCHANGE)(link2)} -->
                                  <--  HDR(IKE_FOLLOWUP_KE), SK {KEr(2),
                                      N(ADDITIONAL_KEY_EXCHANGE)(link3)}

   HDR(IKE_FOLLOWUP_KE), SK {KEi(3),
    N(ADDITIONAL_KEY_EXCHANGE)(link3)} -->
                                  <--  HDR(IKE_FOLLOWUP_KE), SK {KEr(3)}

   The former "Diffie-Hellman Group Num" (now called "Key Exchange
   Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th
   negotiated additional key exchange.

   It is possible that due

   Due to some unexpected events (e.g. reboot) (e.g., a reboot), it is possible that
   the initiator may lose its state and state, forget that it is in the process of
   performing additional key exchanges exchanges, and thus never start the remaining
   IKE_FOLLOWUP_KE exchanges.  The responder MUST handle this situation
   gracefully and delete the associated state if it does not receive the
   next expected IKE_FOLLOWUP_KE request after some reasonable period of
   time.  Note that due  Due to various factors such as computational resource and key
   exchange algorithm used, note that it is not possible to give a
   normative guidance on how long this timeout period should be.  In
   general, 5-20 seconds of waiting time should be appropriate in most
   cases.

   It is also possible that the initiator may also take too long for the initiator to prepare and to send
   the next IKE_FOLLOWUP_KE request or request, or, due to the network conditions,
   the request is could be lost and retransmitted.  In this case, the
   message may reach the responder when it has already deleted the
   associated
   state state, following the advice above.  If the responder
   receives an IKE_FOLLOWUP_KE message for which it does not have a key
   exchange state, it MUST send back a new error type notification
   STATE_NOT_FOUND.
   called "STATE_NOT_FOUND".  This is a non-fatal an error notification, its notification that is not
   fatal to the IKE SA.  Its Notify Message Type value is 47, its
   Protocol ID and SPI Size are both set to 0 0, and the data is empty.
   If the initiator receives this notification in response to an
   IKE_FOLLOWUP_KE exchange performing an additional key exchange, it
   MUST cancel this exchange and MUST treat the whole series of
   exchanges started from the CREATE_CHILD_SA exchange as having failed.
   In most cases, the receipt of this notification is caused by the
   premature deletion of the corresponding state on the responder (the
   time period between IKE_FOLLOWUP_KE exchanges appeared to be too long
   from the responder's point of view, e.g. e.g., due to a temporary network
   failure).  After receiving this notification notification, the initiator MAY start
   a new CREATE_CHILD_SA exchange exchange, which may eventually be followed by
   the IKE_FOLLOWUP_KE exchanges, to retry the failed attempt.  If the
   initiator continues to receive STATE_NOT_FOUND notifications after
   several retries, it MUST treat this situation as a fatal error and
   delete the IKE SA by sending a DELETE payload.

   When

   It is possible that the peers start rekeying the IKE SA or the Child SA, it is possible that the
   peers start doing this
   SA at the same time, which is called simultaneous
   rekeying. "simultaneous rekeying".
   Sections 2.8.1 and 2.8.2 of [RFC7296] describe how IKEv2 handles this
   situation.  In a nutshell nutshell, IKEv2 follows the rule that if that, in the case
   of simultaneous rekeying, if two identical new IKE SAs (or two pairs
   of Child SAs) are created, then one of them should be deleted.  Which
   one is to be deleted delete is determined by comparing the values of four nonces
   that are used in the colliding CREATE_CHILD_SA exchanges.  The IKE SA
   (or pair of Child SAs) that is created by the exchange in which the smallest
   nonce is used should be deleted by the initiator of this exchange.

   With multiple key exchanges, the SAs are not yet created when the
   CREATE_CHILD_SA is completed, completed.  Instead, they would be created only
   after the series of IKE_FOLLOWUP_KE exchanges is finished.  For this
   reason, if additional key exchanges are negotiated in the
   CREATE_CHILD_SA exchange in which the smallest nonce is used, then then,
   because there is nothing to delete yet, the initiator of this
   exchange just stops the rekeying process process, and it MUST NOT initiate
   the IKE_FOLLOWUP_KE exchange.

   In most cases, rekey collisions are resolved in the CREATE_CHILD_SA
   exchange.  However, a situation may occur when when, due to packet loss,
   one of the peers receives the CREATE_CHILD_SA message requesting the
   rekey of an SA that is already being rekeyed by this peer (i.e. (i.e., the
   CREATE_CHILD_SA exchange initiated by this peer has been already
   completed been
   completed, and the series of IKE_FOLLOWUP_KE exchanges is in
   progress).  In this case, a TEMPORARY_FAILURE notification MUST be
   sent in response to such a request.

   If multiple key exchanges are negotiated in the CREATE_CHILD_SA
   exchange, then the resulting keys are computed as follows.

   In the case of an IKE SA rekey:

         SKEYSEED = prf(SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n))

   In the case of a Child SA creation or rekey:

        KEYMAT = prf+ (SK_d, SK(0) | Ni | Nr | SK(1) |  ... SK(n))

   In both cases, SK_d is from the existing IKE SA; SK(0), Ni, and Nr
   are the shared key and nonces from the CREATE_CHILD_SA CREATE_CHILD_SA, respectively;
   SK(1)...SK(n) are the shared keys from additional key exchanges.

2.2.5.  Interaction with IKEv2 Extensions

   It is believed that this specification requires no modification to
   the IKEv2 extensions defined so far.  In particular, the IKE SA
   resumption mechanism defined in [RFC5723] can be used to resume IKE
   SAs created using this specification.

2.2.5.1.  Interaction with Childless IKE SA

   It is possible to establish IKE SAs with post-quantum algorithms by
   only using additional key exchanges, but IKE_FOLLOWUP_KE exchanges and without using the use of
   IKE_INTERMEDIATE exchanges.  In this case, the IKE SA that is created
   from the IKE_SA_INIT
   exchange exchange, can be immediately rekeyed with
   CREATE_CHILD_SA using with additional key exchanges exchanges, where IKE_FOLLOWUP_KE
   messages are used to
   carry the for these additional key exchange payload. exchanges.  If the
   classical key exchange method is used in the IKE_SA_INIT message, the
   very first Child SA created in IKE_AUTH will offer no resistance
   against the quantum threats.  Consequently, if the peers' local
   policy requires that all Child SAs to be post-quantum secure, then the
   peers can avoid creating the very first Child SA by adopting
   [RFC6023].  In this case, the initiator sends two types of proposal proposals
   in the IKE_SA_INIT request, request: one with and another one without Additional Key Exchange transform(s). ADDKE
   Transform Types.  The responder chooses the latter proposal type and
   includes a CHILDLESS_IKEV2_SUPPORTED notification in the IKE_SA_INIT
   response.  Assuming that the initiator supports childless IKE SA
   extension, then both peers performs perform the modified IKE_AUTH exchange
   described in
   [RFC6023] [RFC6023], and no Child SA is created in this exchange.
   The peers should then immediately rekey the IKE SA and subsequently
   create the Child SAs, all with additional key exchanges using a
   CREATE_CHILD_SA exchange.

   It is also possible for the initiator to send proposals without
   Additional Key Exchange transform(s) any
   ADDKE Transform Types in the IKE_SA_INIT message and
   in message.  In this instance,
   the responder will have no information about whether or not the
   initiator supports the extension in this specification.  This may not
   be efficient efficient, as the responder will have to wait for the subsequent
   CREATE_CHILD_SA request to determine whether or not the initiator's
   request is appropriate for its local policy.

   The support for childless IKE SA is not negotiated, but it is the
   responder that indicates the support for this mode.  As such, the
   responder cannot enforce that the initiator to use this mode and
   therefore, mode.
   Therefore, it is entirely possible that the initiator does not
   support this extension and sends IKE_AUTH request as per [RFC7296]
   instead of [RFC6023].  In this case, the responder may respond with
   non-fatal
   an error that is not fatal, such as the NO_PROPOSAL_CHOSEN notify
   message type.

   Note that if the initial IKE SA is used to transfer sensitive
   information, then this information will not be protected using the
   additional key exchanges, which may use post-quantum algorithms.  In
   this arrangement, the peers will have to use post-quantum algorithm
   in Transform Type 4 in order to mitigate the risk of quantum attack.

3.  IANA Considerations

   This document adds a new exchange type into the "IKEv2 Exchange
   Types" registry:

   44         IKE_FOLLOWUP_KE

   This document renames Transform Type 4 defined in the "Transform Type
   Values" registry from "Diffie-Hellman Group (D-H)" to "Key Exchange
   Method (KE)".

   This document renames the IKEv2 registry originally titled "Transform
   Type 4 - Diffie-
   Hellman Diffie-Hellman Group Transform IDs" to "Transform Type 4 -
   Key Exchange Method Transform IDs".

   This document adds the following Transform Types to the "Transform
   Type Values" registry:

       +======+====================================+===============+
       | Type | Description                        | Used In
   -----------------------------------------------------------------       |
       +======+====================================+===============+
       | 6    | Additional Key Exchange 1 (ADDKE1) | (optional in  |
       |      |                                    | IKE, AH, ESP) |
       +------+------------------------------------+---------------+
       | 7    | Additional Key Exchange 2 (ADDKE2) | (optional in  |
       |      |                                    | IKE, AH, ESP) |
       +------+------------------------------------+---------------+
       | 8    | Additional Key Exchange 3 (ADDKE3) | (optional in  |
       |      |                                    | IKE, AH, ESP) |
       +------+------------------------------------+---------------+
       | 9    | Additional Key Exchange 4 (ADDKE4) | (optional in  |
       |      |                                    | IKE, AH, ESP) |
       +------+------------------------------------+---------------+
       | 10   | Additional Key Exchange 5 (ADDKE5) | (optional in  |
       |      |                                    | IKE, AH, ESP) |
       +------+------------------------------------+---------------+
       | 11   | Additional Key Exchange 6 (ADDKE6) | (optional in  |
       |      |                                    | IKE, AH, ESP) |
       +------+------------------------------------+---------------+
       | 12   | Additional Key Exchange 7 (ADDKE7) | (optional in  |
       |      |                                    | IKE, AH, ESP) |
       +------+------------------------------------+---------------+

                 Table 1: "Transform Type Values" Registry

   This document defines a new Notify Message Type in the "Notify "IKEv2 Notify
   Message Types - Status Types" registry:

   16441       ADDITIONAL_KEY_EXCHANGE

   and

   This document also defines a new Notify Message Type in the "Notify "IKEv2
   Notify Message Types - Error Types" registry:

   47         STATE_NOT_FOUND

3.1.  Additional Considerations and Changes

   The

   IANA is requested to add has added the following instructions for designated experts for Transform
   the "Transform Type 4 sub-registry. - Key Exchange Method Transform IDs"
   subregistry:

   *  While adding new KE Key Exchange (KE) methods, the following
      considerations must be applied.  A KE method must take exactly one
      round-trip (one IKE
   exchange) IKEv2 exchange), and at the end of this exchange,
      both peers must be able to derive the shared secret.  In addition,
      any public value that peers exchanged during a KE method must fit
      into a single IKE message. IKEv2 payload.  If these restrictions are not met
      for a KE method, then there must be documentation on how this KE
      method is used in IKEv2.

   The following changes to

   IANA are has also requested. completed the following changes.  It is assumed that
   RFCXXXX
   [RFC9370] refers to this specification.

   *  Add  Added a reference to RFCXXXX [RFC9370] in what was the "Transform Type 4 - Diffie-
      Hellman
      Diffie-Hellman Group Transform IDs" registry.

   *  Replace  Replaced the note Note on what was the "Transform Type 4 - Diffie-Hellman Diffie-
      Hellman Group Transform IDs" registry with: with the following notes:

      This registry was originally named "Transform Type 4 - Diffie-Hellman Diffie-
      Hellman Group Transform IDs" and was
      renamed to its current name by [RFCXXXX].  It has been referenced
      in its original using that name in
      a number of RFCs published prior to [RFCXXXX]. [RFC9370], which gave it the
      current title.

      This registry is used by the "Key Exchange Method (KE)" transform
      type and by all "Additional Key Exchange (ADDKE)" transform types.

      To find out requirement levels for Key Exchange Methods for IKEv2,
      see [RFC8247].

   *  Add this note  Appended [RFC9370] to the Reference column of Transform Type 4 in
      the "Transform Type Values" registry: Transform Type registry.

   *  Added these notes to the "Transform Type 4 - Key Values" registry:

      "Key Exchange Method Transform IDs" (KE)" transform type was originally named "Transform Type 4 - Diffie-Hellman
      "Diffie-Hellman Group
      Transform IDs" (D-H)" and was renamed to its current name by [RFCXXXX].
      It has been referenced in its original by that name in a
      number of RFCs published prior to [RFCXXXX]. [RFC9370], which gave it the
      current title.

      All "Additional Key Exchange" Exchange (ADDKE)" entries use the same
      "Transform Type 4 - Key Exchange Method Transform IDs" registry as
      the "Key Exchange Method (KE)".

   *  Append RFCXXXX to the Reference column of Transform Type 4 in the
      Transform Type Values registry.

   *  Append this note to "Transform Type 4 - Diffie-Hellman Group
      Transform IDs" registry: All "Additional Key Exchange" entries use
      these values as the "Key Exchange Method (KE)". (KE)" entry.

4.  Security Considerations

   The extension in this document is intended to mitigate two possible
   threats in IKEv2, namely IKEv2: the compromise of (EC)DH key exchange using Shor's
   algorithm while remaining backward compatible; compatible and the potential
   compromise of existing or future PQC key exchange algorithms.  To
   address the former threat, this extension allows the establishment of
   a shared secret by using multiple key exchanges,
   typically exchanges: typically, one
   classical (EC)DH and the other one post-quantum algorithm.  In order
   to address the latter threat, multiple key exchanges using a post-quantum post-
   quantum algorithm can be composed performed to form the shared key.

   Unlike key exchange methods (Transform Type 4), the Encryption
   Algorithm (Transform Type 1), the Pseudorandom Function (Transform
   Type 2) 2), and the Integrity Algorithm (Transform Type 3) are not
   susceptible to Shor's algorithm.  However, they are susceptible to
   Grover's attack [GROVER], which allows a quantum computer to perform
   a brute force key search search, using quadratically fewer steps than the
   classical counterpart.  Simply increasing the key length can mitigate
   this attack.  It was previously believed that one needed to double
   the key length of these algorithms.  However, there are a number of
   factors that suggest that it is quite unlikely to achieve the
   quadratic speed up speedup using Grover's algorithm.  According to NIST
   [NISTPQCFAQ], current applications can continue using an AES
   algorithm with the minimum key length of 128 bit. bits.  Nevertheless, if
   the data needs to remain secure for many years to come, one may want
   to consider using a longer key size for the algorithms in Transform
   Types 1-3.

   SKEYSEED is calculated from shared SK(x) SK(x), using an algorithm defined
   in Transform Type 2.  While a quantum attacker may learn the value of
   SK(x), if this value is obtained by means of a classical key
   exchange, other SK(x) values generated by means of a post-quantum
   algorithm ensure that the final SKEYSEED is not compromised.  This
   assumes that the algorithm defined in the Transform Type 2 is quantum
   resistant.

   The ordering of the additional key exchanges should not matter in
   general, as only the final shared secret is of interest.
   Nonetheless, because the strength of the running shared secret
   increases with every additional key exchange, an implementer may want
   to first perform the most secure method (in some metrics) and followed by
   less secure one(s). methods.

   The main focus of this document is to prevent a passive attacker from
   performing a "harvest and decrypt" attack.  In "harvest-and-decrypt" attack: in other words, an
   attacker attackers
   that records record messages exchanged today and proceeds proceed to decrypt them once he owns a
   they have access to cryptographically relevant quantum computer. computers.
   This attack is prevented due to the hybrid nature of the key
   exchange.  Other attacks involving an active attacker using a
   quantum-computer are not completely solved by this document.  This is
   for two reasons. reasons:

   *  The first reason is because that the authentication step remains
      classical.  In particular, the authenticity of the SAs established
      under IKEv2 is protected by using a pre-shared key or digital
      signature algorithms.  Whilst  While the pre-shared key option, provided
      the key is long enough, is post-quantum secure, the other
      algorithms are not.  Moreover, in implementations where
      scalability is a requirement, the pre-shared key method may not be
      suitable.  Post-quantum authenticity may be provided by using a
      post-quantum digital signature.

   *  Secondly, it should be noted that the purpose of post-quantum
      algorithms is to provide resistance to attacks mounted in the
      future.  The current threat is that encrypted sessions are subject
      to eavesdropping and are archived with decryption by quantum
      computers
   taking place at some point in the future.  Until quantum computers
      become available available, there is no point in attacking the authenticity
      of a connection because there are no possibilities for
      exploitation.  These only occur at the time of the connection, for example
      example, by mounting an on-path attack.  Consequently  Consequently, there is
      less urgency for post-quantum authenticity compared to post-quantum post-
      quantum confidentiality.

   Performing multiple key exchanges while establishing an IKE SA
   increases the responder's susceptibility to DoS attacks, attacks because of an
   increased amount of resources needed before the initiator is
   authenticated.  This is especially true for post-quantum key exchange
   methods, where many of them are more memory and/or CPU intensive than
   the classical counterparts.

   Responders may consider recommendations from [RFC8019] to deal with
   increased DoS attack DoS-attack susceptibility.  It is also possible that the
   responder only agrees to create an initial IKE SA without performing
   additional key exchanges, provided exchanges if the initiator includes such an option in
   its proposals.  Then  Then, peers immediately rekey the initial IKE SA with
   the CREATE_CHILD_SA exchange exchange, and additional key exchanges are
   performed via the IKE_FOLLOWUP_KE exchanges.  In this case, at the
   point when resource-intensive operations are required, the peers have
   already authenticated each other.  However, in the context of hybrid
   post-quantum key exchange exchanges, this scenario would leave the initial IKE
   SA (and initial Child SA SA, if it is created) unprotected against
   quantum computers.  Nevertheless  Nevertheless, the rekeyed IKE SA (and Child SAs
   that will be created over it) will have a full protection.  This is
   similar to the scenario described in [RFC8784].  Depending on the
   arrangement and peers' policy, this scenario may or may not be
   appropriate.  For example, in the G-IKEv2 protocol
   [I-D.ietf-ipsecme-g-ikev2] [G-IKEV2], the
   cryptographic materials are sent from the group controller to the
   group members when the initial IKE SA is created.

5.  References

5.1.  Normative References

   [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/info/rfc2119>.

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9242]  Smyslov, V., "Intermediate Exchange in the Internet Key
              Exchange Protocol Version 2 (IKEv2)", RFC 9242,
              DOI 10.17487/RFC9242, May 2022,
              <https://www.rfc-editor.org/info/rfc9242>.

5.2.  Informative References

   [GROVER]   Grover, L., "A Fast Quantum Mechanical Algorithm for
              Database Search", Proc. of the Twenty-Eighth Annual ACM
              Symposium on the Theory of Computing (STOC 1996), 1996.

   [I-D.ietf-ipsecme-g-ikev2]
              Smyslov, V. and B. Weis, "Group Key Management using
              IKEv2", Work in Progress, Internet-Draft, draft-ietf-
              ipsecme-g-ikev2-07, 6 October 2022,
              <https://www.ietf.org/archive/id/draft-ietf-ipsecme-
              g-ikev2-07.txt>.

   [I-D.tjhai-ikev2-beyond-64k-limit]

   [BEYOND-64K]
              Tjhai, C., CJ., Heider, T., and V. Smyslov, "Beyond 64KB Limit
              of IKEv2 Payloads", Work in Progress, Internet-Draft,
              draft-tjhai-ikev2-beyond-64k-limit-03, 28 July 2022,
              <https://www.ietf.org/archive/id/draft-tjhai-ikev2-beyond-
              64k-limit-03.txt>.
              <https://datatracker.ietf.org/doc/html/draft-tjhai-ikev2-
              beyond-64k-limit-03>.

   [G-IKEV2]  Smyslov, V. and B. Weis, "Group Key Management using
              IKEv2", Work in Progress, Internet-Draft, draft-ietf-
              ipsecme-g-ikev2-09, 19 April 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
              g-ikev2-09>.

   [GROVER]   Grover, L., "A fast quantum mechanical algorithm for
              database search", Proc. of the Twenty-Eighth Annual ACM
              Symposium on the Theory of Computing (STOC), pp. 212-219,
              DOI 10.48550/arXiv.quant-ph/9605043, May 1996,
              <https://doi.org/10.48550/arXiv.quant-ph/9605043>.

   [IKEV2TYPE4ID]
              IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters:
              Transform Type 4 - Diffie-Hellman Group Transform IDs",
              <https://www.iana.org/assignments/ikev2-parameters/
              ikev2-parameters.xhtml#ikev2-parameters-8>.
              <https://www.iana.org/assignments/ikev2-parameters/>.

   [NISTPQCFAQ]
              NIST, "Post-Quantum Cryptography Standardization: FAQs", Standard", January 2023,
              <https://csrc.nist.gov/Projects/post-quantum-cryptography/
              faqs>.

   [RFC5723]  Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
              Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
              DOI 10.17487/RFC5723, January 2010,
              <https://www.rfc-editor.org/info/rfc5723>.

   [RFC6023]  Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A
              Childless Initiation of the Internet Key Exchange Version
              2 (IKEv2) Security Association (SA)", RFC 6023,
              DOI 10.17487/RFC6023, October 2010,
              <https://www.rfc-editor.org/info/rfc6023>.

   [RFC7383]  Smyslov, V., "Internet Key Exchange Protocol Version 2
              (IKEv2) Message Fragmentation", RFC 7383,
              DOI 10.17487/RFC7383, November 2014,
              <https://www.rfc-editor.org/info/rfc7383>.

   [RFC8019]  Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange
              Protocol Version 2 (IKEv2) Implementations from
              Distributed Denial-of-Service Attacks", RFC 8019,
              DOI 10.17487/RFC8019, November 2016,
              <https://www.rfc-editor.org/info/rfc8019>.

   [RFC8247]  Nir, Y., Kivinen, T., Wouters, P., and D. Migault,
              "Algorithm Implementation Requirements and Usage Guidance
              for the Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 8247, DOI 10.17487/RFC8247, September 2017,
              <https://www.rfc-editor.org/info/rfc8247>.

   [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,
              <https://www.rfc-editor.org/info/rfc8784>.

Appendix A.  Sample Multiple Key Exchanges

   This appendix shows some examples of multiple key exchanges.  These
   examples are non-normative not normative, and they describe some message flow
   scenarios that may occur in establishing an IKE or CHILD Child SA.  Note
   that some payloads that are not relevant to multiple key exchanges
   may be omitted for brevity.

A.1.  IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange
      Payloads

   The exchanges below show that the initiator proposes the use of
   additional key exchanges to establish an IKE SA.  The initiator
   proposes three sets of additional key exchanges and exchanges, all of which are
   optional.  So  Therefore, the responder can choose NONE for some or all
   of the additional exchanges if the proposed key exchange methods are
   not supported or for whatever reasons the responder decides not to
   perform the additional key exchange.

   Initiator                     Responder
   ---------------------------------------------------------------------
   HDR(IKE_SA_INIT), SAi1(.. AKE*...), ADDKE*...), --->
   KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
   N(INTERMEDIATE_EXCHANGE_SUPPORTED)
       Proposal #1
       Transform ECR (ID = ENCR_AES_GCM_16,
                       256-bit key)
       Transform PRF (ID = PRF_HMAC_SHA2_512)
       Transform KE (ID = Curve25519)
       Transform AKE1 ADDKE1 (ID = PQ_KEM_1)
       Transform AKE1 ADDKE1 (ID = PQ_KEM_2)
       Transform AKE1 ADDKE1 (ID = NONE)
       Transform AKE2 ADDKE2 (ID = PQ_KEM_3)
       Transform AKE2 ADDKE2 (ID = PQ_KEM_4)
       Transform AKE2 ADDKE2 (ID = NONE)
       Transform AKE3 ADDKE3 (ID = PQ_KEM_5)
       Transform AKE3 ADDKE3 (ID = PQ_KEM_6)
       Transform AKE3 ADDKE3 (ID = NONE)
                      <--- HDR(IKE_SA_INIT), SAr1(.. AKE*...), ADDKE*...),
                           KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
                           N(INTERMEDIATE_EXCHANGE_SUPPORTED)
                           Proposal #1
                             Transform ECR (ID = ENCR_AES_GCM_16,
                                            256-bit key)
                             Transform PRF (ID = PRF_HMAC_SHA2_512)
                             Transform KE (ID = Curve25519)
                             Transform AKE1 ADDKE1 (ID = PQ_KEM_2)
                             Transform AKE2 ADDKE2 (ID = NONE)
                             Transform AKE3 ADDKE3 (ID = PQ_KEM_5)

   HDR(IKE_INTERMEDIATE), SK {KEi(1)(PQ_KEM_2)} -->
                      <--- HDR(IKE_INTERMEDIATE), SK {KEr(1)(PQ_KEM_2)}
   HDR(IKE_INTERMEDIATE), SK {KEi(2)(PQ_KEM_5)} -->
                      <--- HDR(IKE_INTERMEDIATE), SK {KEr(2)(PQ_KEM_5)}

   HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } --->
                         <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2,
                              TSi, TSr }

   In this particular example, the responder chooses to perform two
   additional key exchanges.  It selects PQ_KEM_2, NONE NONE, and PQ_KEM_5
   for the first, second second, and third additional key exchanges exchanges,
   respectively.  As per [RFC7296] specification, [RFC7296], a set of keying materials are is
   derived, in particular SK_d, SK_a[i/r], and SK_e[i/r].  Both peers
   then perform an IKE_INTERMEDIATE exchange exchange, carrying PQ_KEM_2 payload payload,
   which is protected with SK_e[i/r] and SK_a[i/r] keys.  After the
   completion of this IKE_INTERMEDIATE exchange, the SKEYSEED is updated
   using SK(1), which is the PQ_KEM_2 shared secret, as follows.

   SKEYSEED(1) = prf(SK_d, SK(1) | Ni | Nr)

   The updated SKEYSEED value is then used to derive the following
   keying materials materials.

   {SK_d(1) | SK_ai(1) | SK_ar(1) | SK_ei(1) | SK_er(1) | SK_pi(1) |
    SK_pr(1)} = prf+ (SKEYSEED(1), Ni | Nr | SPIi | SPIr)

   As per [RFC9242] specification, [RFC9242], both peers compute IntAuth_i1 and IntAuth_r1 using
   the SK_pi(1) and SK_pr(1) keys keys, respectively.  These values are
   required in the IKE_AUTH phase of the exchange.

   In the next IKE_INTERMEDIATE exchange, the peers use SK_e[i/r](1) and
   SK_a[i/r](1) keys to protect the PQ_KEM_5 payload.  After completing
   this exchange, keying materials are updated as below follows:

   SKEYSEED(2) = prf(SK_d(1), SK(2) | Ni | Nr)
   {SK_d(2) | SK_ai(2) | SK_ar(2) | SK_ei(2) | SK_er(2) | SK_pi(2) |
       SK_pr(2)} = prf+ (SKEYSEED(2), Ni | Nr | SPIi | SPIr)

   where

   In this update, SK(2) is the shared secret from the third additional
   key exchange, i.e. i.e., PQ_KEM_5.  Both  Then, both peers then compute the values of
   IntAuth_[i/r]2 using the SK_p[i/r](2) keys.

   After the completion of the second IKE_INTERMEDIATE exchange, both
   peers continue to the IKE_AUTH exchange phase.  As defined in
   [RFC9242], the values IntAuth_[i/r]2 are used to compute IntAuth
   which IntAuth,
   which, in turn turn, is used to calculate the payload to be signed or MACed,
   i.e. InitiatorSignedOctets and ResponderSignedOctets.
   ResponderSignedOctets blobs (see Section 3.3.2 of [RFC9242]).

A.2.  No Additional Key Exchange Used

   The initiator proposes two sets of optional additional key exchanges,
   but the responder does not support any of them.  The responder
   chooses NONE for each set and consequently, set.  Consequently, the IKE_INTERMEDIATE
   exchange does not takes place take place, and the exchange proceeds to the
   IKE_AUTH phase.  The resulting keying materials are the same as those
   derived with [RFC7296].

   Initiator                     Responder
   ---------------------------------------------------------------------
   HDR(IKE_SA_INIT), SAi1(.. AKE*...), ADDKE*...), --->
   KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
   N(INTERMEDIATE_EXCHANGE_SUPPORTED)
     Proposal #1
       Transform ECR (ID = ENCR_AES_GCM_16,
                      256-bit key)
       Transform PRF (ID = PRF_HMAC_SHA2_512)
       Transform KE (ID = Curve25519)
       Transform AKE1 ADDKE1 (ID = PQ_KEM_1)
       Transform AKE1 ADDKE1 (ID = PQ_KEM_2)
       Transform AKE1 ADDKE1 (ID = NONE)
       Transform AKE2 ADDKE2 (ID = PQ_KEM_3)
       Transform AKE2 ADDKE2 (ID = PQ_KEM_4)
       Transform AKE2 ADDKE2 (ID = NONE)
                      <--- HDR(IKE_SA_INIT), SAr1(.. AKE*...), ADDKE*...),
                           KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
                           N(INTERMEDIATE_EXCHANGE_SUPPORTED)
                             Proposal #1
                               Transform ECR (ID = ENCR_AES_GCM_16,
                                              256-bit key)
                               Transform PRF (ID = PRF_HMAC_SHA2_512)
                               Transform KE (ID = Curve25519)
                               Transform AKE1 ADDKE1 (ID = NONE)
                               Transform AKE2 ADDKE2 (ID = NONE)

   HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } --->
                      <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2,
                           TSi, TSr }

A.3.  Additional Key Exchange in the CREATE_CHILD_SA Exchange only Only

   The exchanges below show that the initiator does not propose the use
   of additional key exchanges to establish an IKE SA, but they are
   required in order to establish a Child SA.  In order to establish a
   fully quantum-resistant IPsec SA, the responder includes a
   CHILDLESS_IKEV2_SUPPORTED notification in their IKE_SA_INIT response
   message.  The initiator understands and supports this notification,
   then
   exchanges a modified IKE_AUTH message with the responder responder, and rekeys
   the IKE SA immediately with additional key exchanges.  Any Child SA
   will have to be created via a subsequent CREATED_CHILD_SA exchange.

   Initiator                     Responder
   ---------------------------------------------------------------------
   HDR(IKE_SA_INIT), SAi1, --->
   KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED)
                      <--- HDR(IKE_SA_INIT), SAr1,
                           KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
                           N(CHILDLESS_IKEV2_SUPPORTED)

   HDR(IKE_AUTH), SK{ IDi, AUTH  } --->
                      <--- HDR(IKE_AUTH), SK{ IDr, AUTH }

   HDR(CREATE_CHILD_SA),
         SK{ SAi(.. AKE*...), ADDKE*...), Ni, KEi(Curve25519) } --->
     Proposal #1
       Transform ECR (ID = ENCR_AES_GCM_16,
                      256-bit key)
       Transform PRF (ID = PRF_HMAC_SHA2_512)
       Transform KE (ID = Curve25519)
       Transform AKE1 ADDKE1 (ID = PQ_KEM_1)
       Transform AKE1 ADDKE1 (ID = PQ_KEM_2)
       Transform AKE2 ADDKE2 (ID = PQ_KEM_5)
       Transform AKE2 ADDKE2 (ID = PQ_KEM_6)
       Transform AKE2 ADDKE2 (ID = NONE)
                      <--- HDR(CREATE_CHILD_SA), SK{ SAr(.. AKE*...), ADDKE*...),
                           Nr, KEr(Curve25519),
                           N(ADDITIONAL_KEY_EXCHANGE)(link1) }
                             Proposal #1
                               Transform ECR (ID = ENCR_AES_GCM_16,
                                              256-bit key)
                               Transform PRF (ID = PRF_HMAC_SHA2_512)
                               Transform KE (ID = Curve25519)
                               Transform AKE1 ADDKE1 (ID = PQ_KEM_2)
                               Transform AKE2 ADDKE2 (ID = PQ_KEM_5)

   HDR(IKE_FOLLOWUP_KE), SK{ KEi(1)(PQ_KEM_2), --->
   N(ADDITIONAL_KEY_EXCHANGE)(link1) }
                     <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(1)(PQ_KEM_2),
                           N(ADDITIONAL_KEY_EXCHANGE)(link2) }

   HDR(IKE_FOLLOWUP_KE), SK{ KEi(2)(PQ_KEM_5), --->
   N(ADDITIONAL_KEY_EXCHANGE)(link2) }
                     <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(2)(PQ_KEM_5) }

A.4.  No Matching Proposal for Additional Key Exchanges

   The initiator proposes the combination of PQ_KEM_1, PQ_KEM_2,
   PQ_KEM_3, and PQ_KEM_4 as the additional key exchanges.  The
   initiator indicates that either PQ_KEM_1 or PQ_KEM_2 must be used to
   establish an IKE SA, but Additional Key Exchange 2 ADDKE2 Transform Type is optional so optional.
   Therefore, the responder can either select PQ_KEM_3 or PQ_KEM_4 or
   omit this key exchange by selecting NONE.  The responder, although  Although the responder
   supports the optional PQ_KEM_3 and PQ_KEM_4 methods, it does not
   support either the PQ_KEM_1 or the PQ_KEM_2 mandatory method and therefore method;
   therefore, it responds with a NO_PROPOSAL_CHOSEN notification.

   Initiator                     Responder
   ---------------------------------------------------------------------
   HDR(IKE_SA_INIT), SAi1(.. AKE*...), ADDKE*...), --->
   KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
   N(INTERMEDIATE_EXCHANGE_SUPPORTED)
     Proposal #1
       Transform ECR (ID = ENCR_AES_GCM_16,
                      256-bit key)
       Transform PRF (ID = PRF_HMAC_SHA2_512)
       Transform KE (ID = Curve25519)
       Transform AKE1 ADDKE1 (ID = PQ_KEM_1)
       Transform AKE1 ADDKE1 (ID = PQ_KEM_2)
       Transform AKE2 ADDKE2 (ID = PQ_KEM_3)
       Transform AKE2 ADDKE2 (ID = PQ_KEM_4)
       Transform AKE2 ADDKE2 (ID = NONE)
                            <--- HDR(IKE_SA_INIT), N(NO_PROPOSAL_CHOSEN)

Appendix B.  Design Criteria

   The design of the extension is driven by the following criteria:

   1)   Need for PQC in IPsec. IPsec

        Quantum computers, which might become feasible in the near
        future, pose a threat to our classical public key cryptography.
        PQC, a family of public key cryptography that is believed to be
        resistant against to these computers, needs to be integrated into the
        IPsec protocol suite to restore confidentiality and
        authenticity.

   2)   Hybrid.   Hybrid

        There is currently no post-quantum key exchange that is trusted
        at the level that (EC)DH is trusted for defending against
        conventional (non-quantum) adversaries.  A hybrid post-quantum
        algorithm to be introduced introduced, along with the well-established
        primitives
        primitives, addresses this concern, since the overall security
        is at least as strong as each individual primitive.

   3)   Focus on post-quantum confidentiality. confidentiality

        A passive attacker can store all monitored encrypted IPsec
        communication today and decrypt it once a quantum computer is
        available in the future.  This attack can have serious
        consequences that will not be visible for years to come.  On the
        other hand, an attacker can only perform active attacks attacks, such as
        impersonation of the communicating peers peers, once a quantum
        computer is available, available sometime in the future.  Thus, this
        specification focuses on confidentiality due to the urgency of
        this problem and presents a defense against the serious attack
        described above, but it does not address authentication since because
        it is less urgent at this stage.

   4)   Limit the amount of exchanged data. data

        The protocol design should be such that the amount of exchanged
        data, such as public-keys, public keys, is kept as small as possible possible, even if
        the initiator and the responder need to agree on a hybrid group
        or if multiple public-keys public keys need to be exchanged.

   5)   Not post-quantum specific. specific

        Any cryptographic algorithm could be potentially broken in the
        future by currently unknown or impractical attacks: quantum attacks.  Quantum
        computers are merely the most concrete example of this.  The
        design does not categorize algorithms as "post-quantum" or "non post-quantum" "non-
        post-quantum", nor does it create assumptions about the
        properties of the algorithms, algorithms; meaning that if algorithms with
        different properties become necessary in the future, this
        extension can be used unchanged to facilitate migration to those
        algorithms.

   6)   Limited amount of changes. changes

        A key goal is to limit the number of changes required when
        enabling a post-quantum handshake.  This ensures easier and
        quicker adoption in existing implementations.

   7)   Localized changes. changes

        Another key requirement is that changes to the protocol are
        limited in scope, in particular, limiting changes in the
        exchanged messages and in the state machine, so that they can be
        easily implemented.

   8)   Deterministic operation. operation

        This requirement means that the hybrid post-quantum exchange, and exchange
        and, thus, the computed keys, keys will be based on algorithms that
        both client and server wish to support.

   9)   Fragmentation support. support

        Some PQC algorithms could be relatively bulky and they might require
        fragmentation.  Thus, a design goal is the adaptation and
        adoption of an existing fragmentation method or the design of a
        new method that allows for the fragmentation of the key shares.

   10)  Backwards  Backward compatibility and interoperability. interoperability

        This is a fundamental requirement to ensure that hybrid post-quantum post-
        quantum IKEv2 and standard IKEv2 implementations as per
        [RFC7296]
        specification are interoperable.

   11)  Compliance with USA Federal Information Processing Standards
        (FIPS) compliance.

        IPsec is widely used in Federal Information Systems Systems, and FIPS
        certification is an important requirement.  However, at the time
        of writing, none of the algorithms that is believed to be post-
        quantum is yet FIPS compliant yet. compliant.  Nonetheless, it is possible to
        combine this post-quantum algorithm with a FIPS compliant FIPS-compliant key
        establishment method so that the overall design remains FIPS
        compliant [NISTPQCFAQ].

   12)  Ability to use this method with multiple classical (EC)DH key
        exchanges.
        exchanges

        In some situations situations, peers have no single single, mutually
        trusted trusted, key
        exchange algorithm (e.g., due to local policy restrictions).
        The ability to combine two (or more) key exchange methods in
        such a way that the resulting shared key depends on all of them
        allows peers to communicate in this situation.

Appendix C.  Alternative Design

   This section gives an overview on a number of alternative approaches
   that have been considered, considered but later discarded.  These approaches
   are: are
   as follows.

   *  Sending the classical and post-quantum key exchanges as a single
      transform

      A method to combine the various key exchanges into a single large
      KE payload was considered; this considered.  This effort is documented in a
      previous version of this draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). document (draft-tjhai-ipsecme-hybrid-
      qske-ikev2-01).  This does allow method allows us to cleanly apply hybrid key
      exchanges during the Child SA; however SA.  However, it does add considerable complexity,
      complexity and requires an independent fragmentation solution.

   *  Sending post-quantum proposals and policies in the KE payload only

      With the objective of not introducing unnecessary notify payloads,
      a method to communicate the hybrid post-quantum proposal in the KE
      payload during the first pass of the protocol exchange was
      considered.  Unfortunately, this design is susceptible to the
      following downgrade attack.  Consider the scenario where there is
      an on-path attacker sitting between an initiator and a responder.
      The initiator proposes, through
      Through the SAi payload, to use the initiator proposes using a hybrid post-
      quantum
      post-quantum group and and, as a fallback fallback, a Diffie-Hellman group, group; and
      through the KEi payload, the initiator proposes a list of hybrid post-
      quantum
      post-quantum proposals and policies.  The on-path attacker
      intercepts this traffic and replies with N(INVALID_KE_PAYLOAD) N(INVALID_KE_PAYLOAD),
      suggesting to a downgrade to the fallback Diffie-Hellman group
      instead.  The initiator then resends the same SAi payload and the
      KEi payload containing the public value of the fallback Diffie-Hellman Diffie-
      Hellman group.  Note that the attacker may forward the second
      IKE_SA_INIT message only to the responder, and therefore responder.  Therefore, at this
      point in time, the responder will not have the information that
      the initiator prefers the hybrid group.  Of course, it is possible
      for the responder to have a policy to reject an IKE_SA_INIT
      message that (a) offers a hybrid group but does not offering offer the
      corresponding public value in the KEi payload; payload and (b) the
      responder has not specifically acknowledged that it does not supported
      support the requested hybrid group.  However, the checking of this
      policy introduces unnecessary protocol complexity.  Therefore, in
      order to fully prevent any downgrade attacks, using a KE payload
      alone is not
      sufficient sufficient, and that the initiator MUST always indicate
      its preferred post-quantum proposals and policies in a notify
      payload in the subsequent IKE_SA_INIT messages following a an
      N(INVALID_KE_PAYLOAD) response.

   *  New payload types to negotiate hybrid proposal proposals and to carry post-
      quantum public values

      Semantically, it makes sense to use a new payload type, which
      mimics the SA payload, to carry a hybrid proposal.  Likewise,
      another new payload type that mimics the KE payload, payload could be used
      to transport hybrid public value.  Although, in theory theory, a new
      payload type could be made backwards backward compatible by not setting its
      critical flag as per Section 2.5 of [RFC7296], it is believed that
      it may not be that simple in practice.  Since the original release
      of IKEv2 in RFC4306, RFC 4306, no new payload type has ever been proposed
      and proposed;
      therefore, this creates a potential risk of having a backward backward-
      compatibility issue from non-conformant nonconformant IKEv2 implementations.
      Since there appears to be no other compelling advantages apart
      from a semantic one, the existing transform type Transform Type and notify
      payloads are used instead.

   *  Hybrid public value payload

      One way to transport the negotiated hybrid public payload, which
      contains one classical Diffie-Hellman public value and one or more
      post-quantum public values, is to bundle these into a single KE
      payload.  Alternatively, these could also be transported in a
      single new hybrid public value payload, but payload.  However, following the
      same reasoning as above, this above may not be a good idea from a backward backward-
      compatibility perspective.  Using a single KE payload would
      require an encoding or formatting to be defined so that both peers
      are able to compose and extract the individual public values.
      However, it is believed that it is cleaner to send the hybrid
      public values in multiple KE payloads--one payloads: one for each group or
      algorithm.  Furthermore, at this point in the protocol exchange,
      both peers should have indicated support of for handling multiple KE
      payloads.

   *  Fragmentation

      Handling

      The handling of large IKE_SA_INIT messages has been one of the
      most challenging tasks.  A number of approaches have been considered
      considered, and the two prominent ones that have been discarded
      are outlined as follows.

      The first approach is to treat the entire IKE_SA_INIT message as a
      stream of bytes, which is then split it into a number of fragments,
      each of which is wrapped onto a payload that will fit into the
      size of the network MTU.  The payload that wraps each fragment has
      a new payload type type, and it is envisaged that this new payload type
      will not cause a backward compatibility backward-compatibility issue because because, at this
      stage of the protocol, both peers should have indicated support of
      fragmentation in the first pass of the IKE_SA_INIT exchange.  The
      negotiation of fragmentation is performed using a notify payload,
      which also defines supporting parameters parameters, such as the size of
      fragment in octets and the fragment identifier.  The new payload
      that wraps each fragment of the messages in this exchange is
      assigned the same fragment identifier.  Furthermore, it also has
      other parameters parameters, such as a fragment index and total number of
      fragments.  This approach has been discarded due to its blanket
      approach to fragmentation.  In cases where only a few payloads
      need to be fragmented, this approach appears to be overly
      complicated.

      Another idea that has been discarded was is fragmenting an individual
      payload without introducing a new payload type.  The idea is to
      use the 9-th bit (the bit after the critical flag in the RESERVED
      field) in the generic payload header as a flag to mark that this
      payload is fragmented.  As an example, if a KE payload is to be
      fragmented, it may look as follows.

                       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Next Payload  |C|F| RESERVED  |         Payload Length        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Diffie-Hellman Group Number  |     Fragment Identifier       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Fragment Index        |        Total Fragments        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Total KE Payload Data Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                       Fragmented KE Payload                   ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: Example of How to Fragment a KE Payload

      When the flag F is set, this means the current KE payload is a fragment of a
      larger KE payload.  The Payload Length field denotes the size of
      this payload fragment in octets--including octets: including the size of the generic
      payload header.  The two-octet 2-octet RESERVED field following Diffie-Hellman Diffie-
      Hellman Group Number was to be used as a fragment identifier to
      help the assembly and disassembly of fragments.  The Fragment
      Index and Total Fragments fields are self-explanatory.  The Total
      KE Payload Data Length indicates the size of the assembled KE
      payload data in octets.  Finally, the actual fragment is carried
      in Fragment KE Payload field.

      This approach has been discarded because it is believed that the
      working group may not want to use the RESERVED field to change the
      format of a packet packet, and that implementers may not like the added
      complexity from checking the fragmentation flag in each received
      payload.  More importantly, fragmenting the messages in this way
      may leave the system to be more prone to denial of service denial-of-service (DoS)
      attacks.  By  This issue can be solved using IKE_INTERMEDIATE
      [RFC9242] to transport the large post-
      quantum post-quantum key exchange payloads,
      payloads and using the generic IKEv2 fragmentation protocol [RFC7383] solve the issue.
      [RFC7383].

   *  Group sub-identifier

      As discussed before, each group identifier is used to distinguish
      a post-quantum algorithm.  Further classification could be made on
      a particular post-quantum algorithm by assigning an additional
      value alongside the group identifier.  This sub- identifier sub-identifier value
      may be used to assign different security parameter security-parameter sets to a given post-
      quantum
      post-quantum algorithm.  However, this level of details detail does not
      fit the principles of the document where it should deal with
      generic hybrid key exchange protocol, protocol and not a specific
      ciphersuite.  Furthermore, there are enough Diffie- Hellman Diffie-Hellman group
      identifiers should this be required in the future.

Acknowledgements

   The authors would like to thank Frederic Detienne and Olivier Pelerin
   for their comments and suggestions, including the idea to negotiate
   the post-quantum algorithms using the existing KE payload.  The
   authors are also grateful to Tobias Heider and Tobias Guggemos for
   valuable comments.  Thanks to Paul Wouters for reviewing the
   document.

Authors' Addresses

   C.

   CJ. Tjhai
   Post-Quantum
   Email: cjt@post-quantum.com

   M.

   Martin Tomlinson
   Post-Quantum
   Email: mt@post-quantum.com

   G.

   Graham Bartlett
   Quantum Secret
   Email: graham.ietf@gmail.com

   S.

   Scott Fluhrer
   Cisco Systems
   Email: sfluhrer@cisco.com

   D.

   Daniel Van Geest
   ISARA Corporation
   Email: daniel.vangeest@isara.com

   O. daniel.vangeest.ietf@gmail.com

   Oscar Garcia-Morchon
   Philips
   Email: oscar.garcia-morchon@philips.com

   Valery Smyslov
   ELVIS-PLUS
   Email: svan@elvis.ru