wdiff draft-tjhai-ipsecme-hybrid-qske-ikev2-01.txt draft-tjhai-ipsecme-hybrid-qske-ikev2-02.txt

Internet Engineering Task Force C. Tjhai
Internet-Draft M. Tomlinson
Intended Status: status: Informational Post-Quantum
Expires: July 19, 2018 January 2, 2019 G. Bartlett
S. Fluhrer
Cisco Systems
D. Van Geest
ISARA Corporation
Z. Zhang
Onboard Security
O. Garcia-Morchon
Philips
January 15,
July 1, 2018

Framework to Integrate Post-quantum Key Exchanges into Internet Key
Exchange Protocol Version 2 (IKEv2)
draft-tjhai-ipsecme-hybrid-qske-ikev2-01
draft-tjhai-ipsecme-hybrid-qske-ikev2-02

Abstract

This document describes how to extend Internet Key Exchange Protocol
Version 2 (IKEv2) so that the shared secret exchanged between peers
has resistance against quantum computer attacks. The basic idea is
to exchange one or more post quantum post-quantum key exchange payloads in
conjunction with the existing (Elliptic Curve) Diffie-Hellman
payload. This document also addresses the challenge of fragmentation
as a result of sending large post quantum key exchange data in the
first pair of message of the initial exchange phase.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 19, 2018. January 2, 2019.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2
1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3 2
1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . . 3
1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Document organization . . . . . . . . . . . . . . . . . . 4
2. Design criteria . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Framework of Hybrid Post-quantum Key Exchange . . . . . . 6
3.1. Overall design . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. First Protocol Round . . . . . . . . . . . . . . . . . 7 8
3.2.2. Second Protocol Round . . IKE_AUX round . . . . . . . . . . . . . . 10
3.2.3. Child SA Negotiation . . . . . . 10
3.2.3. IKE_AUX exchange . . . . . . . . . . . 11
3.3. Computation of a Post-Quantum Shared Secret . . . . . . . 12
3.4. Post-Quantum 11
3.3. Post-quantum Group Transform Type and Group Identifiers . 12
3.5. 11
3.4. Hybrid Group Negotiation . . . . . . . . . . . . . . . . . 13
3.5.1. Protocol for the Initiator . . . . . . . . . . . . . . 14
3.5.2. Protocol from the Responder . . . . . . . . . . . . . . 17
3.6. Fragmentation Support . . . . . . . . . . . . . . . . . . 19
3.6.1. Fragmentation Problem Description . . . . . . . . . . 19
3.6.2. Fragmentation Solution . . . . . . . . . . . . . . . . 19
3.6.2.1. Fragmentation Pointer Payload . . . . . . . . . . 19
3.6.2.2. Fragmentation Body Payload . . . . . . . . . . . . 20
3.6.2.3. Fragmentation Semantics . . . . . . . . . . . . . 23
3.6.2.4. IKE AUTH Processing . . . . . . . . . . . . . . . 24
3.6.2.5. Design Rationale . . . . 12
3.5. Child SAs . . . . . . . . . . . . . 25
3.7. Protection against Downgrade Attacks . . . . . . . . . . . 25 12
4. Alternative Design . . . . . . . . . . . . . . . . . . . . . . 28 12
5. Security considerations . . . . . . . . . . . . . . . . . . . 31 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 34 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 18

1. Introduction

1.1. Problem Description

Internet Key Exchange Protocol (IKEv2) as specified in RFC 7296
[RFC7296] uses the Diffie-Hellman (DH) or Elliptic Curve Diffie-
Hellman (ECDH) algorithm to establish a shared secret between an
initiator and a responder. The security of the DH and ECDH
algorithms relies on the difficulty to solve a discrete logarithm
problem in multiplicative and elliptic curve groups respectively when
the order of the group parameter is large enough. While solving such
a problem remains difficult with current computing power, it is
believed that 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. This family of
cryptosystems are known as post-quantum cryptography (PQC). It is
sometime
ometime also referred to as quantum-safe cryptography (QSC) or
quantum-resistant cryptography (QRC).

1.2. Proposed Extension

This document describes a framework to integrate QSC for IKEv2,
whilst while
maintaining backwards compatibility, to exchange derive a shared
secret such set of IKE keys that it has
have resistance to quantum computer attacks. Our framework allows
the negotiation of one or more QSC algorithm to exchange data, in
addition to the existing DH or ECDH key exchange data. We believe
that the feature of using more than one post
quantum post-quantum algorithm is
important as many of these algorithms are relatively new and there
may be a need to hedge the security risk with multiple key exchange
data from several distinct QSC algorithms.

The secrets established from each key exchange are combined in a way
such that should the post quantum post-quantum secrets not be present, the derived
shared secret is equivalent to that of the standard IKEv2; on the
other hand, a post quantum post-quantum shared secret is obtained if both
classical and post quantum post-quantum key exchange data are present. This
framework also applies to key exchanges in IKE Security Associations
(SAs) for Encapsulating Security Payload (ESP) [ESP] or
Authentication Header (AH) [AH], i.e. Child SAs, in order to provide
a stronger guarantee of forward security.

One of the

Some post-quantum key challenges in this framework is fragmentation handling
during the first message pair of the initial exchange phase, i.e.
IKE_SA_INIT. Almost all of the known PQC algorithms to date payloads may have key
exchange data size that exceeds 1K octets. When transmitted
alongside other payloads, the total payload size could easily exceed larger than the common maximum transmission unit (MTU) size of 1500 octets,
standard MTU size, and
hence this may lead to therefore there could be issues with
fragmentation at IP level fragmentation. While IKEv2 has a
mechanism to handle layer. IKE does allow transmission over TCP
where fragmentation [RFC7383], it is applicable to
messages exchanged after IKE_SA_INIT. Of course, fragmentation will not be an issue if messages are sent over TCP [RFC8229]; however, we believe
that a UDP-based solution will also be required. This
document describes required too. IKE does have a simple
mechanism to fragment IKE_SA_INIT
messages, handle fragmentation within UDP [RFC7383], however that
is only applicable to messages exchanged after the IKE_SA_INIT. To
use this mechanism, we use the IKE_AUX exchange as outlined in
[I-D.smyslov-ipsecme-ikev2-aux]. With this mechanism, we do an
initial key exchange, using a smaller, possibly non-quantum resistant
primitive, such as ECDH. Then, before we do the IKE_AUTH exchange,
we perform one or more IKE_AUX exchanges, each of which also allows includes a
secondary key exchange. As the IKE_AUX exchange is encrypted, the
IKE fragmentation protocol RFC7383 can be used. The IKE SK values
will be updated after each exchange, and so the final IKE SK values
will depend on all the key exchanges, hence they are secure if any of
the key exchanges for payload larger than 65,535
octets. are secure.

Note that readers should consider the approach in this document as
providing a long term solution in upgrading the IKEv2 protocol to
support post quantum post-quantum algorithms. A short term solution to make IKEv2
key exchange quantum secure is to use post quantum post-quantum pre-shared keys as
discussed in [FMKS]. [I-D.ietf-ipsecme-qr-ikev2].

1.3. Changes

Changes in this draft in each version iterations.

draft-tjhai-ipsecme-hybrid-qske-ikev2-01

o Use IKE_AUX to perform multiple key exchanges in succession.

o Handle fragmentation by keeping the first key exchange (a standard
IKE_SA_INIT with a few extra notifies) small, and encrypting the
rest of the key exchanges.

o Simplify the negotiation of the 'extra' key exchanges.

draft-tjhai-ipsecme-hybrid-qske-ikev2-00

o We added a feature to allow more than one post quantum post-quantum key
exchange algorithms to be negotiated and used to exchange a post-
quantum shared secret.

o Instead of relying on TCP encapsulation to deal with IP level
fragmentation, we introduced a new key exchange payload that can
be sent as multiple fragments within IKE_SA_INIT message.

1.4. Document organization

The remainder of this document is organized as follows. Section 2
summarizes design criteria. Section 3 describes how post-quantum key
exchange is performed between two IKE peers, peers and how keying materials
are
derived and how downgrade attack derived. The rationale behind the approach of this extension is prevented. This section also
specifies we handle fragmentation
described in IKE_SA_INIT exchanges. A
number of alternative designs to Section 3, which we have considered
but not adopted, are discussed in 3. Section 4. Lastly, 4 discusses security considerations
an lastly, Section 5 discusses security considerations. IANA considerations for the name
spaces introduced in this document.

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119 [RFC2119].

2. Design criteria

The design of the proposed post-quantum IKEv2 is driven by the
following criteria:

1) Need for post-quantum cryptography in IPsec. Quantum computers
might become feasible in the next 5-10 years. If current
Internet communications are monitored and recorded today (D),
the communications could be decrypted as soon as a quantum-
computer is available (e.g., year Q) if key negotiation only
relies on non post-quantum primitives. This is a high threat
for any information that must remain confidential for a long
period of time T > Q-D. The need is obvious if we assume that Q
is 2040, D is 2020, and T is 30 years. Such a value of T is
typical in classified or healthcare data.

2) Hybrid. Currently, there does not exist a post-quantum key
exchange that is trusted at the level that ECDH is trusted
against conventional (non-quantum) adversaries. A hybrid
approach allows introducing promising post-quantum candidates
next to well-established primitives, since the overall security
is at least as strong as each individual primitive.

3) Focus on quantum-resistant confidentiality. A passive attacker
can eavesdrop on IPsec communication today and decrypt it once a
quantum computer is available in the future. This is a very
serious attack for which we do not have a solution. An attacker
can only perform active attacks such as impersonation of the
communicating peers once a quantum computer is available,
sometime in the future. Thus, our design focuses on quantum-
resistant confidentiality due to the urgency of this problem.
This document does not address quantum-resistant authentication
since it is less urgent at this stage.

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

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

6) Identification of hybrid algorithms. The usage of a hybrid
approach in which each hybrid combination of several classical
and post-quantum algorithms leads to a different group
identifier can lead to an exponential number of combinations.
Thus, the design should seek an approach in which a hybrid group
-- comprising multiple post-quantum algorithms -- can be
efficiently negotiated.

7) Limited amount of 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. 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. This requirement means that the hybrid
post-quantum exchange, and thus, the computed key, will be based
on algorithms that both client and server wish to support.

10)

9) Fragmentation 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.

11)

10) Backwards compatibility and interoperability. This is a
fundamental requirement to ensure that hybrid post-quantum IKEv2
and a non-post-quantum IKEv2 implementations are interoperable.

12)

11) FIPS compliance. IPsec is widely used in Federal Information
Systems and FIPS certification is an important requirement.
However, algorithms that are believed to be post-quantum are not
FIPS compliant yet. Still, the goal is that the overall hybrid
post-quantum IKEv2 design can be FIPS compliant.

3. The Framework of Hybrid Post-quantum Key Exchange

3.1. Overall design
The

This design assigns new group identifiers (Transform Type 4) to the
various post-quantum key exchanges (which will be defined later). We
specifically do not make a distinction between classical (DH and
ECDH) and post-quantum key exchanges, nor post-quantum algorithms
which are true key exchanges versus post-quantum algorithms that act
as key transport mechanisms; all are treated equivalently by the
protocol. In order to support both hybrid key exchanges (that is,
relying on distinct key exchanges) and fragmentation, the proposed
hybrid post-quantum IKEv2 protocol extends RFC7296 IKE [RFC7296] by duplicating the initial adding
additional key exchange in [RFC7296]. messages (IKE_AUX) between the IKE_SA_INIT
and the IKE_AUTH exchanges. In order to minimize communication
overhead, only the key shares that are agreed to be used are actually
exchanged. In order to achieve this, the IKE_SA_INIT exchange now consists of two message exchange pairs.
The first pair of IKE_SA_INIT messages negotiates which classical
cryptographic algorithms are
includes notify payloads that negotiate the extra key exchanges to be used, along with the supported PQC
algorithms by initiator and responder, and policies of the initiator
that specify its requirements on a hybrid group.
used. The second initiator IKE_SA_INIT message pair, on includes a notify that lists
the other hand, consists of each peer
sending extra key exchange policy required by the Diffie-Hellman public value along with initiator; the post-quantum
key-shares. Note that no Diffie-Hellman exchange or exchange
responder selects one of
post-quantum key-shares is performed the listed policies, and includes that as a
notify in the first round of response IKE_SA_INIT exchange. Messages are described as message 1 for message. Then, the
initiator's first message, message 2 for initiator and
the responder's first
message, message 3 responder perform one (or possibly more) IKE_AUX exchange; each
such exchange includes a KE payload for the initiator's second message and message 4
for key exchange that was
negotiated.

Here is an overview of the responder's second message. initial exchanges:

Initiator Responder
--------------------------------------------------------------
--------------------------------------------------------
<-- First round (hybrid group IKE_SA_INIT (and extra key exchange negotiation) -->

<-- Second round {IKE_AUX (hybrid quantum-safe post-quantum key exchange) exchange)} -->

This hybrid
...
<-- {IKE_AUX (hybrid post-quantum IKEv2 key exchange can occur in IKE_SA_INIT
or CREATE_CHILD_SA message pair which contains various payloads for
negotiating cryptographic algorithms, exchanging nonces, and
performing a Diffie-Hellman shared secret exchange for an IKE SA or a
Child SA. These payloads are chained together forming a linked-list
and this flexible structure allows additional key exchange payloads
to be introduced. exchange)} -->

<-- {IKE_AUTH} -->

The additional extra post-quantum key exchange uses exchanges can use algorithms that are
currently considered to be resistant to quantum computer attacks.
These algorithms are collectively referred to as post-quantum
algorithms in this document.

3.2. Overall Protocol

In the simplest case, the initiator is happy with a single key
exchange (and has no interest in supporting multiple), and he is not
concerned with possible fragmentation of the IKE_SA_INIT messages
(either because the key exchange he selects is small enough not to
fragment, or he is confident that fragmentation will be handled
either by IP fragmentation, or transport via TCP). In the following
we overview the two protocol rounds involved in the hybrid post-quantum post-
quantum protocol.

In this case, the initiator performs the IKE_SA_INIT as standard,
inserting this prefered key exchange (which is possibly a post-
quantum algorithm) as the listed Transform Type 4, and including the
initiator KE payload. If the responder accepts the policy, he
responds with an IKE_SA_INIT response, and IKE continues as usual.

If the initiator desires to negotiate multiple key exchanges, or he
needs IKE to handle any possible fragmentation, then he uses the
protocol listed below.

3.2.1. First Protocol Round

In the first round, the IKE_SA_INIT request and response messages are
used to
negotiate the hybrid group. The method to negotiate and
exchange post-quantum policies is achieved using initial IKE SAs (as currently), as well as the key exchange
payload (with a Diffie-Hellman Group Num of #TBA). The KE payload
with group number #TBA does not contain Diffie-Hellman or post-
quantum public values, but proposed post-quantum algorithms and the
policy for
exchanges that will be used within the post-quantum ciphers. IKE_AUX phase below.

The initiator negotiates cryptographic suites as per RFC7296, the
only exception is, the Diffie-Hellman KE payload is not populated with a keyshare, but rather
the listed Transform Type 4 (and KE payload contains the proposed
post-quantum algorithms and policies. The Diffie-Hellman groups are
negotiated in the security association payload as per RFC7296 and the
public values sent in payload) being either the next round first
key exchange on his desired list of exchange.

When a responder that supports the hybrid exchange, receives an
IKE_SA_INIT message with a KE payload with group number #TBA, it
performs key exchanges, or alternatively a lookup of the policies and algorithms contained within the
KE payload. Assuming that it supports
small classical one or more proposed post-
quantum algorithms, it then indicates these in the KE payload
response with group number #TBA. The responder also selects the
cryptographic suites, including the chosen Diffie-Hellman Group Num
in (in order to enable fragmentation support of the security association payload as per RFC7296.
later key exchanges). In this exchange
the Diffie-Hellman public value is not sent in addition, the KE payload.

The initiator can signal support of initial IKE_SA_INIT message fragmentation
by including a payload fragmentation Notify payload. The responder
can also
will include this the following two Notify payload to indicate support of
IKE_SA_INIT message fragmentation. payloads:

o The responder may choose to allocate state to the session, N(AUX_EXCHANGE_SUPPORTED) notify, as the
initial message is used specified in authenticating
[I-D.smyslov-ipsecme-ikev2-aux]. This draft makes no requirements
about the IKE SA messages.
Optionally, included data.

o An N(EXTRA_KEY_EXCHANGE_POLICY) notify, which has a Protocol ID
and SPI Size of 0, and includes the responder may prefer not below data.

This data will be the list of groups that the initiator is willing to allocate any state and
reply with a cookie instead. The cookie can provide two functions.
One being
negotiate during the standard RFC7296 behaviour. IKE_AUX phase below. The other benefit initiator signifies
this by specifying the specific list of using the cookie is sets of key exchanges
that he will allow. The list MUST be ordered from most prefered to provide fast detection
least prefered. This is encoded as a series of 2 byte values; a downgrade attack without
running into the risk
specified list of state exhaustion attacks. Whether or not
any states are allocated, acceptable groups is given as the responder detects specific
Transform IDs, followed by a 0x00 value. For example, if the NewHope
post-quantum
cryptographic algorithms and policies that do not match key exchange is 0x40, Round2 is 0x42, and can SIKE is 0x47,
then
abort the session prior to calculating the shared secrets. See
Section 3.7 for more information on cookie and downgrade attack
prevention.

Initiator Responder
--------------------------------------------------------------
HDR, SAi1, KEi(#TBA),
Ni, [N(Pay Frag)] -->

<-- HDR, SAr1, KE(#TBA),
Nr, [N(Pay Frag),]
[N(COOKIE)]

By using the KE payload, peers that do not support the hybrid
exchange data payload:

0040 0000
0042 0047 0000
0042 0000

will reject the initial negotiation and assuming signify that a
Diffie-Hellman Group Num contained in the Diffie-Hellman Group
Transform IDs was acceptable, the peer will send an
INVALID_KE_PAYLOAD message initiator is willing to indicate its preferred Diffie-Hellman
group. Note that using the KE payload enables backward compatibility perform IKE_AUX with existing RFC7296 implementations.
either NewHope, Round2 followed by SIKE, or only Round2.

If this scenario occurs, the initiator SHOULD retry is willing to skip the hybrid exchange. Dependent on policies, IKE_AUX phase, he can signify
that by including a 0000 value as a list; for example:

0040 0000
0042 0047 0000
0042 0000
0000

would signify either (NewHope), (Round2, SIKE), (Round2) or skipping
the initiator may retry IKE_AUX entirely.

When the exchange as per RFC7296, and if this
occurs then responder that supports the N(PQ_ALGO_POLICIES) notify payload MUST be included
to prevent downgrade attacks. The N(PQ_ALGO_POLICIES) notify payload
contains hybrid exchange receives an
IKE_SA_INIT message with the same post-quantum algorithms AUX_EXHANGE_SUPPORTED and policies that were sent
in
EXTRA_KEY_EXCHANGE_POLICY notifies, then (after processing the KE(#TBA) payload in IKE
message as normal), it scans through the first round of IKE_SA_INIT request.

On receipt of policy listed within the N(PQ_ALGO_POLICIES) payload,
EXTRA_KEY_EXCHANGE_POLICY Notify payload. If the responder MUST
validate these post-quantum algorithms and policies against finds a
list of key exchanges that is consistent with its own
policies. This validation is required to ensure that the post-
quantum algorithms were not amended in policy, it
includes N(AUX_EXCHANGE_SUPPORTED) and N(EXTRA_KEY_EXCHANGE_LIST)
notifies, which both have 0 Protocol IDs and SPI sizes. The data for
the initial exchange,
resulting in a downgrade attack.

Should EXTRA_KEY_EXCHANGE_LIST notify would have data specifying the proposed post-quantum algorithms not be
list of acceptable to the
responder, the responder SHOULD indicate this by sending Transform IDs as a series of 2 byte values. If
the
INVALID_KE_PAYLOAD Notify message responder's policy requires it to indicate its preferred Diffie-
Hellman group or the NO_PROPOSAL_CHOSEN Notify message if no Diffie-
Hellman group were acceptable. If perform the classical cryptographic suite
is acceptable, extra key exchange,
but none of the post-quantum algorithms key exchange lists are not, the responder
SHOULD indicate this by specifying the preferred Diffie-Hellman group acceptable, it returns an
error in a notification with type NO_PROPOSAL_CHOSEN.

For example, if the INVALID_KE_PAYLOAD notification. The initiator should single transform Round2 is accepted, then
revert to the classical IKEv2 exchange
data payload will consist of:

0042

If the set Round2 and include SIKE is accepted, then the
N(PQ_ALGO_POLICIES) data payload to prevent downgrade attacks. Below will
consist of:

0042 0047

If no IKE_AUX transforms is
an example that shows desired, then the proposed hybrid group data payload will be
empty (or alternatively no such notification is not supported by included, which
implies the same thing).

On success, the responder will create the IKE SA and that SK values based
on SAi1, SAr1 and KE payloads as normal.

When the responder prefers a Diffie-Hellman Group
19 (P-256), assuming that this group is in initiator receives the list proposed
(although reply IKE_SA_INIT message, it is checks
for the existence of the AUX_EXCHANGE_SUPPORTED and
EXTRA_KEY_EXCHANGE_LIST notifies. If those notifies are not preferred), in present,
then the previous message.

Initiator Responder
--------------------------------------------------------------
HDR, SAi1, KEi(#TBA),
Ni, [N(Pay Frag)] -->

<-- HDR, N(INVALID_KE_PAYLOAD, 19)
HDR, SAi1, KEi(19),
N(PQ_ALGO_POLICIES), -->
Ni

For implementations that mandate only initiator treats it as if no extra key exchanges were chosen
(and then can proceed by either rejecting the use of hybrid exchange,
these MUST not revert to or proceed
using the classical IKEv2 exchange. This
should be a configurable parameter in implementations.

As per RFC7296, should single negotiated key exchange, depending on local policy).

If those notifies are present, then the responder not accept any of the
cryptographic suites verifies that were sent in the security association
payload, a NO_PROPOSAL_CHOSEN message is responded, as depicted
below.

Initiator Responder
--------------------------------------------------------------
HDR, SAi1, KEi(#TBA),
Ni, [N(Pay Frag)] -->

<-- HDR, N(NO_PROPOSAL_CHOSEN)

3.2.2. Second Protocol Round

In
key exchanges listed within the second protocol round, EXTRA_KEY_EXCHANGE_LIST are one of
the initiator sends again options within its local policy; if so, it processes the
IKE_SA_INIT request. The main difference is that this message
includes the key-shares associated as normal, and then proceeds to each of the post-quantum
algorithms agreed in the previous IKE_AUX
round. Each key-share is
transported in a KE payload, and therefore there may exist multiple
KE payloads in the second round of

3.2.1.1. Note on responder policy check

One reason that the IKE_SA_INIT message.
Furthermore, these KE payloads initiator may be fragmented if the key-shares
are large and both peers indicate select the support of fragmentation.

In a general hybrid arrangement, the RFC7296 Diffie-Hellman public
value is sent in initial key exchange
(the type 4 transform within the first KE payload (denoted KEi1), with one or
more post-quantum key-share being sent in additional KE payloads
(denoted KEi2, KEi3, etc). However, this ordering SAi1 payload) is not mandatory.

If the responder sent a cookie in the first round of exchange, the
initiator MUST return this cookie. In addition for security,
but instead to that, the
initiator MUST send the same post-quantum algorithms and policies
that were included in the KE payload simply establish keys to allow fragmentation of type #TBA sent in the first
round
IKE_AUX message. Because of this possibility, if the exchange, in receiver sees a notify payload N(PQ_ALGO_POLICIES). The
responder MUST examine
list of key exchanges listed within the post-quantum algorithms and EXTRA_KEY_EXCHANGE_LIST that
satisfies its policies, and
confirm it SHOULD accept it (assuming that the presented KE payloads match those represented by the
cookie, see Section 3.7 for more information. Should an anomaly or a
mismatch be detected, the responder MUST abort the session. On the
other hand, SAi1
payload is otherwise acceptable), even if the validation passes, then key payload within the responder can proceed
SAi1 is not necessary according to compute a shared secret as detailed in Section 3.3.

The responder also sends the IKE_SA-INIT response message including its key-shares. As before, if policy.

3.2.2. IKE_AUX round

For each extra key exchange agreed and if required, fragmentation
is handled as described to in Section 3.6. Once the initiator has
received all key-shares from the responder, IKE_SA_INIT exchange,
the initiator can compute
the same shared secret following and the description in Section 3.3.

Below is responder perform an example message exchanged IKE_SA_AUX exchange, as
described in the second round of
IKE_SA_INIT message. [I-D.smyslov-ipsecme-ikev2-aux].

This exchange is as follows:

Initiator Responder
--------------------------------------------------------------
-------------------------------------------------
HDR, [N(COOKIE),] SAi1,
KEi1[, KEi2, ..., KEiX,]
Ni[, N(PQ_ALGO_POLICIES)] SK {Ni2, KEi2} -->
<-- HDR, SAr1, KEr1[, KEr2,
..., KErX,] Nr

For implementations that are to be used by peers that are pre-
configured with matching hybrid policies, resulting SK {Nr2, KEr2}

The initiator sends a nonce in the initial
exchange used to negotiate the post-quantum policies Ni2 payload, and algorithms
contained in the first round of exchanges being redundant, key exchange
payload in the
initiator can skip KEi2; the first round group id of exchanges by sending the
IKE_SA_INIT containing the key-shares. However the initiator MUST be
sure that the responder will accept the presented key-shares. In this
instance the responder is open to abuse by fragmentation related
attacks and KEi2 payload MUST revert to using the initial exchange, should it find
itself under any form of attack.

3.2.3. Child SA Negotiation

After the initial IKE SA is negotiated, either side may later
negotiate child SAs or rekey match the IKE SA which may involve a fresh
negotiated extra key exchange. If a hybrid group This packet is desired, then encrypted with the initiator proposes
current IKE SK keys.

On receiving this, the responder sends a Transform Type 4 (Diffie-Hellman) of (TBA); he includes nonce in the KE
payloads for Nr2 payload,
and the key exchange types that were negotiated for the
child SAs during the initial negotiation (see Section 3.5.1). The
responder replies payload KEr2; again, this packet is encrypted
with the corresponding KE payloads, and both use
the shared secrets to generate the child current IKE SA keying material (see
section 3.3). If hybrid groups were not initially negotiated as a
part of the initial key exchange, then child SAs MUST NOT propose a
hybrid group.

Specifically, the key keys.

Once this exchange for creating a child SA using a hybrid
group is:

Initiator Responder
--------------------------------------------------------------
HDR, SK{SA, Ni, KEi1, KEi2,
..., KEiN, TSi, TSr} -->
<-- HDR, SK{SA, Nr, KEr1, KEr2,
..., KErN, TSi, TSr}

where both SA payloads include a transform type 4 of (TBA), and the
KEi1, ..., KEiN, KEr1, ..., KErN are the KE types there were
initially negotiated.

3.3. Computation of a Post-Quantum Shared Secret

After the second protocol round detailed in Section 2.2., is done, then both
initiator and responder can sides compute the common shared secrets to
generate an SKEYSEED, from which all updated keying materials for protection
of the IKE SA are derived. The quantity SKEYSEED is computed as
follows:
material:

SKEYSEED = prf(Ni prf(SK_d(old), KE2result | Nr, SS1 Ni2 | SS2 | ...| SSN) Nr2)

where prf, Ni and Nr are defined as in IKEv2 [RFC7296], SSi
represents KE2result is the i-th shared secret computed from of the i-th key exchange
algorithm contained in the hybrid group that was negotiated in the
protocol. Note that if at least one of these SSi is a classical
shared secret that is FIPS approved, then FIPS compliance design
criteria as outlined in Section 2 is achieved. The seven secrets
derived from SKEYSEED, namely exchange. Then,
SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr, are generated as defined in IKEv2 [RFC7296].

For child SAs that SK_pr are negotiated using a hybrid group, the keying
material is defined updated as:

KEYMAT = prf+(SK_d, SS1 | SS2

{SK_d | ... SK_ai | SSN SK_ar | Ni SK_ei | Nr)

where SSi represents the i-th shared secret computed from the i-th
key exchange algorithm that was performed during the negotiation of
the child SA.

When rekeying an IKE SA using a hybrid group, the new SKEYSEED is
computed as:

SKEYSEED = prf(SK_d (old), SS1 SK_er | SS2 SK_pi | ... SK_pr}
= prf+ (SKEYSEED, Ni2 | SSN Nr2 | Ni SPIi | Nr)

where SSi represents SPIr)

Note that the i-th shared secret computed from negotiated transform types (the encryption type, hash
type, prf type) are not modified.

Both the i-th initiator and the responder will use this updated key values
for the next message.

If the EXTRA_KEY_EXCHANGE_LIST has negotiated more than one key
exchange, then this exchange algorithm that was is performed during once for every key exchange
on the negotiation of list.

3.2.3. IKE_AUX exchange

After the new IKE_AUX exchanges have completed, then the initiator and
the responder will perform an IKE_AUTH exchange. This exchange is
the standard IKE SA.

3.4. Post-Quantum exchange, except that the initiator and responder
signed octets are modified as described in
[I-D.smyslov-ipsecme-ikev2-aux].

3.3. Post-quantum Group Transform Type and Group Identifiers

In generating keying material within IKEv2, both initiator and
responder negotiate up to four cryptographic algorithms in the SA
payload of an IKE_SA_INIT or a CREATE_CHILD_SA exchange. One of the
negotiated algorithms is a Diffie-Hellman algorithm, which is used
for key exchange. This negotiation is done using the Transform Type
4 (Diffie-Hellman Group) where each Diffie-Hellman group is assigned
a unique value.

In order to enable a post-quantum key exchange in IKEv2, the various
post-quantum algorithms MUST be negotiated between two IKEv2 peers.
To this end, this draft assigns new meanings to various transforms of
transform type 4 ("Diffie-Hellman group"). It assigns identifiers to
each of the various post-quantum algorithms (even though they are not
actually Diffie-Hellman groups, they are methods of performing key
exchange). In addition, it assigns two artificial values that are
not actually key exchange mechanisms, but are used as a part of the
negotiation.

We expect that in the future, IANA will assign permanent values to
these transforms. Until it does, we will use the following mappings
in the 'reserved for private use space':

0x9000 HYBRID - this signifies that we are negotiating a hybrid
group, the details are listed in the KE payload.

The following values are reserved
for the below key exchanges: 0x9100
- 0xXXXX. The following abstract identifiers are used exchanges (which will need to illustrate
their usage be specified in our framework. Actual more
detail elsewhere). Official identifiers will be maintained by IANA
and updated during the NIST standardization process.

Name Number Key exchange
--------------------------------------------------
NIST_CANDIDATE_1 0x9100 The 1st candidate of
NIST PQC submission
NIST_CANDIDATE_2 0x9101 The 2nd candidate of
NIST PQC submission

Because we are using transforms in the private use space, both the
initiator and responder must include a vendor id with this payload:

d4 48 11 94 c0 c3 4c 9d d1 22 76 aa 9a 4e 80 d5

This payload is the MD5 hash of "IKEv2 Quantum Safe Key Exchange
v1"). If the other side does not include this vendor id, an
implementation MUST NOT process these private use transforms as
listed in this draft.

3.5.

3.4. Hybrid Group Negotiation

Most post-quantum key agreement algorithms are relatively new, and
thus are not fully trusted. There are also many proposed algorithms,
with different trade-offs and relying 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 the key agreement
algorithm not be as secure as expected). A hybrid solution allows us
to deal with this uncertainty by combining a classical key exchanges
with post-quantum key agreements.
However, there are many post-quantum proposals that when combined can
lead to many potential hybrid groups. Furthermore, different
organizations might have different requirements when using a hybrid
group. For instance, the type of underlying problem that is trusted,
the minimum number of algorithms that should be used in a hybrid
group, or the security strength of each of the algorithms. For these
reasons, hybrid groups might lead to many potential combinations
difficult to define, maintain and standardize. This motivates our
hybrid group negation protocol.

Our hybrid group negotiation protocol allows the initiator and
responder to agree on a common hybrid group based on their respective
policies. The protocol categorizes each type of key exchange into a
type T, which is based on the type of hard problem it relies upon.
We use the aforementioned abstract identifiers to illustrate the
idea.

Given this categorization of the key agreement protocols, initiator
and responder have security policies that define the minimum number
of post-quantum algorithms that they require in a hybrid group and
also one, as well as leaving open the types possibility of
multiple post-quantum key agreement protocols that they support (and
therefore, trust). exchanges.

The initiator and responder can then engage in a
simple protocol method that allows them we use to compute a common perform hybrid group
fulfilling their policies. The protocol for the initiator and
responder is described below.

Note that it would be possible for the responder to search for a
mutually acceptable combination without specifying the key exchange
types, however the algorithm to search for such a combination would
be considerably more complex. This design assumes that the security
policies of the initiator and the responder will rely on key
exchanges based upon distinct types of hard problems, and hence the
additional complexity of the more general algorithm is not warranted.

3.5.1. Protocol for the Initiator

To define the protocol, we first define a "DH_Group_List", this is a
list of groups of a specific type; it has the format:

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
+---------------------------------------------------------------+
| T | N |
+---------------------------------------------------------------+
| PQC_ID_1 | PQC_ID_2 |
~ ... ~ ... ~
| PQC_ID_N | 0 |
+---------------------------------------------------------------+

where
o T is the type of the groups that are in this list, with this
proposed encoding:

- 0x0001 is classical
- 0x0002 is lattice
- 0x0003 is code-based
- 0x0004 is isogeny-based
- 0x0005 is symmetric (preshared key)

o N is the number of groups that make up also addresses
the list. fragmentation issue. The semantics
of this proposal is that the initiator is proposing M different
types of groups; initial IKE_INIT messages do not have
any selection of one group from K different
types will be acceptable.

o PQC_ID_1, PQC_ID_2, PQC_ID_N, such as NIST_CANDIDATE_1, is the
identifier for the PQC algorithm to be used for negotiation, in
order of preference.

o 0 is padding, present if N is odd.

The semantics of this list is that these are the groups of PQC
algorithms of type T inherent fragmentation support within IKE; however that are acceptable to the initiator.

We now define a "DH_Group_Policy"; this is can
include a list of group types that
are negotiated together. It has the format:

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
+---------------------------------------------------------------+
| K | M |
+---------------------------------------------------------------+
| DH Group List 1 |
+---------------------------------------------------------------+
| DH Group List 2 |
~ ... ~
| DH Group List M |
+---------------------------------------------------------------+

where:
o K is the minimum number of group lists that must be satisfied;
o M is the number of group lists;
o DH_Group_LIST_1, ..., DH_Group_List_M are the lists of
different types of DH groups, in order of preference.

The semantics of this proposal is that the initiator is proposing M
different types of groups; any selection of relatively short KE payload (e.g. one for group from K
different types will be acceptable.

For example, suppose our policy is "we must agree on at least 2
groups from the list (P-256, P-384), (NIST_CANDIDATE_1,
NIST_CANDIDATE_2; both of type lattice) and (NIST_CANDIDATE_1 of type
isogeny), where NIST_CANDIDATE_1 and NIST_CANDIDATE_2 of type lattice
are assigned group numbers 40 and 41 respectively, and
NIST_CANDIDATE_1 of type isogeny is assigned group number 60"; we
have the following list (in hexadecimal)

0002 0003 0001 0002 0013 0014 0002
0002 0028 0029 0004 0001 003c 0000

which is parsed as
0002 K = 2
0003 We have 3 group lists
0001 0002 First list is of type classical, and consists of two
groups
0013 0014 Group 14, 19 (P-256) and group 20 (P-384)
0002 0002 Second list is of type lattice, and consists of two
groups
0028 0029 Group 40 (NIST_CANDIDATE_1 of type lattice) and group
41 (NIST_CANDIDATE_2 of type lattice)
0004 0001 Third list is of type isogeny, and consists of one
group
003c Group 60 (NIST_CANDIDATE_1 of type isogeny)
0000 Zero-pad

We can now give the format that the initiator sends to the responder
in the KEi payload. or
31). The initiator sends its group policy in one rest of the following two formats:

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
+-------------------------------------------------------------+
| DH_Group_Policy |
+-------------------------------------------------------------+

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
+-------------------------------------------------------------+
| DH_Group_Policy for initial IKE exchange |
+-------------------------------------------------------------+
| DH_Group_Policy for child SAs |
+-------------------------------------------------------------+

If the initiator uses the first format, then the same DH policy will
be negotiated for both the initial IKE exchange, as well as any child
SA exchanges. If the initiator uses the second format, then the
first policy listed will be used for the initial IKE exchange; the
second policy listed will be used for any child SA negotiations.

3.5.2. Protocol from the Responder

If the responder finds a combination of groups that are mutually
acceptable, then it responds with the KEr payload in one of the
following two formats:

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
+---------------------------------------------------------------+
| 0 | N |
+---------------------------------------------------------------+
| DH_1 | DH_2 |
~ ... ~ ... ~
| DH_N | 0 |
+---------------------------------------------------------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------------------------------------------------------+
| 0 | N_Initial |
+---------------------------------------------------------------+
| DH_1 | DH_2 |
~ ... ~ ... ~
| DH_N_Initial | 0 |
+---------------------------------------------------------------+
| 0 | N_Child |
+---------------------------------------------------------------+
| DH_1 | DH_2 |
~ ... ~ ... ~
| DH_N_Child | 0 |
+---------------------------------------------------------------+

where
o 0 is a fixed 0000 pattern;
o N, N_Initial, N_Child is the number of groups that KE payloads are
selected;
o DH_1, DH_2, ..., DH_N encrypted within IKE_AUX
messages; because they are encrypted, the selected groups.

If the second format is selected, then the groups used for the
initial standard IKE SA and the groups used for child SAs are listed
separately.

We assume that the responder has a similar local policy governing
what it fragmentation
solution [RFC7383] is willing to negotiate. To search the initiator's vector to
find such a mutually acceptable combination, the responder can run
the following algorithm.

1. Set list of accepted DH groups to empty
2. Set K to the maximum of (minimum number available.

3.5. Child SAs

This method of group lists
specified performing hybrid key exchanges, by the initiator, minimum number of group lists
acceptable according to the responder policy).
3. For every DH_Group_list in the initiator proposal
a. Set T to the DH_Group_list type
b. Find for the responder DH_Group_list of type T
c. If the responder has such a group list
* Scan for a DH element that the two lists have performing
multiple exchanges in common
- If there is such a group
o Append that to the "list of accepted DH groups"
o (Optional) if the list is at least K elements
long, stop searching (and accept)
4. If the list of accepted DH groups is at least K elements long,
accept. Otherwise, fail.

3.6. Fragmentation Support

3.6.1. Fragmentation Problem Description

When the IKE message size exceeds series, solves the path MTU, the IKE messages are
fragmented at the IP level. IP fragments can be blocked or dropped issue by network devices such as NAT/PAT gateways, firewalls, proxies and
load balancers. If IKE messages are dropped, making the IKE and subsequent
IPsec Security Association (SA) will fail to be established. In many
instances the quantum safe key exchange data could SK
values be too large to
send in a single IKE message as the path MTU between hosts is set
below the total size function of all the IKE message. As this draft defines
multiple key exchanges in a single IKE message, there is a high
chance that IP fragmentation will occur in IKE_SA_INIT messages.

The maximum length of an IKE payload is 65,535 octets. It is
anticipated that some post quantum algorithms will require a key
exchange payload size that is greater than 65,535 octets.
Furthermore, CERT payloads in IKE_AUTH messages are expected to
exceed 65,565 octets when sending certificates containing post
quantum public keys and signatures.

To overcome these limitations we present a method to split any
payload into multiple fragments and optionally send these fragments
in separate IKE_SA_INIT messages.

3.6.2. Fragmentation Solution

To enable fragmentation of IKE payloads, we introduce new
FRAG_POINTER and FRAG_BODY payloads. Further, performed. Hence, we introduce a method
of sending payload fragments in multiple IKE_SA_INIT messages as well
as a method of sending payload fragments in encrypted IKE messages
which then may or may not be fragmented using RFC 7383's IKEv2
message fragmentation.

3.6.2.1. Fragmentation Pointer Payload

In place of any payload within an IKE packet, the sender may replace
it with a FRAG_POINTER payload; this FRAG_POINTER type (rather than
the original payload type) will appear in the next payload field of
the previous payload (or IKE header). This payload has the following
format
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| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Type | Fragment Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:
o C is the Critical flag for the original payload.
o Payload Type is the payload type of the original payload; e.g. if
this payload is a KE payload, this will be the value 34.
o Fragment Identifier is a 24 bit value that the sender does not
reuse often, that is, within
achieve the timeout period goal of this IKE
packet. It is intended to be used to allow making the receiver to
correlate the fragments (contained in other packets) to the
payload within the original IKE packet.
o Total Payload Length is the length of the original payload. Note
that this draft allows the transmission of payloads greater than
64k, exchange secure if necessary.
o Fragment Length is the amount of data contained within each
fragment (except for the last fragment, which may be smaller).
o RESERVED will be an all-0's field.

3.6.2.2. Fragmentation Body Payload

The sender can split the contents of any payload across one or more
FRAG_BODY payloads. This payload has the format:

where:
o Next Payload is the identifier for the payload type of the next
payload in the message. There may be additional restrictions on
the value of Next Payload during the fragmentation of an
IKE_SA_INIT message, see Section 3.6.2.3 below.
o Payload Type, Fragment Identifier, Total Payload Length, Fragment
Length key
exchanges are the same as the corresponding fields in the
FRAG_POINTER payload. Take careful note, like the other fields
described here the Fragment Length field will be identical across
all fragments. Thus, if this is the last fragment, Fragment
Length could be longer than the size of the Payload Data field.
o Fragment Number is the current fragment message number, starting
from 1. secure.

This field MUST NOT be 0.
o Payload Data is proposal allows the contents support of the payload for this fragment.
For any fragment other than the last, this will be 'Fragment
Length' bytes long; for the last one, it will be (Total Payload
Length-1) % Fragment Length + 1 bytes long. Note that the Generic
Payload Header from the original payload MUST NOT be included multiple post-quantum algorithms
(in case we don't have full confidence in
the Payload Data of the fragment, but any additional payload
header fields after the Generic Payload Header MUST be included.
The Generic Payload Header cannot be included because it includes
the 16-bit Payload Length field, however the length of a
fragmented payload may require more than 16 bits to be stored.

The logical contents of the reassembled payload will be

Payload Data[1] | PayloadData[2] | ... | PayloadData[N]

where N = Total Payload Length / Fragment Length (rounded up).

As an example, the following KE payload could be fragmented into a
FRAG_POINTER and two FRAG_BODY payloads with Fragment Length of 1000
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| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Group Num | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Exchange Data (1500 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Key Exchange Payload to be Fragmented
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| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KE | Fragment Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Payload Length (1504) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Length (1000) | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example FRAG_POINTER Payload for KE Payload

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| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KE | Fragment Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Payload Length (1504) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Length (1000) | Fragment Number (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Group Num * | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Exchange Data[0..995] (996 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Example FRAG_BODY Payload 1 for KE Payload
(*) Corresponds to the payload-specific header fields beginning
immediately after the Generic Payload Header of the Key Exchange
payload being fragmented. This is the beginning of the Payload
Data field in the FRAG_BODY payload.

3.6.2.3. Fragmentation Semantics

If the receiver supports one); this fragmentation extension, the sender may
fragment any payload by replacing the payload with a FRAG_POINTER
payload and one of more FRAG_BODY payloads. If IP fragmentation is
not a concern (e.g. when IKEv2 fragmentation is achieved using
encrypted fragment payloads, or it's known that IP fragmentation of
IKE_SA_INIT won't be an issue) then the corresponding FRAG_BODY
payloads MUST appear anywhere after the FRAG_POINTER in an IKE
message.

An IKE_SA_INIT message may be fragmented across multiple IKE messages
using this payload fragmentation. In this case the sender first
sends an IKE_SA_INIT message containing
implemented by having the FRAG_POINTER payloads and
any unfragmented payloads. Then it sends one IKE_SA_INIT message per
FRAG_BODY payload generated from initiator list all the original IKE_SA_INIT message.
Each IKE_SA_INIT message must be sent with a Message ID combinations of 0. Each
IKE_SA_INIT message subsequent to the first one MUST contain one
FRAG_BODY payload, MAY contain a COOKIE notification and SHOULD NOT
contain any other payloads. Since FRAG_POINTER support
extra key exchanges he finds acceptable. It is negotiated
in an initial IKE_SA_INIT round-trip which didn't generate any shared
keys, the responder had the opportunity to send a COOKIE notify
payload back to the initiator. This COOKIE can be used by the
responder as a denial-of-service prevention measure. If the sender
received a COOKIE notification payload in the initial exchange, it
MUST include the COOKIE notify payload in each fragmented IKE_SA_INIT
message that it sends. This allows the receiver to reject any
IKE_SA_INIT messages without a COOKIE or with an unrecognized COOKIE,
thus mitigating a DoS attack where an attacker sends malformed
IKE_SA_INIT messages containing a FRAG_BODY payload which the
receiver would enqueue, filling up its receiving buffers. Note, this
does not prevent an attack where the attacker listens in on messages
to determine a valid COOKIE and emits malformed IKE_SA_INIT messages
with that cookie, or where it sends a valid initial round IKE_SA_INIT
message to received a valid cookie and then emit malformed messages
using anticipated that cookie.

When the receiver receives an IKE payload with one or more
FRAG_POINTER payloads, it waits until it processes all the
corresponding FRAG_BODY payloads to transform the payloads into the
original unfragmented payload which it processes as normal. If the
IKE message was not a fragmented IKE_SA_INIT message, all
corresponding FRAG_BODY payloads
there will be contained in the IKE
message, if they are not the receiver MUST reject the IKE message.

When the receiver receives an IKE_SA_INIT message, is may have to
process several IKE_SA_INIT messages to reconstruct the original
unfragmented message. If it receives the initial message containing
the FRAG_POINTER payloads, it enqueues that message and awaits the
corresponding IKE_SA_INIT messages containing the FRAG_POINTER
payloads needed to reconstruct the original message. In addition, if
it receives a FRAG_BODY message without receiving a corresponding
FRAG_POINTER payload first, it may enqueue that payload.

The receiver may vet the declared payload length, and reject it if it
decides that the length is too long.

Also note that we allow the FRAG_BODY payload to consist of the
entire payload; this can happen if (for example) the MTU size is
1500, and we want to transmit a 1300 byte KE payload, in addition to
400 bytes of other IKE data.

Once all the FRAG_BODY payloads have been received and reassembled,
the IKE receiver may commence parsing the IKE packet. This proceeds
as normal, except that when it sees a payload of type FRAG_POINTER,
it looks into the FRAG_POINTER payload to see the actual payload type
and length, and refers to the reassembly buffer need for the actual
payload data.

Note about the criticality field; a FRAG_POINTER field may be marked
as noncritical, which means that the IKE parser may ignore it if it
does not understand the payload type within the FRAG_POINTER payload.
However, even if it does that, it MUST still reassemble all the
FRAG_BODY payloads (because of the IKE AUTH processing depends on
them).

3.6.2.4. IKE AUTH Processing

When generating the IKE AUTH payload, the reassembled texts contained
within the FRAG_BODY payloads is logically appended to the IKE
message (and before the nonce). Specifically, we modify how
InitiatorSignedOctets and ResponderSignedOctets are computed as
follows:

where PayloadData1, ..., PayloadDataN are the fields from the
FRAG_BODY payloads associated with the IKE message being
authenticated, in the same order that the corresponding FRAG_POINTERS
appear in, and for payloads from the same FRAG_POINTER, in increasing
FRAGMENT_NUMBER order.

3.6.2.5. Design Rationale

The contents of the FRAG_POINTER/FRAG_BODY payloads were designed to
make it easy to reassemble. The initial segments of the payloads
were intentionally kept identical (to simply the processing if the
FRAG_BODY arrived first); the receiver always knows how long the
payload will be (allowing the allocation of buffers, if required);
the receiver always knows the location in the payload data of each
fragment (and so is able to save the data immediately into the
buffer), and the receiver can compute the large number of fragments up
front (and hence can easily tell when all fragments have been
received).

The method of performing IKE AUTH processing was also designed to
make it easy to implement; that PayloadData1 | PayloadData2 | ... |
PayloadDataN is just the reassembled payloads concatenated together.

3.7. Protection against Downgrade Attacks

In RFC7296, man-in-the-middle (MitM) downgrade attack is prevented by
always resending the full set of group proposal in subsequent
IKE_SA_INIT messages if the responder chooses a different Diffie-
Hellman group from the one in the initial IKE_SA_INIT message. The
two-round nature combinations of the protocol in
key exchanges, hence this document presents some
challenges in terms of downgrade attack protection. However, the
general idea is the same relatively simple encoding method was
selected as the one in RFC7296, in that the responder
must have sufficient information to verify that the downgrade is a
genuine one, rather than one instigated by a malicious attacker.
Consider the following example: an initiator proposes to use a hybrid
key exchange, reasonable compromise between simplicity and for backward compatibility also purposes a Diffie-
Hellman group 19 (P-256 elliptic curve) through SAi payload, in the
first round of the exchange. The initiator may receive an
INVALID_KE_PAYLOAD notification response.
functionality.

This could be a genuine
response from a responder that does not understand or support the
selected hybrid key exchange, or it could method also be a malicious
downgrade response from an MitM attacker. The initiator, on the
second round of the exchange, MUST send the same cipher proposals and
policies as in the first exchange round to indicate that the
initiator would have preferred allows us to use the hybrid fragment large post-quantum key exchange. The
responder MUST check that the chosen proposal is indeed not caused by
a downgrade attack. If the check fails, it indicates a potential
downgrade attack and the connection SHALL be dropped immediately.

In order to check the proposals and policies, the responder may
choose to maintain states between IKE_SA_INIT rounds. However, this
increases the risk of state exhaustion attack. Of course, the
responder may decide not to allocate any states and rely on the
authentication in IKE_AUTH for any tampering of the exchange.
Unfortunately, this option does not offer the benefit of an early
downgrade attack detection; the responder will have to spend
resources computing entities such as shared secrets and
authentication code before knowing whether or not there is a
downgrade attack. Such a benefit may be obtained by encoding some
information into a cookie (Section 2.6. RFC7296).

Whilst this document does not mandate how information should be
encoded to form the cookie, it could be efficiently done as follows

Cookie = <VersionIDofSecret> | Hash(KEi(#TBA) | <secret>)

where KEi(#TBA) is the KE payload in the first round of IKE_SA_INIT
exchange, <secret> is a randomly entity generated by the responder
which SHOULD be changed periodically as suggested in RFC7296, and the
entity <VersionIDofSecret> should be updated whenever <secret> is
changed. In this scenario, the responder calculates a cookie value
from the first round of the IKE_SA_INIT request message and sends it
to the initiator as part of
exchanges; all the first round IKE_SA_INIT response
message. The initiator echoes back the cookie and a
N(PQ_ALGO_POLICIES) notify payload along with other IKE_SA_INIT
attributes. When the responder receives the second round of the
IKE_SA_INIT message, it recalculates the cookie value and checks
whether or not this value is the same as the one in the previous
round of the exchange, which is available from N(PQ_ALGO_POLICIES).
If they mismatch, it indicates an attempt needs to force a downgrade attack
and therefore the connection SHALL be terminated. As before, any
attempts of the attacker to modify the packets so that cookie
validation passes will be detectable in IKE_AUTH stage.

In the event of the value <secret> goes out-of-sync, as suggested in
RFC7296, the responder MAY reject the request by responding with a
new cookie, or it MAY keep using the old value of <secret> for a
short time and accept cookies computed from either one.

The complete two-round IKE_SA_INIT message exchange flow with cookie assure is shown below. In this particular example, the responder
understands and accepts the hybrid key exchange proposed in the first
IKE_SA_INIT round.

Initiator Responder
--------------------------------------------------------------
HDR, SAi1, KEi(#TBA),
Ni, [N(Pay Frag)] -->
<-- HDR, SAr1, KE(#TBA),
Nr, N(COOKIE),
[N(Pay Frag),]

HDR, N(COOKIE), SAi1,
KEi1[, KEi2, ..., KEiX,]
Ni, N(PQ_ALGO_POLICIES) -->
<-- HDR, SAr1, KEr1[, KEr2,
..., KErX,] Nr

The following shows the flow whereby the responder does not support that the proposed hybrid key exchange and proposes to switch to classical
Diffie-Hellman initial key
exchange of type P-256. Because the responder
does not keep any states, it relies on (which has the cookie and
N(PQ_ALGO_POLICIES) to detect that it KE payloads exchanged during IKE_SA_INIT) is a genuine downgrade.

Initiator Responder
--------------------------------------------------------------
HDR, SAi1, KEi(#TBA),
Ni, [N(Pay Frag)] -->
<-- HDR, N(INVALID_KE_PAYLOAD, 19),
N(COOKIE)

HDR, N(COOKIE), SAi1,
KEi(19), Ni,
N(PQ_ALGO_POLICIES) -->
<-- HDR, SAr1, KEr(19), Nr

The cookie does
small enough not protect against an adversary that amends the
KE(#TBA) payload in the first IKE_SA_INIT request round and also then
amends the N(PQ_ALGO_POLICIES) payload in the second IKE_SA_INIT
request round to create a match. In this instance, IKE_AUTH
authentication SHALL fail due to the InitiatorSignedOctets being
inconsistent between both peers.

The decision to use a cookie or allocate state SHOULD be a decision
taken by the responder. This should be a configurable value, and/or
activated when a certain threshold of half open connections is
reached. The cookie is sent in addition to the other attributes
contained in first round of IKE_SA_INIT response.

The cookie does not mitigate an attack whereby an adversary cause the
responder to perform many lookups for the post-quantum algorithms and
policies, resulting in a denial-of-service (DoS) condition. In order
to mitigate this type of attack, the RFC7296 cookie mechanism or a
puzzle-solving mechanism as described in RFC8019 SHOULD be used. A
responder MAY decide to combine DoS and downgrade prevention cookies,
in which case, the combined cookie may be encoded as follows

where Ni, IPi and SPIi are as described in RFC7296. fragmentation.

4. Alternative Design

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

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

We considered combining the various key exchanges into a single
large KE payload; this effort is documented in a previous version
of this draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This
does allow us to cleanly apply hybrid key exchanges during the
child SA; however it does add considerable complexity, and
requires an independant fragmentation solution.

o Sending post-quantum proposals and policies in KE payload only

With the objective of not introducing unnecessary notify payloads,
we considered communicating the hybrid post-quantum proposal in
the KE payload during the first pass of the protocol exchange.
Unfortunately, this design is susceptible to the following
downgrade attack. Consider the scenario where there is an MitM
attacker sitting between an initiator and a responder. The
initiator proposes, through SAi payload, to use a hybrid post-
quantum group and as a backup a Diffie-Hellman group, and through
KEi payload, the initiator proposes a list of hybrid post-quantum
proposals and policies. The MitM attacker intercepts this traffic
and replies with N(INVALID_KE_PAYLOAD) suggesting to downgrade to
the backup Diffie-Hellman group instead. The initiator then
resends the same SAi payload and the KEi payload containing the
public value of the backup Diffie-Hellman group. Note that the
attacker may forward the second IKE_SA_INIT message only to the
responder, and 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 not offering the corresponding public value in the KEi
payload; and (b) the responder has not specifically acknowledged
that it does not supported the requested hybrid group. However,
the checking of this policy introduces unnecessary protocol
complexity. Therefore, in order to fully prevent any downgrade
attacks, using KE payload alone is not 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 N(INVALID_KE_PAYLOAD) response.

o New payload types to negotiate hybrid proposal 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, could be used
to transport hybrid public value. Although, in theory a new
payload type could be made backwards compatible by not setting its
critical flag as per Section 2.5 of RFC7296, we believe that it
may not be that simple in practice. Since the original release of
IKEv2 in RFC4306, no new payload type has ever been proposed and
therefore, this creates a potential risk of having a backward
compatibility issue from non-conforming RFC IKEv2 implementations.
Since we could not see any other compelling advantages apart from
a semantic one, we use the existing KE transform type and notify
payloads instead. In fact, as described above, we use the KE
payload in the first IKE_SA_INIT request round and the notify
payload to carry the post-quantum proposals and policies. We use
one or more of the existing KE payloads to carry the hybrid public
values.

o 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 following the same
reasoning as above, this may not be a good idea from a 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, we believe that it is cleaner to send the hybrid public
values in multiple KE payloads--one for each group or algorithm.
Furthermore, at this point in the protocol exchange, both peers
should have indicated support of handling multiple KE payloads.

o Fragmentation

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

The first approach was to treat the entire IKE_SA_INIT message as
a stream of bytes, which we then split it into a number of
fragments, each of which is wrapped onto a payload that would fit
into the size of the network MTU. The payload that wraps each
fragment is a new payload type and it was envisaged that this new
payload type will not cause a backward compatibility issue 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 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 such as a fragment index and total
number of fragments. We decided to discard this approach due to
its blanket approach to fragmentation. In cases where only a few
payloads need to be fragmented, we felt that this approach is
overly complicated.

Another idea that was discarded was fragmenting an individual
payload without introducing a new payload type. The idea was 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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 the size of
the generic payload header. The two-octet RESERVED field
following Diffie-Hellman Group Number was to be used as a fragment
identifier to help 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.

We discarded this approach because we believe that the working
group may not be happy using the RESERVED field to change the
format of a packet and that implementers may not like the
complexity added from checking the fragmentation flag in each
received payload. Furthermore, we dismissed this idea in favour
of More importantly, fragmenting the idea present messages in Section 3.6 due to the handling of the
total IKEv2 payload size. There was not a clean method for
this way may leave the
receiver system to determine the total size of all the IKEv2 fragmented
payloads. The method defined in Section 3.6 allows for a clean
method for implementations be more prone to determine the IKE payload size and
make a policy decision denial of
service (DoS) attacks. By using IKE_AUX to allocate memory or discard transport the packet. large
post-quantum key exchange payloads, there is no longer any issue
with fragmentation.

o Group sub-identifier

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

o State Keeping in Downgrade Attack Protection

Another way of checking whether or not a downgrade attack is in
effect is to have a responder to commit the state of the first-
pass of the IKE_SA_INIT message onto memory or a temporary
database. When the responder receives the second-pass of the
exchange, it can verify it against the saved state to determine
whether or not a downgrade attack is in effect. While this simple
verification does offer protection against downgrade attack, it is
susceptible to state exhaustion attack. While we do not discard
this idea, it is RECOMMENDED to use the other two downgrade
protection mechanisms described in Section 3.7.

5. Security considerations

The key length of the Encryption Algorithm (Transform Type 1), the
Pseudorandom Function (Transform Type 2) and the Integrity Algorithm
(Transform Type 3), all have to be of sufficient length to prevent
attacks using Grover's algorithm [GROVER]. In order to use the
extension proposed in this document, the key lengths of these
transforms SHALL be at least 256 bits long in order to provide
sufficient resistance to quantum attacks. Accordingly the post-
quantum security level achieved is at least 128 bits.

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

The main focus of this document is to prevent a passive attacker
performing a "harvest and decrypt" attack. In other words, an
attacker that records messages exchanges today and proceeds to
decrypt them once he owns a quantum computer. 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 since document. This is for two reasons.

The first reason is because the authentication step remains
classical. In particular, the authenticity of the SAs established
under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA
algorithms. Whilst the pre-shared key option, provided the key is
long enough, is post-quantum, the other algorithms are not.

Moreover, in implementations where scalability is a requirement, the
pre-shared key method may not be suitable. Quantum-
safe Quantum-safe authenticity
may be provided by using a quantum-safe digital signature and several
quantum-safe digital signature methods are being explored by IETF.
For example example, if the implementation is able to reliably track state,
the hash based method, XMSS has the status of an Internet Draft, RFC, see [XMSS]. [RFC8391].
Currently, quantum-safe authentication methods are not specified in
this document, but are planned to be incorporated in due course.

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
archived with decryption by quantum computers taking place at some
point in the future. Until quantum computers become 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 by mounting a MitM attack.
Consequently there is not such a pressing need for quantum-safe
authenticity.

The key exchange mechanism in this document provides a method for
malicious parties to send multiple KE payloads, where each of which
could be large, to a responder. As the standard behavior is for the
responder to consume computational resources

This draft does not attempt to compute and send
multiple address key exchanges with KE payloads back to
longer than 64k; the initiator, this allows for current IKE payload format does not allow that
as a simple
method for malicious parties to cause possibility. If such huge KE payloads are required, a VPN gateway to perform
excessive processing. In order to mitigate against this threat,
implementations MAY make use of the DoS prevention COOKIE
notification work
around (such as defined in [RFC7296], to mitigate spoofed traffic making the KE payload a URL and a puzzle-solving notification [RFC8019] to minimize hash of the impact from
hosts who use their own IP address.

Cookie notification is used to prevent downgrade attacks. The cookie
SHALL NOT real
payload) would be of arbitrary length, otherwise needed. At the current time, it appears likely
that there will be susceptible to
SLOTH attack as described in [BL]. It is RECOMMENDED that the length plenty of the cookie be no longer than 64 octets. key exchanges available that would not
require such a workaround.

6. References

[ADPS] Alkim, E., Ducas, L., Poppelmann, T., and Schwabe, P.,
"Post-quantum Key Exchange - a New Hope", 25th USENIX
Security Symposium, pp. 327-343, 2016.

[AH] Kent, S., "IP Authentication Header", RFC 4302, December
2005, <http://www.rfc-editor.org/info/rfc4302>.

[BL] Bhargavan, K. and Leurent, G., "Transcript Collision
Attacks: Breaking Authentication in TLS, IKE, and SSH",
Network and Distributed System Security Symposium, 2016.

[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005, <http://www.rfc-
editor.org/info/rfc4303>.

[FMKS] Fluhrer, S., McGrew, D., Kampanakis, P., and Smyslov, V.,
"Postquantum Preshared Keys for IKEv2", Internet draft,
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-
ikev2, 2017.
<http://www.rfc-editor.org/info/rfc4303>.

[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

[IKEV2IANA]
IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters", <http://www.iana.org/assignments/ikev2-
parameters/>.

[LOGJAM] Adrian, 1996.

[I-D.ietf-ipsecme-qr-ikev2]
Fluhrer, S., McGrew, D., Bhargavan, K., Durumeric, Z., Gaudry, Kampanakis, P.,
Green, M., Halderman, J., Heninger, N., Springall, D.,
Thome, E., Valenta, L., VanderSloot, B., Wustrow, E.,
Beguelin, S., and Zimmermann, P., "Imperfect forward
secrecy: How Diffie-Hellman fails V. Smyslov,
"Postquantum Preshared Keys for IKEv2", draft-ietf-
ipsecme-qr-ikev2-03 (work in practice", Proc. 22rd
ACM SIGSAC Conference on Computer and Communications
Security, pp. 5-17, 2015. progress), June 2018.

[I-D.smyslov-ipsecme-ikev2-aux]
Smyslov, V., "Auxiliary Exchange in the IKEv2 Protocol",
draft-smyslov-ipsecme-ikev2-aux-00 (work in progress),
January 2018.

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

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

[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383,
DOI 10.17487/RFC7383, November 2014.

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

[RFC8229] Pauly, T., Touati, S., and R. Mantha, R., "TCP Encapsulation
of IKE and IPsec Packets", RFC8229, RFC 8229, DOI 10.17487/RFC8229,
August 2017.

[XMSS] 2017, <https://www.rfc-editor.org/info/rfc8229>.

[RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A.
Mohaisen, A., "XMSS: Extended Hash-Based Signatures", Crypto Forum
Research Group Internet Draft, 2017 eXtended Merkle Signature Scheme",
RFC 8391, DOI 10.17487/RFC8391, May 2018,
<https://www.rfc-editor.org/info/rfc8391>.

Acknowledgements

The authors would like to thanks Frederic Detienne and Olivier
Pelerin for their comments and suggestions, including the idea to
negotiate the post-quantum algorithms using the existing KE payload.

Authors' Addresses

C. Tjhai
Post-Quantum
email: cjt [at] post-quantum.com

Email: cjt@post-quantum.com

M. Tomlinson
Post-Quantum
email: mt [at] post-quantum.com

Email: mt@post-quantum.com
G. Bartlett
Cisco Systems
email: grbartle [at] cisco.com

Email: grbartle@cisco.com

S. Fluhrer
Cisco Systems
email: sfluhrer [at] cisco.com

Email: sfluhrer@cisco.com

D. Van Geest
ISARA Corporation
email: daniel.vangeest [at] isara.com

Email: daniel.vangeest@isara.com

Z. Zhang
Onboard Security
email: zzhang [at] onboardsecurity.com

Email: zzhang@onboardsecurity.com

O. Garcia-Morchon
Philips
email: oscar.garcia-morchon [at] philips.com

Email: oscar.garcia-morchon@philips.com