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

Internet Engineering Task Force C. Tjhai
Internet-Draft M. Tomlinson
Intended Status: Informational A. Cheng Post-Quantum
Expires: January July 19, 2018 Post-Quantum G. Bartlett
S. Fluhrer
Cisco Systems
July 18, 2017

Hybrid Quantum-Safe
D. Van Geest
ISARA Corporation
Z. Zhang
Onboard Security
O. Garcia-Morchon
Philips
January 15, 2018

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

Abstract

This document describes the optional key-exchange payload of how to extend Internet Key Exchange Protocol
Version 2 (IKEv2) so that carries quantum-safe the shared secret exchanged between peers
has resistance against quantum computer attacks. The basic idea is
to exchange one or more post quantum key exchange data. This optional payload is used payloads in
conjunction with the existing (Elliptic Curve) Diffie-Hellman key exchange to establish a quantum-safe
shared secret between an initiator and a responder. The optional
payload supports
payload. This document also addresses the challenge of fragmentation
as a number result of quantum-safe sending large post quantum key exchange schemes. 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/.

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 December 21, 2017. July 19, 2018.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 3
1.1. Problem Description . . . . . . . . . . . . . . . . . . . 2 3
1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology Changes . . . . . . . . . . . . . . . . . . . . . . . 3 . . 4
1.4. Document organization . . . . . . . . . . . . . . . . . . 4
2. Design criteria . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Framework of Hybrid Quantum-Safe Post-quantum Key Exchange . . . . . . 6
3.1. Overall design . . . . . . . . . 4
2.1. Quantum-Safe Group Transform Type . . . . . . . . . . . . 4
2.2. IKE_SA_INIT Exchange . 6
3.2. Overall Protocol . . . . . . . . . . . . . . . . . . 5
2.3. CREATE_CHILD_SA Exchange . . . 7
3.2.1. First Protocol Round . . . . . . . . . . . . . . 6
2.3.1. New Child SAs from the CREATE_CHILD_SA Exchange . . . 7
2.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
3.2.2. Second Protocol Round . . 8
2.3.3. Rekeying . . . . . . . . . . . . . . 10
3.2.3. Child SAs with SA Negotiation . . . . . . . . . . . . . . . . . 11
3.3. Computation of a Post-Quantum Shared Secret . . . . . . . 12
3.4. Post-Quantum Group Transform Type and Group Identifiers . 12
3.5. Hybrid Group Negotiation . . . . . . . . . . . . . . . . . 13
3.5.1. Protocol for the CREATE_CHILD_SA Exchange Initiator . 8
2.4. QSKE Payload Format . . . . . . . . . . . . . 14
3.5.2. Protocol from the Responder . . . . . . . 9
3. Design Rationale . . . . . . . 17
3.6. Fragmentation Support . . . . . . . . . . . . . . . . 10
3.1. Threat Categories . . 19
3.6.1. Fragmentation Problem Description . . . . . . . . . . 19
3.6.2. Fragmentation Solution . . . . . . . . 10
3.2. Dealing with . . . . . . . . 19
3.6.2.1. Fragmentation Pointer Payload . . . . . . . . . . 19
3.6.2.2. Fragmentation Body Payload . . . . . . 11
3.3. Removal of the Diffie-Hellman exchange . . . . . . 20
3.6.2.3. Fragmentation Semantics . . . . 12
4. Security Considerations . . . . . . . . . 23
3.6.2.4. IKE AUTH Processing . . . . . . . . . . 12
5. IANA Considerations . . . . . 24
3.6.2.5. Design Rationale . . . . . . . . . . . . . . . . 13
6. References . 25
3.7. Protection against Downgrade Attacks . . . . . . . . . . . 25
4. Alternative Design . . . . . . . . . . . . . . . 14
Appendix A. Quantum-safe Ciphers . . . . . . . 28
5. Security considerations . . . . . . . . . . . . . . . . . . . 31
6. References . . . . . . . . . . . 16
Appendix A.1. Ring Learning With Errors . . . . . . . . . . . . . 16
Appendix A.2. NTRU Lattices . . 33
Acknowledgements . . . . . . . . . . . . . . . . . 21 . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 35

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 [DH] to establish a shared secret between an
initiator and a responder. The security of the Diffie-Hellman algorithm 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 can easily crack 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 also referred to as quantum-safe cryptography (QSC) or
quantum-resistant cryptography (QRC).

1.2. Proposed Extension

This document describes a method framework to extend integrate QSC for IKEv2,
whilst maintaining backwards compatibility, to perform key exchange a shared
secret such that is robust
against it has resistance to quantum computers. The idea is computer attacks. Our
framework allows the negotiation of one or more QSC algorithm to use an optional key
exchange payload using a quantum-safe key exchange algorithm, data, in addition to the existing Diffie-Hellman DH or ECDH key exchange. exchange
data. We believe that the feature of using more than one 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 quantum-safe secret post quantum secrets not be present, the derived
shared secret is equivalent to that of the standard IKEv2; on the
other hand, a quantum-safe post quantum shared secret is obtained if both
classical and post quantum key exchange
payloads data are present. This extension
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.

The goals

One of the key challenges in this extension are:

o 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 allow an additional date have key
exchange using a quantum-safe
algorithm to be used data size that exceeds 1K octets. When transmitted
alongside other payloads, the existing key exchange
algorithm while we are transitioning to a post-quantum era;

o to keep total payload size could easily exceed
the modifications common maximum transmission unit (MTU) size of 1500 octets, and
hence this may lead to IP level fragmentation. While IKEv2 to has a minimum whilst
maintaining compatibility with IKEv2; and

o
mechanism to provide handle 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 path UDP-based solution will also be required. This
document describes a simple mechanism to phase out fragment IKE_SA_INIT
messages, which also allows exchanges for payload larger than 65,535
octets.

Note that readers should consider the existing Diffie-Hellman key
exchange approach in this document as
providing a long term solution in upgrading the future.

It IKEv2 protocol to
support post quantum algorithms. A short term solution to make IKEv2
key exchange quantum secure is expected that implementers of to use post quantum pre-shared keys as
discussed in [FMKS].

1.3. Changes

Changes in this specification are familiar
with IKEv2 [RFC7296], and are knowledgeable about quantum-safe
cryptosystems, draft in particular each version iterations.

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

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

o Instead of relying on TCP encapsulation mechanisms instantiated to deal with public-key encryption. 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. Subsection
1.3 provides an overview of the terminology and the abbreviations
used in this document. Section 2 specifies
summarizes design criteria. Section 3 describes how quantum-safe post-quantum key
exchange is performed between two IKE peers and peers, how keying materials are
derived in both IKE and Child SAs. The rationale behind the
approach of this extension how downgrade attack is described prevented. This section also
specifies we handle fragmentation in IKE_SA_INIT exchanges. A
number of alternative designs to Section 3. 3, which we have considered
but not adopted, are discussed in Section 4 4. Lastly, Section 5
discusses security considerations. Section 5 describes IANA
considerations for the name spaces introduced in this document. This
is followed by a list of cited references and the authors' contact
information.

1.3. Terminology

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].
In addition to using

2. Design criteria

The design of the terms defined in proposed post-quantum IKEv2 [RFC7296], this
document uses is driven by the
following list of abbreviations:

KEM: It stands 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 encapsulation mechanism whereby key
material negotiation only
relies on non post-quantum primitives. This is transported using a public-key algorithm.

QSKE: Denotes high threat
for any information that must remain confidential for a quantum-safe 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 payload, 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 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
similar available,
sometime in the future. Thus, our design focuses on quantum-
resistant confidentiality due to Key Exchange (KE) payload.

QSSS: Denotes 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 quantum-safe shared secret (QSSS) established from
QSKEi 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 QSKEr payloads. does not create assumptions
about the properties of the algorithms, meaning that if
algorithms with different properties become necessary in 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 entity
ensures easier and quicker adoption in existing implementations.

8) Localized changes. Another key requirement is similar that changes to
the
Diffie-Hellman shared secret g^ir as defined protocol are limited in RFC 7296.

Q-S Group:
It stands for Quantum-Safe Group scope, in particular, limiting
changes in the exchanged messages and it represents in the state machine, so
that they can be easily implemented.

9) 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) Fragmentation support. Some PQC algorithms could be relatively
bulky and they might require fragmentation. Thus, a
quantum-safe cryptography algorithm 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 exchange. Each
group corresponds shares.

11) Backwards compatibility and interoperability. This is a
fundamental requirement to an algorithm with ensure that hybrid post-quantum IKEv2
and a specific set non-post-quantum IKEv2 implementations are interoperable.

12) 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
parameters.

2. Hybrid Quantum-Safe Post-quantum Key Exchange

3.1. Overall design
The proposed hybrid post-quantum IKEv2 protocol extends RFC7296
[RFC7296] by duplicating the initial exchange in [RFC7296]. 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 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. The second
IKE_SA_INIT message pair, on the other hand, consists of each peer
sending the Diffie-Hellman public value along with the post-quantum
key-shares. Note that no Diffie-Hellman exchange or exchange of
post-quantum key-shares is performed in the first round of
IKE_SA_INIT exchange. Messages are described as message 1 for the
initiator's first message, message 2 for the responder's first
message, message 3 for the initiator's second message and message 4
for the responder's second message.

Initiator Responder
--------------------------------------------------------------
<-- First round (hybrid group negotiation) -->

<-- Second round (hybrid quantum-safe key exchange) -->

This hybrid post-quantum IKEv2 key exchange occurs 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 an additional key exchange payload, denoted QSKE, payloads
to be introduced. The additional key exchange uses algorithms that
are currently considered to be resistant to quantum computer attacks.
These algorithms are collectively referred to as quantum-safe post-quantum
algorithms in this document.

2.1. Quantum-Safe Group Transform Type

3.2. Overall Protocol

In generating keying materials 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 following we overview the
negotiated algorithms is an ephemeral Diffie-Hellman algorithm, which
is used for key-exchange. This negotiation is facilitated by two protocol rounds involved in the
Transform Type 4 (Diffie-Hellman Group) where each Diffie-Hellman
group is assigned a unique Transform ID.
hybrid post-quantum protocol.

3.2.1. First Protocol Round

In order to enable a quantum-safe key exchange in IKEv2, the various
quantum-safe algorithms MUST be negotiated between two IKEv2 peers.
Transform Type #tba (Quantum-Safe Group) is first round, the IKE_SA_INIT request and response messages are
used to facilitate this
negotiation. It is identical negotiate the hybrid group. The method to Transform Type 4, except that negotiate and
exchange post-quantum policies is achieved using the
latter deals key exchange
payload (with a Diffie-Hellman Group Num of #TBA). The KE payload
with various group number #TBA does not contain Diffie-Hellman groups or post-
quantum public values, but proposed post-quantum algorithms and the
policy for the post-quantum ciphers.

The initiator negotiates cryptographic suites as per RFC7296, the
only whereas exception is, the
former handles quantum-safe algorithms only. Each quantum-safe
algorithm Diffie-Hellman KE payload is assigned not populated
with a unique Transform ID.

Whilst all keyshare, but rather the key exchange algorithms in Transform Type 4 are based
on Diffie-Hellman, some of KE payload contains the proposed
post-quantum algorithms in Transform Type #tba are
Diffie-Hellman-like, and policies. The Diffie-Hellman groups are
negotiated in the rest of security association payload as per RFC7296 and the algorithms use key-
encapsulation-mechanism (KEM). In
public values sent in the case next round of KEM, exchange.

When a responder that supports the initiator
randomly generates hybrid exchange, receives an
IKE_SA_INIT message with a random, ephemeral public and private key pair,
and sends KE payload with group number #TBA, it
performs a lookup of the public key to policies and algorithms contained within the responder in QSKEi
KE payload. Assuming that it supports one or more proposed post-
quantum algorithms, it then indicates these in the KE payload
response with group number #TBA. The responder generates a random entity, encrypts it using also selects the received
public key, and sends
cryptographic suites, including the encrypted quantity to chosen Diffie-Hellman Group Num
in the initiator security association payload as per RFC7296. In this exchange
the Diffie-Hellman public value is not sent in
QSKEr the KE payload.

The initiator decrypts the encrypted can signal support of IKE_SA_INIT message fragmentation
by including a payload using
the private key. After fragmentation Notify payload. The responder
can also include this point Notify payload to indicate support of the exchange, both initiator
and
IKE_SA_INIT message fragmentation.

The responder have may choose to allocate state to the same random entity from which session, as the quantum-safe
shared secret (QSSS) is derived.

The Transform Type #tba (Quantum-Safe Group)
initial message is defined as an
optional type used in IKE, AH authenticating the IKE SA messages.
Optionally, the responder may prefer not to allocate any state and ESP protocols. This transform type MUST
NOT exist if there is no Transform Type 4 in
reply with a proposal.

For Transform Type #tba, cookie instead. The cookie can provide two functions.
One being the defined list standard RFC7296 behaviour. The other benefit of quantum-safe Transform
IDs are listed below. Note that using
the values below are only current as cookie is to provide fast detection of a downgrade attack without
running into the publication date risk of this document. Readers should refer to
[IKEV2IANA] for state exhaustion attacks. Whether or not
any states are allocated, the latest values.

Name Number Key exchange
------------------------------------------------------
RLWE 128 1 Diffie-Hellman-like
NewHope 128 2 Diffie-Hellman-like
NTRU EES743EP1 3 KEM
NTRU-Prime 216 4 KEM

2.2. IKE_SA_INIT Exchange

The IKE_SA_INIT request and response pairs negotiate responder detects the post-quantum
cryptographic
algorithms, exchange nonces algorithms and perform a key exchange policies that do not match and can then
abort the session prior to calculating the shared secrets. See
Section 3.7 for an IKE SA. more information on cookie and downgrade attack
prevention.

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

The initiator sends a QSKEi payload which contains parameters needed
to established a quantum-safe shared secret. The QSKEi payload is
marked as OPTIONAL so

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

By using the KE payload, peers that it will be ignored by a responder who does do not understand it. In this particular case, support the responder hybrid
exchange will
respond with reject the initial negotiation and assuming that a set of payloads as defined
Diffie-Hellman Group Num contained in IKEv2 [RFC7296], and
therefore maintaining the Diffie-Hellman Group
Transform IDs was acceptable, the peer will send an
INVALID_KE_PAYLOAD message to indicate its preferred Diffie-Hellman
group. Note that using the KE payload enables backward compatibility
with existing implementation. On RFC7296 implementations. If this scenario occurs, the other hand, if
initiator SHOULD retry the responder implements this specification, it
will respond hybrid exchange. Dependent on policies,
the initiator may retry the exchange as follows:

<-- HDR, SAr1, KEr, [QSKEr,]
Nr, [CERTREQ] per RFC7296, and if this
occurs then the N(PQ_ALGO_POLICIES) notify payload MUST be included
to prevent downgrade attacks. The QSKEr N(PQ_ALGO_POLICIES) notify payload completes the quantum-safe shared secret between
contains the initiator same post-quantum algorithms and responder.

At this point policies that were sent
in the negotiation, both initiator and KE(#TBA) payload in the first round of IKE_SA_INIT request.

On receipt of the N(PQ_ALGO_POLICIES) payload, the responder MUST
validate these post-quantum algorithms and policies against its own
policies. This validation is
able required to compute:

o a shared Diffie-Hellman secret from KEi and KEr pair, and

o ensure that the post-
quantum algorithms were not amended in the initial exchange,
resulting in a quantum-safe shared secret from QSKEi and QSKEr pair.

Using these two shared secrets, each peer generates SKEYSEED, from
which all keying materials for protection of downgrade attack.

Should the IKE SA are derived.
The quantity SKEYSEED proposed post-quantum algorithms not be acceptable to the
responder, the responder SHOULD indicate this by sending the
INVALID_KE_PAYLOAD Notify message to indicate its preferred Diffie-
Hellman group or the NO_PROPOSAL_CHOSEN Notify message if no Diffie-
Hellman group were acceptable. If the classical cryptographic suite
is computed as follows:

SKEYSEED = prf(Ni | Nr, g^ir | QSSS)

where prf, Ni, Nr, and g^ir acceptable, but the post-quantum algorithms are defined as not, the responder
SHOULD indicate this by specifying the preferred Diffie-Hellman group
in the INVALID_KE_PAYLOAD notification. The initiator should then
revert to the classical IKEv2 [RFC7296]. QSSS exchange and include the
N(PQ_ALGO_POLICIES) payload to prevent downgrade attacks. Below is represented as
an octet string. The seven secrets derived from
SKEYSEED, namely SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, example that shows the proposed hybrid group is not supported by
the responder and SK_pr,
are generated as defined in IKEv2 [RFC7296].

Because that the initiator sends responder prefers a QSKE payload, which contains quantum-
safe data, Diffie-Hellman Group
19 (P-256), assuming that this group is in the IKE_SA_INIT, list proposed
(although it must guess a Q-S group is not preferred), in 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 the
responder will select from its list use of proposed groups. If hybrid exchange,
these MUST not revert to using the
initiator guesses incorrectly, classical IKEv2 exchange. This
should be a configurable parameter in implementations.

As per RFC7296, should the responder will respond with not accept any of the
cryptographic suites that were sent in the security association
payload, a
Notify payload 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 the second protocol round, the initiator sends again the
IKE_SA_INIT request. The main difference is that this message
includes the key-shares associated to each of type INVALID_QSKE_PAYLOAD indicating the selected
Q-S group post-quantum
algorithms agreed in the previous round. Each key-share is
transported in a KE payload, and therefore there may exist multiple
KE payloads in the initiator MUST retry second round of the IKE_SA_INIT with message.
Furthermore, these KE payloads may be fragmented if the
corrected Q-S group. There key-shares
are two octets large and both peers indicate the support of data associated fragmentation.

In a general hybrid arrangement, the RFC7296 Diffie-Hellman public
value is sent in 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 notification, which contains ordering is not mandatory.

If the accepted Quantum-Safe Group
Transform Type number in big endian order. As responder sent a cookie in the case first round of
INVALID_KE_PAYLOAD, exchange, the
initiator MUST again propose its full set return this cookie. In addition to that, the
initiator MUST send the same post-quantum algorithms and policies
that were included in the KE payload of
acceptable cryptographic suites because type #TBA sent in the rejection message was not
authenticated, which may lead to any potential vulnerabilities
exploitation.

2.3. CREATE_CHILD_SA Exchange first
round of the exchange, in a notify payload N(PQ_ALGO_POLICIES). The CREATE_CHILD_SA exchange is used to create new Child SAs
responder MUST examine the post-quantum algorithms and to
rekey both IKE SAs policies, and Child SAs. If
confirm that the CREATE_CHILD_SA request
contains a presented KE payload, it MAY also contain an optional QSKE payload
to enable quantum-safe forward secrecy for payloads match those represented by the Child SA. The keying
material
cookie, see Section 3.7 for the Child SA is more information. Should an anomaly or a function of Sk_d established during
mismatch be detected, the establishment of responder MUST abort the IKE SA, session. On the nonces exchanged during
other hand, if the
CREATE_CHILD_SA exchange, validation passes, then the Diffie-Hellman value, responder can proceed
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 agreed and if required, fragmentation
is handled as described in Section 3.6. Once the quantum-
safe data (if QSKE payload initiator has
received all key-shares from the responder, the initiator can compute
the same shared secret following the description in Section 3.3.

Below is included an example message exchanged in the CREATE_CHILD_SA
exchange).

If a CREATE_CHILD_SA request includes a QSKEi payload, at least one second round of
IKE_SA_INIT message.

Initiator Responder
--------------------------------------------------------------
HDR, [N(COOKIE),] SAi1,
KEi1[, KEi2, ..., KEiX,]
Ni[, N(PQ_ALGO_POLICIES)] -->

<-- HDR, SAr1, KEr1[, KEr2,
..., KErX,] Nr

For implementations that are to be used by peers that are pre-
configured with matching hybrid policies, resulting in the SA offers MUST include a Q-S group initial
exchange used to negotiate the post-quantum policies and algorithms
contained in one the first round of its transform
structures. The Q-S group MUST be an element exchanges being redundant, the
initiator can skip the first round of exchanges by sending the group that
IKE_SA_INIT containing the key-shares. However the initiator expects MUST be
sure that the responder to accept. If will accept the responder selects
a different Q-S group, presented key-shares. In this
instance the responder is open to abuse by fragmentation related
attacks and MUST reject revert to using the request by
sending INVALID_QSKE_PAYLOAD Notify payload. The responder's
preferred Q-S group initial exchange, should it find
itself under any form of attack.

3.2.3. Child SA Negotiation

After the initial IKE SA is indicated in this notify payload. In negotiated, either side may later
negotiate child SAs or rekey the case
of IKE SA which may involve a rejection, fresh key
exchange. If a hybrid group is desired, then the initiator should retry with another
CREATE_CHILD_SA request containing proposes
a Q-S group Transform Type 4 (Diffie-Hellman) of (TBA); he includes the KE
payloads for the key exchange types that was indicated in were negotiated for the INVALID_QSKE_PAYLOAD Notify payload.

2.3.1. New Child
child SAs from during the CREATE_CHILD_SA Exchange initial negotiation (see Section 3.5.1). The CREATED_CHILD_SA request
responder replies with the corresponding KE payloads, and response pair both use
the shared secrets to create generate the child SA keying material (see
section 3.3). If hybrid groups were not initially negotiated as a new Child
part of the initial key exchange, then child SAs MUST NOT propose a
hybrid group.

Specifically, the key exchange for creating a child SA is shown below: using a hybrid
group is:

Initiator Responder
--------------------------------------------------------------
HDR, SK {SA, SK{SA, Ni,
[KEi,] [QSKEi,] KEi1, KEi2,
..., KEiN, TSi, TSr} -->
<-- HDR, SK {SA, SK{SA, Nr,
[KEr,] [QSKEr,] KEr1, KEr2,
..., KErN, TSi, TSr}

The initiator sends an encrypted request containing

where both SA offer(s), payloads include a
nonce, optional Diffie-Hellman and quantum-safe key exchange data transform type 4 of (TBA), and the proposed Traffic Selectors.

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., both
initiator and responder replies with can compute the common shared secrets to
generate an encrypted response containing SKEYSEED, from which all keying materials for protection
of the
accepted IKE SA offer, a nonce, a Diffie-Hellman value if KEi was
included are derived. The quantity SKEYSEED is computed as
follows:

SKEYSEED = prf(Ni | Nr, SS1 | SS2 | ...| SSN)

where prf, Ni and Nr are defined as in IKEv2 [RFC7296], SSi
represents the request and i-th shared secret computed from the expected Diffie-Hellman group was
selected, a quantum-safe data if QSKEi was included i-th key exchange
algorithm contained in the request
and the expected Q-S hybrid group that was selected, and negotiated in the accepted Traffic
Selectors.

The keying material
protocol. Note that if at least one of these CREATE_CHILD_SA exchanges SSi is a classical
shared secret that have both
KE is FIPS approved, then FIPS compliance design
criteria as outlined in Section 2 is achieved. The seven secrets
derived from SKEYSEED, namely SK_d, SK_ai, SK_ar, SK_ei, SK_er,
SK_pi, and QSKE payloads SK_pr, are generated as defined in IKEv2 [RFC7296].

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

KEYMAT = prf+(SK_d, QSSS (new) SS1 | SS2 | ... | g^ir (new) SSN | Ni | Nr)

where prf+, Sk_d, g^ir (new), Ni and Nr are defined in IKEv2

[RFC7296], and QSSS (new) is SSi represents the i-th shared secret computed from the ephemeral
quantum-safe i-th
key exchange. The QSSS quantity is represented as an
octet string.

2.3.2. Rekeying IKE SAs with exchange algorithm that was performed during the CREATE_CHILD_SA Exchange

The CREATE_CHILD_SA request and response pair for negotiation of
the child SA.

When rekeying an IKE SA using a hybrid group, the new SKEYSEED is shown below:

Initiator Responder
--------------------------------------------------------------
HDR, SK{SA, Ni,
KEi[, QSKEi]} -->
<-- HDR, SK {SA, Nr,
KEr[, QSKEr]}

The
computed as:

SKEYSEED = prf(SK_d (old), SS1 | SS2 | ... | SSN | Ni | 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 new IKE SA.

3.4. Post-Quantum Group Transform Type and Group Identifiers

In generating keying material within IKEv2, both initiator sends an encrypted request containing amongst other
payloads, a KEi payload which carries a Diffie-Hellman value, and an
OPTIONAL QSKEi payload which carries a quantum-safe data.

The
responder replies with negotiate up to four cryptographic algorithms in the SA
payload of an encrypted response containing IKE_SA_INIT or a number CREATE_CHILD_SA exchange. One of payloads. If the responder selects
negotiated algorithms is a Diffie-Hellman group that
matches one of algorithm, which is used
for key exchange. This negotiation is done using the proposed group(s), a KEr payload containing a Transform Type
4 (Diffie-Hellman Group) where each Diffie-Hellman public value group is replied assigned
a unique value.

In order to enable a post-quantum key exchange in IKEv2, the encrypted response. If 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 request contains 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 QSKEr payload and part of the responder selects a Q-S
group
negotiation.

We expect that matches one of in the proposed group(s), 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 QSKEr payload
containing quantum-safe data is sent hybrid
group, the details are listed in the reply. KE payload.

The quantity SKEYSEED following values are reserved for the new IKE SA is computed as follows:

SKEYSEED = prf(SK_d (old), QSSS (new) | g^ir (new) | Ni | Nr)

where prf, SK_d (old), g^ir (new), Ni below key exchanges: 0x9100
- 0xXXXX. The following abstract identifiers are used to illustrate
their usage in our framework. Actual identifiers will be maintained
by IANA and Nr 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 defined using transforms in IKEv2
[RFC7296], QSSS (new) 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 shared secret from MD5 hash of "IKEv2 Quantum Safe Key Exchange
v1"). If the ephemeral
quantum-safe other side does not include this vendor id, an
implementation MUST NOT process these private use transforms as
listed in this draft.

3.5. Hybrid Group Negotiation

Most post-quantum key exchange. 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 QSSS quantity concern is represented 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 an
octet string.

2.3.3. Rekeying Child SAs secure as expected).

A hybrid solution allows us to deal with the CREATE_CHILD_SA Exchange

The CREATE_CHILD_SA request and response pair for rekeying this uncertainty by
combining 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 Child SA hybrid
group. For instance, the type of underlying problem that is shown below:

Initiator Responder
--------------------------------------------------------------
HDR, SK {N(REKEY_SA), SA,
Ni, [KEi,] [QSKEi,]
TSi, TSr} -->
<-- HDR, SK {SA, Nr,
[KEr,] [QSKEr,] TSi, TSr}

Both KEi and QSKEi payloads are OPTIONAL. The KEi and QSKEi
payloads, which are sent encrypted by trusted,
the initiator, carry minimum number of algorithms that should be used in a Diffie-
Hellman value and quantum-safe data respectively.

If hybrid
group, or the CREATE_CHILD_SA request includes KEi security strength of each of the algorithms. For these
reasons, hybrid groups might lead to many potential combinations
difficult to define, maintain and QSKEi payloads,
provided that a Diffie-Hellman standardize. This motivates our
hybrid group and a Q-S negation protocol.

Our hybrid group are present in
the SA offers, negotiation protocol allows the responder replies with an encrypted response
containing both KEr initiator and QSKEr payloads.
responder to agree on a common hybrid group based on their respective
policies. The keying material computation protocol categorizes each type of this key exchange into a
type T, which is based on the same as 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
defined define the minimum number
of post-quantum algorithms that they require in [Section 2.3.1].

2.4. QSKE Payload Format

The quantum-safe a hybrid group and
also the types of key exchange payload, denoted QSKE agreement protocols that they support (and
therefore, trust). The initiator and responder can then engage in this document, a
simple protocol that allows them to compute a common hybrid group
fulfilling their policies. The protocol for the initiator and
responder is used 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 quantum-safe shared secret between two IKE
peers. The QSKE payload consists combination would
be considerably more complex. This design assumes that the security
policies of the IKE generic payload header,
a two-octet value denoting initiator and the Quantum-Safe Group number, responder will rely on key
exchanges based upon distinct types of hard problems, and
followed by hence the quantum-safe data itself. The format
additional complexity of the QSKE
payload more general algorithm is shown below. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length
+---------------------------------------------------------------+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T | Quantum-Safe Group Num N | RESERVED
+---------------------------------------------------------------+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PQC_ID_1 | PQC_ID_2 |
~ Quantum-Safe Data ... ~ ... ~
| PQC_ID_N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The length of the quantum-safe data varies depending on 0 |
+---------------------------------------------------------------+

where
o T is the type of
quantum-safe cipher. The content type of quantum-safe data 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 also
dependent on the type number of quantum-safe cipher. For quantum-safe
ciphers groups that use Diffie-Hellman-like key exchange, make up the content list. The semantics
of the
quantum-safe data this proposal is the proposed/accepted cipher's public value.
For ciphers that use KEM, the content initiator is either a random public-key
of the proposed quantum-safe cipher in the case proposing M different
types of QSKEi payload, or
the content is a ciphertext produced using the received public-key in
the case groups; any selection of QSKEr payload.

The Quantum-Safe Group Num identifies the quantum-safe cipher with
which the quantum-safe data was computed. The Quantum-Safe Group Num
MUST match the Q-S one group specified in a proposal in the SA payload
sent in the same message. If the proposal in the SA payload does not
specify a quantum-safe cipher, the QSKE payload MUST NOT from K different
types will be present.
If the responder selects a Q-S group that does not match acceptable.

o PQC_ID_1, PQC_ID_2, PQC_ID_N, such as NIST_CANDIDATE_1, is the proposed
group,
identifier for the quantum-safe key exchange MUST PQC algorithm to be rejected with a Notify
payload used for negotiation, in
order of type INVALID_QSKE_PAYLOAD. The chosen Q-S group preference.

o 0 is
indicated in the INVALID_QSKE_PAYLOAD Notify payload and the
initiator can restart the exchange with that group.

The payload type for the QSKE payload padding, present if N is TBA (TBA).

3. Design Rationale

In general, the size odd.

The semantics of QSKE payload this list is larger than that of the KE
counterpart and sending it in these are the IKE_SA_INIT may prevent peers from
establishing IPSec Security Association (SA) due groups of PQC
algorithms of type T that are acceptable to fragmentation.
While the fragmentation issue may be addressed by sending QSKE in the
IKE_AUTH exchange, it initiator.

We now define a "DH_Group_Policy"; this is decided that QSKE should still 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 exchanged
in satisfied;
o M is the IKE_SA_INIT. 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 rationale behind semantics of this decision proposal is discussed
below.

3.1. Threat Categories

The treats to that the IKE exchange can initiator is proposing M
different types of groups; any selection of one group from K
different types will be broken into two categories:

1. From current day until general purpose quantum computers 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
available.

The addition assigned group numbers 40 and 41 respectively, and
NIST_CANDIDATE_1 of type isogeny is assigned group number 60"; we
have the QSKE allows 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 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 IKEv2 exchange format that the initiator sends to the responder
in the KEi payload. The initiator sends its group policy 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
+-------------------------------------------------------------+
| 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
secured against an adversary who captures all control plane
(IKE) and data plane (ESP) traffic, 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 intention 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
breaking groups that are
selected;
o DH_1, DH_2, ..., DH_N are the selected groups.

If the second format is selected, then the groups used for the
initial IKE exchange (when quantum computers become
available) SA and subsequently being able the groups used for child SAs are listed
separately.

We assume that the responder has a similar local policy governing
what it is willing to view negotiate. To search the data plane
traffic. The use 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 QSKE maximum of (minimum number of group lists
specified by the initiator, minimum number of group lists
acceptable according to the responder policy).
3. For every DH_Group_list in the IKE_SA_INIT results 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 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 SA becoming quantum secure against future attacks.

2. After general purpose quantum computers message size exceeds the path MTU, the IKE messages are available.

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

The maximum length of attack:

o Active attack

Assuming an IKE payload is 65,535 octets. It is
anticipated that a general purpose some post quantum computer algorithms will require a key
exchange payload size that is
available 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, 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 adversary can manipulate 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 exchange 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 the timeout period of this IKE
packet. It is intended to be used to allow the receiver to
correlate the fragments (contained in real time. 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, 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 attacker sender can break Diffie-Hellman in
real time, but not split the QSKE. contents of any payload across one or more
FRAG_BODY payloads. This results payload has the format:

where:
o Next Payload is the identifier for the payload type of the next
payload in the IKE_AUTH
exchange being secure 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 are the same as the QSKE 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. This field MUST NOT be 0.
o Payload Data is the contents 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 in
the
derivation Payload Data of key material used 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 secure be stored.

The logical contents of the IKE_AUTH
exchange.

However, reassembled payload will be

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

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

As an active attacker who can sit between example, the following KE payload could be fragmented into a
FRAG_POINTER and two hosts 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 this fragmentation extension, the sender may
fragment any payload by replacing the payload with a FRAG_POINTER
payload and impersonate each host can perform one of more FRAG_BODY payloads. If IP fragmentation is
not a man-in-the-middle
(MitM) attack concern (e.g. when the authentication method IKEv2 fragmentation is not quantum
secure. This includes 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 the FRAG_POINTER payloads and
any asymmetric authentication method unfragmented payloads. Then it sends one IKE_SA_INIT message per
FRAG_BODY payload generated from the original IKE_SA_INIT message.
Each IKE_SA_INIT message must be sent with a Message ID of 0. Each
IKE_SA_INIT message subsequent to the first one MUST contain one
FRAG_BODY payload, MAY contain a COOKIE notification and non-quantum computer resistant Extensible
Authentication Protocol (EAP) authentication. For
authentication methods SHOULD NOT
contain any other payloads. Since FRAG_POINTER support is negotiated
in an initial IKE_SA_INIT round-trip which are quantum secure, such as
using didn't generate any shared key
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 integrity code comprising that it sends. This allows the receiver to reject any
IKE_SA_INIT messages without a
shared-secret COOKIE or with sufficient entropy (256 bits), 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
allows for
does not prevent an attack where the IKEv2 exchange 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 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 will be secured against contained in the IKE
message, if they are not the receiver MUST reject the IKE message.

When the receiver receives an
active adversary when including IKE_SA_INIT message, is may have to
process several IKE_SA_INIT messages to reconstruct the QSKE.

o Passive attack

As per original
unfragmented message. If it receives the first category, 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 QSKE allows FRAG_BODY payloads have been received and reassembled,
the IKEv2 exchange 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 for the actual
payload data.

Note about the criticality field; a FRAG_POINTER field may be secured against an adversary who
captures 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 control plane (IKE) and data plane (ESP)
traffic, with the intention
FRAG_BODY payloads (because of breaking the IKE exchange.

3.2. Dealing 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 Fragmentation

In some instances, the QSKE public value 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 large enough (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
cause fragmentation save the data immediately into the
buffer), and the receiver can compute the 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 occur at
make it easy to implement; that PayloadData1 | PayloadData2 | ... |
PayloadDataN is just the IP layer. reassembled payloads concatenated together.

3.7. Protection against Downgrade Attacks

In practice, there
will 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 of the protocol in this document presents some
challenges in terms of downgrade attack protection. However, the
general idea is the same 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, 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. This could be cases where IKE traffic fragmented at a genuine
response from a responder that does not understand or support the IP layer will
selected hybrid key exchange, or it could also be
dropped 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 to use the hybrid key exchange. The
responder MUST check that the chosen proposal is indeed not caused by network devices
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 NAT/PAT gateways, Intrusion
Prevention System (IPS), firewalls shared secrets and proxies, that cannot handle IP
fragments
authentication code before knowing whether or are configured 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 block IP fragments. This blocked
traffic will prevent form the IKE session 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 being established. the first round of the IKE_SA_INIT request message and sends it
to the initiator as part of the first round IKE_SA_INIT response
message. The
issue initiator echoes back the cookie and a
N(PQ_ALGO_POLICIES) notify payload along with fragmentation can easily 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 to force a downgrade attack
and therefore the connection SHALL be avoided by moving terminated. As before, any
attempts of the QSKE 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
is shown below. In this particular example, the responder
understands and by employing IKEv2 Message Fragmentation
[RFC7383]. 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 implication following shows the flow whereby the responder does not support
the proposed hybrid key exchange and proposes to switch to classical
Diffie-Hellman key exchange of this type P-256. Because the responder
does not keep any states, it relies on the cookie and
N(PQ_ALGO_POLICIES) to detect that it 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 not protect against an adversary that while all amends the Child SAs,
which carry
KE(#TBA) payload in the data traffic, would 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 quantum secure, a decision
taken by the IKE SA
itself would 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 be, mitigate an attack whereby an adversary cause the
responder to perform many lookups for the post-quantum algorithms and
policies, resulting in the disclosure a denial-of-service (DoS) condition. In order
to mitigate this type of IKE identities 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 IPsec proxies. Furthermore by sending downgrade prevention cookies,
in which case, the QSKE combined cookie may be encoded as follows

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

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 post-quantum proposals and policies in KE payload only

With the objective of not IKE_SA_INIT would allow 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 active MitM
attacker with sitting between an initiator and a quantum
computer responder. The
initiator proposes, through SAi payload, to perform attacks against IKE such use a hybrid post-
quantum group and as forging an identity
used for authentication, abuse a backup a Diffie-Hellman group, and through
KEi payload, the initiator proposes a list of attributes sent 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 CFG
exchange, MitM attack, DoS, etc. It responder will
not have the information that the initiator prefers the hybrid
group. Of course, it is believed 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 trade off requested hybrid group. However,
the checking of this policy introduces unnecessary protocol
complexity. Therefore, in order to deliver 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 resistant IKE public values

Semantically, it makes sense to use a new payload type, which
mimics the SA is of greater security benefit
than payload, to carry a hybrid proposal. Likewise,
another new payload type that mimics the issues 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 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 encountered due 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 fragmentation 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
IP layer. It 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 worth noting wrapped onto a payload that encapsulating IKE traffic within
TCP [IKETCPENCAP] would fit
into the size of the network MTU. The payload that wraps each
fragment is a simple method to prevent IKE_SA_INIT traffic
being fragmented 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 IP layer. protocol, both peers should have indicated
support of fragmentation in the first pass of the IKE_SA_INIT
exchange. The following table gives an idea negotiation of fragmentation is performed using a
notify payload, which also defines supporting parameters such as
the common size of fragment in octets and the QSKE fragment identifier. The
new payload that wraps each fragment of the messages in this
exchange is assigned the proposed schemes.

Scheme QSKE size (octets)
-------------------------------------
RLWE 128 4096
NewHope 128 1792
NTRU EES743EP1 1030
NTRU-Prime 216 1200

It 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 evident
overly complicated.

Another idea that both NewHope 128 and RLWE 128 will naturally
increase was discarded was fragmenting an IP Maximum Transmission Unit (MTU) 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 larger than 1500
octets which
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 common for most Internet traffic, resulting in set, this means the
IKE_SA_INIT being fragmented at current KE payload is a
fragment of a larger KE payload. The Payload Length field denotes
the IP layer.

3.3. Removal size of this payload fragment in octets--including the size of
the generic payload header. The two-octet RESERVED field
following Diffie-Hellman exchange Group Number was to be used as a fragment
identifier to help assembly and disassembly of fragments. The IKE_SA_INIT exchange currently mandates
Fragment Index and Total Fragments fields are self-explanatory.
The Total KE Payload Data Length indicates the use size of the Diffie-
Hellman. As
assembled KE payload data in octets. Finally, the Diffie-Hellman exchange actual fragment
is carried in Fragment KE Payload field.

We discarded this approach because we believe that the working
group may not quantum secure be happy using the RESERVED field to change the
format of a packet and that implementers may not like the QSKE exchange is quantum secure,
complexity added from checking the addition fragmentation flag in each
received payload. Furthermore, we dismissed this idea in favour
of the QSKE can be
thought idea present in Section 3.6 due to the handling of making the Diffie-Hellman redundant. This draft does
total IKEv2 payload size. There was not
advise removing a clean method for the use
receiver to determine the total size of Diffie-Hellman, though future all the IKEv2 fragmented
payloads. The method defined in Section 3.6 allows for a clean
method for implementations that have migrated to using QSKE determine the IKE payload size and
make a policy decision to allocate memory or discard the packet.

o Group sub-identifier

As discussed in Section 3.4, each group identifier is used to
distinguish a post-quantum algorithm. Further classification
could remove be made on a particular post-quantum algorithm by assigning
additional value alongside the
requirement group identifier. This sub-
identifier value may be used to send assign different security
parameter sets to a given post-quantum algorithm. However, this
level of details does not fit the Diffie-Hellman exchange 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 QSKE
providing 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 same functionality. Sending state of the QSKE in first-
pass of the IKE_SA_INIT allows for 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 transition
verification does offer protection against downgrade attack, it is
susceptible to only using QSKE should
the need state exhaustion attack. While we do not discard
this idea, it is RECOMMENDED to remove use the Diffie-Hellman exchange occur.

4. other two downgrade
protection mechanisms described in Section 3.7.

5. Security Considerations 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 prevent any provide
sufficient resistance to quantum attacks from succeeding. attacks. Accordingly the post-quantum post-
quantum security level achieved is at least 128 bits.

The quantities

SKEYSEED and KEYMAT are is calculated from shared
secrets, g^ir and QSSS, shared, KEx, using an algorithm defined
in Transform Type 2. While a quantum attacker may learn the value of g^ir, the
quantity QSSS ensures
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 neither SKEYSEED nor KEYMAT is not compromised. This assumes that the
algorithm defined in the Transform Type 2 is quantum-safe.

Because some quantum-safe public values are in the order post-quantum.

The main focus of several
KB, this document is to prevent a IKEv2 message that contains such passive attacker
performing a QSKE payload will exceed the
path Maximum Transmission Unit (MTU) "harvest and the message may be
fragmented at the IP level. This presents the possibility of decrypt" attack. In other words, an
attack vector
attacker that relies on IP fragmentation. One such records messages exchanges today and proceeds to
decrypt them once he owns a quantum computer. This attack
vector is
prevented due to mount a denial the hybrid nature of service by swamping the key exchange. Other
attacks involving an active attacker using a receiver with IP
fragments [DOSUDPPROT]. This issue could be mitigated quantum-computer are not
completely solved by employing
TCP encapsulation [IKETCPENCAP].

The this document since the authentication step
remains classical. In particular, the authenticity of the SAs
established under IKEv2 is protected using a pre-shared key, RSA, DSS,
DSA, or ECDSA algorithms. Whilst the pre-shared key option, provided
the key is long enough, is quantum-
safe, 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 the hash based method, XMSS has
the status of an Internet Draft, see [XMSS]. 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 quantum-safe post-quantum algorithms is to
prevent attacks,
provide resistance to attacks mounted in the future, from succeeding. future. The current
threat is that encrypted sessions may be 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 use of the QSKE key exchange mechanism in this document provides an a method for
malicious parties to send
IKE_SA_INIT initiator messages containing QSKE multiple KE payloads, where each of type KEM and with
random values. which
could be large, to a responder. As the standard behavior is for the
responder to
generate a random entity, encrypt it using the received public key
(which would be a random value), consume computational resources to compute and sends the encrypted quantity send
multiple KE payloads back to the initiator in QSKEr payload. This initiator, this allows for a simply simple
method for malicious parties to cause a VPN gateway to perform
excessive processing. To In order to mitigate against this threat,
implementations can MAY make use of the DoS prevention COOKIE
notification as defined in [RFC7296], to mitigate spoofed traffic and
a puzzle-solving notification [RFC8019] to minimize the impact from
hosts who use their own IP address.

5. IANA Considerations

This document defines a new IANA registry for IKEv2 Transform Types.

Trans.
Description Type Used In
-----------------------------------------------------------
Quantum-Safe Group (Q-S) tba Optional in IKE, AH & ESP

A number of Transform IDs of the Q-S group Transform Type are also
defined. The initial values are listed below:

Name Value
------------------------------
RLWE 128 1
NewHope 128 2
NTRU EES743EP1 3
NTRU-Prime 216 4

In order to transport quantum-safe data

Cookie notification is used to establish a quantum-safe
SA, this extension registers a new key exchange payload in the IKEv2
Payload Types prevent downgrade attacks. The cookie
SHALL NOT be of the IANA registry:

Description Notation Value
---------------------------------
QSKE Payload QSKE tba

This extension also specifies a new error type arbitrary length, otherwise it will be susceptible to
SLOTH attack as described in [BL]. It is RECOMMENDED that the IKEv2 Notify
Message Types - Error Types length
of the IANA registry:

Error Type Value
------------------------------
INVALID_QSKE_PAYLOAD tba cookie be no longer than 64 octets.

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

[BCNS15] Bos, J., Costello, C., Naehrig, M., and Stebila, D.,
"Post-quantum Key Exchange for the TLS Protocol from the
Ring Learning with Errors Problem", IEEE Symposium on
Security and Privacy, pp. 553-570, 2015.

[DH] Diffie, W.,

[BL] Bhargavan, K. and Hellman, M., "New Directions Leurent, G., "Transcript Collision
Attacks: Breaking Authentication in
Cryptography", IEEE Transactions on Information Theory,
V.IT-22 n. 6, June 1977.

[DOSUDPPROT]
Kaufman, C., Perlman, R., TLS, IKE, and Sommerfeld, B., "DoS
protection for UDP-based protocols", ACM Conference on
Computer SSH",
Network and Communications Security, October 2003. 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.

[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

[IKETCPENCAP]
Pauly, T., Touati, S., and Mantha, R., "TCP Encapsulation
of IKE and IPsec Packets", draft RFC, May 2017,
<https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-
encaps-10>.

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

[LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, 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 in practice", Proc. 22rd
ACM SIGSAC Conference on Computer and Communications
Security, pp. 5-17, 2015.

[NTRU] Hoffstein, J., Pipher, J., and Silverman, J., "NTRU: A
Ring-Based Public Key Cryptosystem", Lecture Notes in
Computer Science, pp. 267-288, 1998.

[NTRUPRIME]
Bernstein, D., Chuengsatiansup, C., Lange, T., and van
Vredendaal, C., "NTRU Prime", IACR Cryptology ePrint
Archive: Report 2016/461, 2016.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and
Kivinen, T., "Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7296, October 2014.

[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383, 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.

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

[XMSS] Huelsing, A., Butin, D., Gazdag, S., and Mohaisen, A.,
"XMSS: Extended Hash-Based Signatures", Crypto Forum
Research Group Internet Draft, 2017

Appendix A. Quantum-safe Ciphers

Each of the specific quantum-safe ciphers is assigned a unique
Transform ID. All of the selected quantum-safe ciphers are based on
lattice construction. Specifically the ciphers fall into the
categories of Ring Learning With Errors, NTRU and Streamlined NTRU
Prime. In each case the selected parameters are chosen so as to
achieve at least 128 bits of post-quantum security.

Appendix A.1. Ring Learning With Errors

Ring Learning with Errors is a cryptographic primitive that relies on
the worst-case hardness of a shortest vector problem in ideal
lattices. It is commonly abbreviated as RLWE. The security
parameters are given by an integer n which is a power of 2, a prime
integer q, an array of n coefficients denoted by {a} and a standard
deviation sigma along with the type of error distribution X. Note
that each coefficient of {a} is less than the prime q and is sampled
from distribution X. Let a(x) be a polynomial, whose coefficients
are given by {a}, the RLWE problem can be stated as follows: given
polynomials a(x), b(x) and a small polynomial e(x), find the secret
s(x) from the relationship a(x) * s(x) + b(x) = e(x) modulo q.

RLWE 128
--------
This set of parameters follows the system described by Bos et al
[BCNS15]. Using a fixed coefficient array {a} in this way may result
in security vulnerabilities such as "all-for-the-price-of-one"
precomputation attacks such as the Logjam attack on the classical
Diffie-Hellman key exchange [LOGJAM]. As has been pointed out since,
this is straightforwardly solved by the coefficient array {a} being
generated on-the-fly for each key exchange from a seed value shared
by the initiator and responder. The fixed coefficient array {a} is
also avoided in similar fashion in NewHope 128 (see below).

The set of parameters that is proposed by Bos et al is given as
follows:

n = 1024
q = 2^32 -1
sigma = 8/sqrt(2 * PI)
X = discrete Gaussian
{a} = 29FE0191, DD1A457D, 3534EE4B, 6450ED74, BBFE9F64, 92BF0F31,
8DCF8995, 4C5E30D0, 9E2ED04D, 8C18FE0B, 1A70F2E7, 2625CD93,
0065DA14, 6E009722, E6A70E8B, AEF6EF56, 8C6C06AF, 9E59E953,
4995F67B, E918EE9D, 8B4F41A7, 0D811041, F5FE6458, 3C02B584,
CBCFC8FD, 5A01F116, 73408361, 44D3A098, BBDEECF6, 90E09082,
F8538BA4, F9600091, D8D30FEF, 56201487, ACB2159D, 38F47F77,
ED7A864F, 8FC785CA, 7CBD6108, 3CA577DE, FF44CCC2, A1385A79,
5C88E3AD, 177C46A9, DA4A4DD8, 2AA3594F, A4A5E629, 47CA6F6E,
B2DF1BC6, 6841B78E, 0823F5A8, A18C7D52, 7634A0D1, DA1751BA,
18B9D25D, 5B2643BC, ACC6975D, 48E786F4, 05E3ED4E, 4DC86568,
3F5C5F99, 585DBFD7, EF6E0715, 7D36B823, 12D872CD, D7B78F27,
DD672BF5, 2DC7C7EB, A3033801, 50E48348, 9162A260, 0BE8F15B,
ABB563EC, 06624C5A, 812BF7BC, 8637AC35, F44504F3, FF8577AB,
4A0161B0, 000AEB0E, 311204AF, 2A76831B, 4D903F3A, 97204FA9,
9EB524E3, 1757AFAC, BA369FEC, CD8F198D, 6B33C246, 51C13FCE,
B58ACC4E, 39ACF8DA, 7BB7EBF7, EDC1449D, C7B47FDB, 9C39148D,
4E688D7B, FAD0C2C2, 296CE85C, 6045C89C, 6441C0C6, 50C7C83A,
C11764DD, 58D7EEA2, E57B9D0E, 4E142770, B8BFBB59, E143EBAA,
FF60C855, 238727F0, E35B4A5B, 8F96940B, 4498A6BA, 5911093A,
394DD002, 521B00D2, 140BDAF9, EAB67207, 21E631A6, A04AADA9,
A96A9843, 4B44CC9B, E4D24C33, C7E7AE78, E45A6C72, CBE61D3C,
CE5A4869, 10442A52, DB11F194, 39FC415D, 7E7BDB76, AE9EFA22,
25F4F262, 472DD0A7, 42EBD7A0, E8038ECE, D3DB002A, 8416D2EC,
DF88C989, 7FEA22D5, C7A3F6FE, 37409982, F45B75E2, 9A4AC289,
90406FD6, EA1C74A5, 5777B39F, D07F1FA3, CE6EDA0D, D150ECFB,
BEFF71BA, 50129EFC, 51CE65B9, B9FB0AB8, 770C59CB, 11F2354F,
8623D4BB, D6FCAFD6, B2B1697C, 0D7067E2, 2BA5AFB9, D369C585,
5B5E156C, D8C81E6E, 80CFDF16, F6F441EB, C173BAF5, 78099E3A,
D38F027B, 4AC8D518, 8D0108A1, E442B0F1, 56F9EA3C, D0D6BBCA,
4E17DCB4, 69BF743B, 0CCE779F, D5E59851, 63861EA2, B1CB22C1,
BBFD2ACE, DDA390D1, EDF1059F, 04F80F89, B13AF849, 58C66009,
E0D781C0, 588DC348, A305669D, 0D7AF67F, 32BC3C38, D725EFBA,
DC3D9434, 22BD7ED8, 2DFD2926, 4BDEAD3A, B2D5ECE6, 16B05C99,
FEEC7104, F6CAC918, 0944C774, CE00633B, C59DA01A, 41E8E924,
335DF501, 3049E8EE, 5B4B8AAC, C962FC91, D6BB22B3, 0AC870EB,
C3D99400, A0CEAC28, AF07DE1E, 831C2824, 258C5DDC, 779417E6,
41CB33D0, 4E51076A, D1DB6038, 9E0B1C41, A9A1F90D, F27E7705,
75892711, 5D9F1175, 85CC508B, 5CA415BE, 1858C792, FB18632F,
C94111EB, 937C0D28, C2A09970, 386209D9, BBDD9787, 2473F53A,
EF7E7637, CFC8630B, 2BA3B7F8, 3C0047AD, 10D76FF7, B1D9414D,
CEB7B902, A5B543F5, 2E484905, E0233C10, D061A1F8, CED0A901,
AC373CAC, 04281F37, 3609797F, DB80964D, 7B49A74F, 7699656F,
0DCEC4BC, 0EC49C2D, F1573A4E, A3708464, 9A1E89F0, 6B26DEB6,
2329FA10, CA4F2BFF, 9E012C8E, 788C1DFD, 2C758156, 2774C544,
150A1F7D, 50156D6E, 7B675DE1, 5D634703, A7CEB801, 92733DAB,
B213C00B, 304A65B1, 8856CF8E, 7FF7DD67, D0912293, 30064297,
663D051D, 01BC31B4, 2B1700BD, 39D7D18F, 1EAD5C95, 6FB9CD8B,
A09993A6, B42071C0, 3C1F2195, 7FDF4CF8, C7565A7E, 64703D34,
14B250EF, 2FA338D2, AEE576DC, 6CCED41D, 612D0913, D0680733,
8B4DBE8A, 6FFEA3D0, 46197CA2, A77F916F, FA5D7BD6, 01E22AEB,
18E462DD, 4EC9B937, DE753212, 05113C94, 7786FBD4, FB379F71,
756CF595, EAADCFAB, BBD74C2E, 1F234AC9, 85E28AEB, 329F7878,
D48FDE09, 47A60D0A, AE95163F, 72E70995, 27F9FCBF, BDCFCC41,
334BC498, EE7931A1, DFA6AEF4, 1EC5E1BF, 6221870F, CD54AE13,
7B56EF58, 4847B490, 31640CD3, 10940E14, 556CC334, C9E9B521,
499611FF, BEC8D592, 44A7DCB7, 4AC2EABD, 7D387357, 1B76D4B6,
2EACE8C9, 52B2D2A4, 0C1F2A64, 50EF2B9A, 3B23F4F4, 8DDE415E,
F6B92D2D, 9DB0F840, E18F309D, 737B7733, F9F563C5, 3C5D4AEE,
8136B0AF, C5AC5550, 6E93DEF9, 946BCCEC, 5163A273, B5C72175,
4919EFBD, 222E9B68, 6E43D8EE, AA039B23, 913FD80D, 42206F18,
5552C01F, 35B1136D, FDC18279, 5946202B, FAAE3A37, 4C764C88,
78075D9B, 844C8BA0, CC33419E, 4B0832F6, 10D15E89, EE0DD05A,
27432AF3, E12CECA6, 60A231B3, F81F258E, E0BA44D7, 144F471B,
B4C8451E, 3705395C, E8A69794, 3C23F27E, 186D2FBA, 3DAED36B,
F04DEFF1, 0CFA7BDD, FEE45A4F, 5E9A4684, 98438C69, 5F1D921B,
7E43FD86, BD0CF049, 28F47D38, 7DF38246, 8EED8923, E524E7FC,
089BEC03, 15E3DE77, 78E8AE28, CB79A298, 9F604E2B, 3C6428F7,
DCDEABF3, 33BAF60A, BF801273, 247B0C3E, E74A8192, B45AC81D,
FC0D2ABE, F17E99F5, 412BD1C1, 75DF4247, A90FC3C0, B2A99C0E,
0D3999D7, D04543BA, 0FBC28A1, EF68C7EF, 64327F30, F11ECDBE,
4DBD312C, D71CE03A, AEFDAD34, E1CC7315, 797A865C, B9F1B1EB,
F7E68DFA, 816685B4, 9F38D44B, 366911C8, 756A7336, 696B8261,
C2FA21D2, 75085BF3, 2E5402B4, 75E6E744, EAD80B0C, 4E689F68,
7A9452C6, A5E1958A, 4B2B0A24, 97E0165E, A4539B68, F87A3096,
6543CA9D, 92A8D398, A7D7FDB4, 1EA966B3, 75B50372, 4C63A778,
34E8E033, 87C60F82, FC47303B, 8469AB86, 2DAADA50, CFBB663F,
711C9C41, E6C1C423, 8751BAA9, 861EC777, 31BCCCE1, C1333271,
06864BEE, 41B50595, D2267D30, 878BA5C5, 65267F56, 2118FB18,
A6DDD3DE, 8D309B98, 68928CB2, FAE967DC, 3CEC52D0, 9CA8404B,
AADD68A8, 3AC6B1DF, D53D67EA, 95C8D163, B5F03F1D, 3A4C28A7,
E3C4B709, B8EB7C65, E76B42A3, 25E5A217, 6B6DD2B4, BEFC5DF4,
9ACA5758, C17F14D3, B224A9D3, DE1A7C8F, 1382911B, 627A2FB9,
C66AE36E, 02CC60EF, C6800B20, 7A583C77, E1CECEE8, CA0001B4,
6A14CF16, EF45DD21, 64CAA7D5, FF3F1D95, D328C67E, C85868B1,
7FBF3FEB, 13D68388, 25373DD9, 8DE47EFB, 47912F26, 65515942,
C5ED711D, 6A368929, A2405C50, FFA9D6EB, ED39A0D4, E456B8B5,
53283330, 7837FD52, 6EE46629, CAFC9D63, B781B08F, DD61D834,
FB9ACF09, EDA4444A, BB6AA57F, AED2385C, 22C9474D, 36E90167,
E6DF6150, F1B0DA3B, C3F6800E, 966302E0, 7DB1F627, F9632186,
B4933075, 81C5C817, 878CA140, 4EDE8FED, 1AF347C1, FDEB72BA,
2DA7FF9A, B9BA3638, 2BB883F1, 474D1417, C2F474A4, 1E2CF9F3,
231CB6B0, 7E574B53, EDA8E1DA, E1ACB7BB, D1E354A6, 7C32B431,
8189991B, 25F9376A, 3FFA8782, CD9038F1, 119EDBD1, 5C571840,
3DCA350F, 83923909, 9DC3CF55, 94D79DD0, D683DE2B, ECF4316A,
0FFF48D4, 5D8076ED, 12B42C97, 2284CDB4, CB245554, 3025B4D9,
B0075F35, 43A3802E, 18332B4D, 056C4467, C597E3F7, 3F0EAF9D,
F48EBB9F, 92F62731, BDB76296, 516D4466, 226102B3, 15E38046,
A683C4E0, 6C0D1962, E20CB6CA, C90C1D70, D0FF8692, D1419690,
2D6F1081, 34782E5E, AE092CD5, 90C99193, E97C0405, EAE201DA,
631FB5AC, 279A2821, DF47BA5B, FBE587E2, 6810AD2D, C63E94BD,
9AF36B42, F14F0855, 946CE350, 7E3320E0, 34130DFF, 8C57C413,
AB0723B2, F514C743, 63694BA3, 5665D23D, 6292C0B5, 9D768323,
2F8E447C, B99A00FB, 6F8E5970, 69B3BB45, 59253E02, 1C518A02,
DD7C1232, C6416C38, 77E10340, CF6BEB9A, 006F9239, 0E99B50F,
863AD247, 75F0451A, 096E9094, E0C2B357, 7CC81E15, 222759D4,
EE5BCFD0, 050F829B, 723B8FA9, 76143C55, 3B455EAF, C2683EFD,
EE7874B4, 9BCE92F7, 6EED7461, 8E93898F, A4EBE1D0, FA4F019F,
1B0AD6DA, A39CDE2F, 27002B33, 830D478D, 3EEA937E, 572E7DA3,
4BFFA4D1, 5E53DB0B, 708D21EE, B003E23B, 12ED0756, 53CA0412,
73237D35, 438EC16B, 295177B8, C85F4EE6, B67FD3B4, 5221BC81,
D84E3094, 18C84200, 855E0795, 37BEC004, DF9FAFC9, 60BEB6CD,
8645F0C5, B1D2F1C3, ECDC4AE3, 424D17F1, 8429238C, 6155EAAB,
A17BEE21, 218D3637, 88A462CC, 8A1A031E, 3F671EA5, 9FA08639,
FF4A0F8E, 34167A7D, 1A817F54, 3215F21E, 412DD498, 57B633E7,
E8A2431F, 397BD699, 5A155288, BB3538E8, A49806D2, 49438A07,
24963568, 40414C26, E45C08D4, 61D2435B, 2F36AEDE, 6580370C,
02A56A5E, 53B18017, AF2C83FC, F4C83871, D9E5DDC3, 17B90B01,
ED4A0904, FA6DA26B, 35D9840D, A0C505E4, 3396D0B5, EC66B509,
C190E41C, 2F0CE5CF, 419C3E94, 220D42CA, 2F611F4F, 47906734,
8C2CDB17, D8658F1C, 2F6745CD, 543D0D4F, 818F0469, 380FFDAE,
F5DD91E2, AD25E46A, E7039205, A9F47165, B2114C12, CF7F626F,
54D2C9FF, E4736A36, 16DB09FC, E2B787BB, 9631709A, 72629F66,
819EBA08, 7F5D73F3, A0B0B91C, FEDFBA71, 252F14EE, F26F8FA2,
92805F94, 43650F7F, 3051124F, 72CA8EAD, 21973E34, A5B70509,
B36A41CC, C52EDE5F, F706A24E, 8AAF9F92, ADF6D99A, 23746D73,
1DA39F70, 9660FC8F, A0A8CFEB, 83D5EFCA, 0AA4A72F, EEF1B2DE,
00CFCC66, 8A145369, 6376CEDA, A3262E2E, 3367BBA8, 01488C32,
5561A2AD, 40821BF2, F0C89F61, C4FAA6B3, D843377A, 67A76555,
E8D9F1CE, 943034FF, 2BD468BD, A514D935, 50CDB19D, A09C7E9E,
6FEBEC30, B1B36CF7, CD7A30BC, 36C6FE0A, 2DF52C45, 45C9957F,
65076A79, BF783DEE, 718D37F0, 098F9117, 9A70C430, 80EB1A53,
9F2505B1, 48D10D98, B8D781E9, F2376133, ECF25B98, 5A3B0E18,
2F623537, 9F0E34A4, F1027EB6, F9B16022, BA3FEC59, EF7226FD,
9F3058AA, BB51DE0E, D5435EA0, 8A6479D5, 077708B8, 9634876A,
069A260A, 168D9E6A, 9FD18E94, 8A7ACD53, 8E5A5869, 1B6F35FD,
A968913B, C72F076B, 7DDA354C, 25B0297C, D07219D5, A66862BA,
87E8EE67, FA28809B, 55762443, 31EF4956, F4F4A511, 9A9378CB,
42ABDBDE, 7AA484B7, E8EC22ED, CADDEF61, 9D18538A, A81B923E,
9C32F92A, 6D278E58, 4CDFC716, AB64814F, F832BF1A, E2C1A36B,
20675610, E78D855A, 38332C3D, 5AE0EAD9, 2E23F22D, 3C8683C5,
A351AF89, 54720D3B, ABC6E51F, 89330C8E, 600D5650, 197EA0C6,
7D502A5D, 3A536EA7, 7DF71F32, 456FE645, 3EF5E7A2, 6664BCAF,
A9D074C2, E9D9E478, 1AE9AB77, FECE7160, C618EEEC, 771B0026,
2B54F43C, 145DA102, 1B3D7949, BB6E2D9D, DB8FDC4A, 25397EBA,
9228A6E9, 56B4C69D, 337B943C, E35B716C, F7FE89A1, 023AC20D,
033165C8, 9F13B130, C1BAFB1D, A2C42C8C, 58E4D431, E10741E6,
2547589A, 8D9EF7BD, 7E322280, F49FDDC2, BE21A094, A061178A,
34D9F13B, 694D652F, 05084A2A, 2767B991, E8536AB4, EBFADF6F,
F4C8DFAC, D9967CCA, E04BCF3F, 232B3460, 9FF6E88A, 6DF3A2B0,
0FE10E99, 7B059283, 067BFB57, 8DDA26B0, B7D6652F, 85705248,
0826240C, 5DF7F52E, 47973463, B9C22D37, 9BEB265D, 493AB6FD,
10C0FB07, 947C102A, 5FEC0608, 140E07AE, 8B330F43, 9364A649,
C9AD63EF, BE4B2475, 1A09AC77, 9E40A4B0, BA9C23E7, 7F4A798D,
E2C52D66, A26EE9E0, 8C79DCE7, DD7F1C3D, 6AE83B20, 073DBA03,
B1844D97, 16D7ED6E, 5E0DE0B1, A497D717, FA507AA2, C332649B,
21419E15, 384D9CCC, 8B915A8B, BA328FD5, F99E8016, 545725EC,
ED9840ED, 71E5D78A, 21862496, 6F858B6C, F3736AE2, 8979FC2B,
5C8122D0, 0A20EB5A, 2278AA6E, 55275E74, 22D57650, E5FFDC96,
6BA86E10, 4EC5BFCC, 05AFA305, FB7FD007, 726EA097, F6A349C4,
CB2F71E4, 08DD80BA, 892D0E23, BD2E0A55, 40AC0CD3, BFAF5688,
6E40A6A5, 6DA1BBE0, 969557A9, FB88629B, 11F845C4, 5FC91C6F,
1B0C7E79, D6946953, 27A164A0, 55D20869, 29A2182D, 406AA963,
74F40C59, 56A90570, 535AC9C6, 9521EF76, BA38759B, CD6EF76E,
F2181DB9, 7BE78DA6, F88E4115, ABA7E166, F60DC9B3, FECA1EF3,
43DF196A, CC4FC9DD, 428A8961, CF6B4560, 87B30B57, 20E7BAC5,
BFBDCCDF, F7D3F6BB, 7FC311C8, 2C7835B5, A24F6821, 6A38454C,
460E42FD, 2B6BA832, C7068C72, 28CDCE59, AE82A0B4, 25F39572,
9B6C7758, E0FE9EBA, A8F03EE1, D70B928E, 95E529D7, DD91DB86,
F912BA8C, 7F478A6A, 1F017850, 5A717E10, DAC243F9, D235F314,
4F80AAE6, A46364D8, A1E3A9E9, 495FEFB1, B9058508, 23A20999,
73D18118, CA3EEE2A, 34E1C7E2, AADBADBD.

The public key size of RLWE 128 is 4096 octets and it provides 128-
bit post-quantum security, although it does not provide forward
secrecy due to the way coefficient array {a} is generated. A set of
open source ciphersuites has been implemented and included in OpenSSL
v1.0.1f and may be found within the libcrypto module.

Acknowledgements

The authors
anticipate RLWE being incorporated into TLS with the RLWE 128
ciphersuites being compatible with TLS 1.3. Moreover, the
ciphersuites are constant time, and therefore are not vulnerable to
possible side channel attacks.

NewHope 128
-----------
This is a variation on the ring learning with errors cipher by Alkim
et al [ADPS] who set out in their solution to make improvements to
RLWE 128. Their main improvements are would like to use a random coefficient
array {a} for each key exchange thanks Frederic Detienne and to reduce the size of key
exchanges by using a 14-bit modulus instead of a 32-bit modulus.
Additionally they relax the requirement Olivier
Pelerin for the error distribution to
be discrete Gaussian and substitute the easier to generate Binomial
distribution and provide a security justification. The set of
parameters proposed by Alkim et al is given as follows:

n = 1024
q = 12289
sigma = sqrt(8)
X = Binomial

This cipher provides 128-bit post-quantum security and has a public
key size of 1792 octets. It features forward secrecy. Open source,
constant time, side-channel-proof, ciphersuites are publically
available.

Appendix A.2. NTRU Lattices

NTRU lattices are another variant of cryptosystems based on integer
lattices. The lattices have a cyclic structure as in the case of
RLWE, however the NTRU problem can be stated as follows: given a
polynomial a(x), a small secret polynomial e(x) and ciphertext c(x)
find the secret e(x) from the ciphertext c(x) = a(x) * s(x) + e(x),
modulo some integer q, where s(x) is a small secret polynomial. In
the case of NTRU-Prime 216, the transmitted secret is the small
polynomial s(x) and e(x) is generated incidentally as a result of
streamlined data packing of the ciphertext.

NTRU EES743EP1
--------------
The inventors of the first lattice cryptosystem by Silverman et al in
1996 have been developing their system ever since. Adoption by the
crypto community has been hampered by patents comments and a lack of security
proof. Whilst the polynomial ring of RLWE is truncated modulo (x^n +
1) where n is an integer power of 2, the operations of NTRU EES743EP1
[NTRU] are defined over the polynomial ring modulo (x^n - 1) where n
is 743, a prime integer. The integer modulus q is a power of 2, and
it is 2048 in NTRU EES743EP1. The QSKE public value is 1030 octets.

NTRU-Prime 216
--------------
The authors, Bernstein et al [NTRUPRIME], of this recent variant of
NTRU set out to provide increased security in the light of possible
vulnerabilities in the mathematical structure of rings used in NTRU
and RLWE. Accordingly a Galois field, not a ring, is used in NTRU-
Prime 216 with polynomials reduced modulo (x^p - x - 1), where p is a
prime integer. Specifically, while the operations of NTRU EES743EP1
are defined over the polynomial modulo (x^743 - 1), the operations of
NTRU-Prime 216 [NTRUPRIME] are defined over polynomial modulo (x^743
- x - 1). The integer modulus q is also chosen to be a prime to
avoid any additional mathematical structure that may be potentially
exploited. NTRU-Prime 216 has q = 7541. There is another parameter,
an integer t, which defines the weight of one of suggestions, including the public key
polynomials. The value of t is chosen to be 157 in this case so as
to make cryptographic failure an impossibility. Cryptographic
failure is theoretically possible in some ring based systems but
usually these systems are designed so that this occurs with
infinitesimal probability.

NTRU-Prime 216 has been designed idea to minimize
negotiate the public key size and
key encapsulation data by post-quantum algorithms using streamlined data packing and the
resulting QSKE public value is 1200 octets long. The ciphertext
includes a 256 bit key confirmation hash. The system achieves
forward secrecy. It is a very conservative design achieving 216 bits
pre-quantum security and at least 128 bits post-quantum security.
Open source, constant time, side-channel-proof ciphersuites are
publicly available. existing KE payload.

Authors' Addresses

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

M. Tomlinson
Post-Quantum
EMail: mt@post-quantum.com

A. Cheng
Post-Quantum
EMail: ac@post-quantum.com
email: mt [at] post-quantum.com

G. Bartlett
Cisco Systems
EMail: grbartle@cisco.com
email: grbartle [at] cisco.com

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

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

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

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