< draft-tjhai-ipsecme-hybrid-qske-ikev2-00.txt		draft-tjhai-ipsecme-hybrid-qske-ikev2-01.txt >
	Internet Engineering Task Force C. Tjhai		Internet Engineering Task Force C. Tjhai
	Internet-Draft M. Tomlinson		Internet-Draft M. Tomlinson
	Intended Status: Informational A. Cheng		Intended Status: Informational Post-Quantum
	Expires: January 19, 2018 Post-Quantum		Expires: July 19, 2018 G. Bartlett
	G. Bartlett		S. Fluhrer
	Cisco Systems		Cisco Systems
	July 18, 2017		D. Van Geest
			ISARA Corporation
			Z. Zhang
			Onboard Security
			O. Garcia-Morchon
			Philips
			January 15, 2018
	Hybrid Quantum-Safe Key Exchange for Internet		Framework to Integrate Post-quantum Key Exchanges
	Key Exchange Protocol Version 2 (IKEv2)		into Internet Key Exchange Protocol Version 2 (IKEv2)
	draft-tjhai-ipsecme-hybrid-qske-ikev2-00		draft-tjhai-ipsecme-hybrid-qske-ikev2-01
	Abstract		Abstract
	This document describes the optional key-exchange payload of Internet		This document describes how to extend Internet Key Exchange Protocol
	Key Exchange Protocol Version 2 (IKEv2) that carries quantum-safe key		Version 2 (IKEv2) so that the shared secret exchanged between peers
	exchange data. This optional payload is used in conjunction with the		has resistance against quantum computer attacks. The basic idea is
	existing Diffie-Hellman key exchange to establish a quantum-safe		to exchange one or more post quantum key exchange payloads in
	shared secret between an initiator and a responder. The optional		conjunction with the existing (Elliptic Curve) Diffie-Hellman
	payload supports a number of quantum-safe key exchange schemes.		payload. This document also addresses the challenge of fragmentation
			as a result of sending large post quantum key exchange data in the
			first pair of message of the initial exchange phase.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 21, 2017.		This Internet-Draft will expire on July 19, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Problem Description . . . . . . . . . . . . . . . . . . . 2		1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3
	1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . . 3		1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . . 3
	1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Hybrid Quantum-Safe Key Exchange . . . . . . . . . . . . . . . 4		1.4. Document organization . . . . . . . . . . . . . . . . . . 4
	2.1. Quantum-Safe Group Transform Type . . . . . . . . . . . . 4		2. Design criteria . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . . 5		3. The Framework of Hybrid Post-quantum Key Exchange . . . . . . 6
	2.3. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . . . . 6		3.1. Overall design . . . . . . . . . . . . . . . . . . . . . . 6
	2.3.1. New Child SAs from the CREATE_CHILD_SA Exchange . . . 7		3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . . 7
	2.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . . 8		3.2.1. First Protocol Round . . . . . . . . . . . . . . . . . 7
	2.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange . 8		3.2.2. Second Protocol Round . . . . . . . . . . . . . . . . 10
	2.4. QSKE Payload Format . . . . . . . . . . . . . . . . . . . 9		3.2.3. Child SA Negotiation . . . . . . . . . . . . . . . . . 11
	3. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 10		3.3. Computation of a Post-Quantum Shared Secret . . . . . . . 12
	3.1. Threat Categories . . . . . . . . . . . . . . . . . . . . 10		3.4. Post-Quantum Group Transform Type and Group Identifiers . 12
	3.2. Dealing with Fragmentation . . . . . . . . . . . . . . . . 11		3.5. Hybrid Group Negotiation . . . . . . . . . . . . . . . . . 13
	3.3. Removal of the Diffie-Hellman exchange . . . . . . . . . . 12		3.5.1. Protocol for the Initiator . . . . . . . . . . . . . . 14
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 12		3.5.2. Protocol from the Responder . . . . . . . . . . . . . . 17
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		3.6. Fragmentation Support . . . . . . . . . . . . . . . . . . 19
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		3.6.1. Fragmentation Problem Description . . . . . . . . . . 19
	Appendix A. Quantum-safe Ciphers . . . . . . . . . . . . . . . . 16		3.6.2. Fragmentation Solution . . . . . . . . . . . . . . . . 19
	Appendix A.1. Ring Learning With Errors . . . . . . . . . . . . . 16		3.6.2.1. Fragmentation Pointer Payload . . . . . . . . . . 19
	Appendix A.2. NTRU Lattices . . . . . . . . . . . . . . . . . . . 21		3.6.2.2. Fragmentation Body Payload . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		3.6.2.3. Fragmentation Semantics . . . . . . . . . . . . . 23
			3.6.2.4. IKE AUTH Processing . . . . . . . . . . . . . . . 24
			3.6.2.5. Design Rationale . . . . . . . . . . . . . . . . . 25
			3.7. Protection against Downgrade Attacks . . . . . . . . . . . 25
			4. Alternative Design . . . . . . . . . . . . . . . . . . . . . . 28
			5. Security considerations . . . . . . . . . . . . . . . . . . . 31
			6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
			Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 34
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
	1. Introduction		1. Introduction
	1.1. Problem Description		1.1. Problem Description
	Internet Key Exchange Protocol (IKEv2) as specified in RFC 7296		Internet Key Exchange Protocol (IKEv2) as specified in RFC 7296
	[RFC7296] uses the Diffie-Hellman algorithm [DH] to establish a		[RFC7296] uses the Diffie-Hellman (DH) or Elliptic Curve Diffie-
	shared secret between an initiator and a responder. The security of		Hellman (ECDH) algorithm to establish a shared secret between an
	the Diffie-Hellman algorithm relies on the difficulty to solve a		initiator and a responder. The security of the DH and ECDH
	discrete logarithm problem when the order of the group parameter is		algorithms relies on the difficulty to solve a discrete logarithm
	large enough. While solving such a problem remains difficult with		problem in multiplicative and elliptic curve groups respectively when
	current computing power, it is believed that general purpose quantum		the order of the group parameter is large enough. While solving such
	computers can easily crack this problem, implying that the security		a problem remains difficult with current computing power, it is
	of IKEv2 is compromised. There are, however, a number of		believed that general purpose quantum computers will be able to solve
	cryptosystems that are conjectured to be resistant against quantum		this problem, implying that the security of IKEv2 is compromised.
	computer attack.		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		1.2. Proposed Extension
	This document describes a method to extend IKEv2, whilst maintaining		This document describes a framework to integrate QSC for IKEv2,
	backwards compatibility, to perform key exchange that is robust		whilst maintaining backwards compatibility, to exchange a shared
	against quantum computers. The idea is to use an optional key		secret such that it has resistance to quantum computer attacks. Our
	exchange payload using a quantum-safe key exchange algorithm, in		framework allows the negotiation of one or more QSC algorithm to
	addition to the existing Diffie-Hellman key exchange. The secrets		exchange data, in addition to the existing DH or ECDH key exchange
	established from each key exchange are combined in a way such that		data. We believe that the feature of using more than one post
	should the quantum-safe secret not be present, the derived shared		quantum algorithm is important as many of these algorithms are
	secret is equivalent to that of the standard IKEv2; on the other		relatively new and there may be a need to hedge the security risk
	hand, a quantum-safe shared secret is obtained if both key exchange		with multiple key exchange data from several distinct QSC algorithms.
	payloads are present. This extension 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 of this extension are:		The secrets established from each key exchange are combined in a way
			such that should the post quantum secrets not be present, the derived
			shared secret is equivalent to that of the standard IKEv2; on the
			other hand, a post quantum shared secret is obtained if both
			classical and post quantum key exchange data are present. This
			framework also applies to key exchanges in IKE Security Associations
			(SAs) for Encapsulating Security Payload (ESP) [ESP] or
			Authentication Header (AH) [AH], i.e. Child SAs, in order to provide
			a stronger guarantee of forward security.
	o to allow an additional key exchange using a quantum-safe		One of the key challenges in this framework is fragmentation handling
	algorithm to be used alongside the existing key exchange		during the first message pair of the initial exchange phase, i.e.
	algorithm while we are transitioning to a post-quantum era;		IKE_SA_INIT. Almost all of the known PQC algorithms to date have key
			exchange data size that exceeds 1K octets. When transmitted
			alongside other payloads, the total payload size could easily exceed
			the common maximum transmission unit (MTU) size of 1500 octets, and
			hence this may lead to IP level fragmentation. While IKEv2 has a
			mechanism to 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 UDP-based solution will also be required. This
			document describes a simple mechanism to fragment IKE_SA_INIT
			messages, which also allows exchanges for payload larger than 65,535
			octets.
	o to keep the modifications to IKEv2 to a minimum whilst		Note that readers should consider the approach in this document as
	maintaining compatibility with IKEv2; and		providing a long term solution in upgrading the IKEv2 protocol to
			support post quantum algorithms. A short term solution to make IKEv2
			key exchange quantum secure is to use post quantum pre-shared keys as
			discussed in [FMKS].
	o to provide a path to phase out the existing Diffie-Hellman key		1.3. Changes
	exchange in the future.
	It is expected that implementers of this specification are familiar		Changes in this draft in each version iterations.
	with IKEv2 [RFC7296], and are knowledgeable about quantum-safe
	cryptosystems, in particular key exchange mechanisms and key
	encapsulation mechanisms instantiated with public-key encryption.
	The remainder of this document is organized as follows. Subsection		draft-tjhai-ipsecme-hybrid-qske-ikev2-00
	1.3 provides an overview of the terminology and the abbreviations
	used in this document. Section 2 specifies how quantum-safe key		o We added a feature to allow more than one post quantum key
	exchange is performed between two IKE peers and how keying materials		exchange algorithms to be negotiated and used to exchange a post-
	are derived in both IKE and Child SAs. The rationale behind the		quantum shared secret.
	approach of this extension is described in Section 3. Section 4
	discusses security considerations. Section 5 describes IANA		o Instead of relying on TCP encapsulation to deal with IP level
	considerations for the name spaces introduced in this document. This		fragmentation, we introduced a new key exchange payload that can
	is followed by a list of cited references and the authors' contact		be sent as multiple fragments within IKE_SA_INIT message.
	information.
			1.4. Document organization
			The remainder of this document is organized as follows. Section 2
			summarizes design criteria. Section 3 describes how post-quantum key
			exchange is performed between two IKE peers, how keying materials are
			derived and how downgrade attack is prevented. This section also
			specifies we handle fragmentation in IKE_SA_INIT exchanges. A
			number of alternative designs to Section 3, which we have considered
			but not adopted, are discussed in Section 4. Lastly, Section 5
			discusses security considerations.
	1.3. Terminology
	The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,		The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
	SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this		SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
	document, are to be interpreted as described in RFC 2119 [RFC2119].		document, are to be interpreted as described in RFC 2119 [RFC2119].
	In addition to using the terms defined in IKEv2 [RFC7296], this
	document uses the following list of abbreviations:
	KEM: It stands for key encapsulation mechanism whereby key		2. Design criteria
	material is transported using a public-key algorithm.
	QSKE: Denotes a quantum-safe key exchange payload, which is		The design of the proposed post-quantum IKEv2 is driven by the
	similar to Key Exchange (KE) payload.		following criteria:
	QSSS: Denotes a quantum-safe shared secret (QSSS) established from		1) Need for post-quantum cryptography in IPsec. Quantum computers
	QSKEi and QSKEr payloads. This entity is similar to the		might become feasible in the next 5-10 years. If current
	Diffie-Hellman shared secret g^ir as defined in RFC 7296.		Internet communications are monitored and recorded today (D),
			the communications could be decrypted as soon as a quantum-
			computer is available (e.g., year Q) if key negotiation only
			relies on non post-quantum primitives. This is a high threat
			for any information that must remain confidential for a long
			period of time T > Q-D. The need is obvious if we assume that Q
			is 2040, D is 2020, and T is 30 years. Such a value of T is
			typical in classified or healthcare data.
	Q-S Group:		2) Hybrid. Currently, there does not exist a post-quantum key
	It stands for Quantum-Safe Group and it represents a		exchange that is trusted at the level that ECDH is trusted
	quantum-safe cryptography algorithm for key exchange. Each		against conventional (non-quantum) adversaries. A hybrid
	group corresponds to an algorithm with a specific set of		approach allows introducing promising post-quantum candidates
	parameters.		next to well-established primitives, since the overall security
			is at least as strong as each individual primitive.
	2. Hybrid Quantum-Safe Key Exchange		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 available,
			sometime in the future. Thus, our design focuses on quantum-
			resistant confidentiality due to the urgency of this problem.
			This document does not address quantum-resistant authentication
			since it is less urgent at this stage.
	IKEv2 key exchange occurs in IKE_SA_INIT or CREATE_CHILD_SA message		4) Limit amount of exchanged data. The protocol design should be
	pair which contains various payloads for negotiating cryptographic		such that the amount of exchanged data, such as public-keys, is
	algorithms, exchanging nonces, and performing a Diffie-Hellman shared		kept as small as possible even if initiator and responder need
	secret exchange for an IKE SA or a Child SA. These payloads are		to agree on a hybrid group or multiple public-keys need to be
	chained together forming a linked-list and this flexible structure		exchanged.
	allows an additional key exchange payload, denoted QSKE, 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
	algorithms in this document.
	2.1. Quantum-Safe Group Transform Type		5) Future proof. Any cryptographic algorithm could be potentially
			broken in the future by currently unknown or impractical
			attacks: quantum computers are merely the most concrete example
			of this. The design does not categorize algorithms as "post-
			quantum" or "non post-quantum" and does not create assumptions
			about the properties of the algorithms, meaning that if
			algorithms with different properties become necessary in future,
			this framework can be used unchanged to facilitate migration to
			those algorithms.
	In generating keying materials within IKEv2, both initiator and		6) Identification of hybrid algorithms. The usage of a hybrid
	responder negotiate up to four cryptographic algorithms in the SA		approach in which each hybrid combination of several classical
	payload of an IKE_SA_INIT or a CREATE_CHILD_SA exchange. One of the		and post-quantum algorithms leads to a different group
	negotiated algorithms is an ephemeral Diffie-Hellman algorithm, which		identifier can lead to an exponential number of combinations.
	is used for key-exchange. This negotiation is facilitated by the		Thus, the design should seek an approach in which a hybrid group
	Transform Type 4 (Diffie-Hellman Group) where each Diffie-Hellman		-- comprising multiple post-quantum algorithms -- can be
	group is assigned a unique Transform ID.		efficiently negotiated.
	In order to enable a quantum-safe key exchange in IKEv2, the various		7) Limited amount of changes. A key goal is to limit the number of
	quantum-safe algorithms MUST be negotiated between two IKEv2 peers.		changes required when enabling a post-quantum handshake. This
	Transform Type #tba (Quantum-Safe Group) is used to facilitate this		ensures easier and quicker adoption in existing implementations.
	negotiation. It is identical to Transform Type 4, except that the
	latter deals with various Diffie-Hellman groups only whereas the
	former handles quantum-safe algorithms only. Each quantum-safe
	algorithm is assigned a unique Transform ID.
	Whilst all the key exchange algorithms in Transform Type 4 are based		8) Localized changes. Another key requirement is that changes to
	on Diffie-Hellman, some of the algorithms in Transform Type #tba are		the protocol are limited in scope, in particular, limiting
	Diffie-Hellman-like, and the rest of the algorithms use key-		changes in the exchanged messages and in the state machine, so
	encapsulation-mechanism (KEM). In the case of KEM, the initiator		that they can be easily implemented.
	randomly generates a random, ephemeral public and private key pair,
	and sends the public key to the responder in QSKEi payload. The
	responder generates a random entity, encrypts it using the received
	public key, and sends the encrypted quantity to the initiator in
	QSKEr payload. The initiator decrypts the encrypted payload using
	the private key. After this point of the exchange, both initiator
	and responder have the same random entity from which the quantum-safe
	shared secret (QSSS) is derived.
	The Transform Type #tba (Quantum-Safe Group) is defined as an		9) Deterministic operation. This requirement means that the hybrid
	optional type in IKE, AH and ESP protocols. This transform type MUST		post-quantum exchange, and thus, the computed key, will be based
	NOT exist if there is no Transform Type 4 in a proposal.		on algorithms that both client and server wish to support.
	For Transform Type #tba, the defined list of quantum-safe Transform		10) Fragmentation support. Some PQC algorithms could be relatively
	IDs are listed below. Note that the values below are only current as		bulky and they might require fragmentation. Thus, a design goal
	of the publication date of this document. Readers should refer to		is the adaptation and adoption of an existing fragmentation
	[IKEV2IANA] for the latest values.		method or the design of a new method that allows for the
			fragmentation of the key shares.
	Name Number Key exchange		11) Backwards compatibility and interoperability. This is a
	------------------------------------------------------		fundamental requirement to ensure that hybrid post-quantum IKEv2
	RLWE 128 1 Diffie-Hellman-like		and a non-post-quantum IKEv2 implementations are interoperable.
	NewHope 128 2 Diffie-Hellman-like
	NTRU EES743EP1 3 KEM
	NTRU-Prime 216 4 KEM
	2.2. IKE_SA_INIT Exchange		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.
	The IKE_SA_INIT request and response pairs negotiate cryptographic		3. The Framework of Hybrid Post-quantum Key Exchange
	algorithms, exchange nonces and perform a key exchange for an IKE SA.
	Initiator Responder		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
	--------------------------------------------------------------		--------------------------------------------------------------
	HDR, SAi1, KEi, [QSKEi,]		<-- First round (hybrid group negotiation) -->
	Ni -->
	The initiator sends a QSKEi payload which contains parameters needed		<-- Second round (hybrid quantum-safe key exchange) -->
	to established a quantum-safe shared secret. The QSKEi payload is
	marked as OPTIONAL so that it will be ignored by a responder who does
	not understand it. In this particular case, the responder will
	respond with a set of payloads as defined in IKEv2 [RFC7296], and
	therefore maintaining compatibility with existing implementation. On
	the other hand, if the responder implements this specification, it
	will respond as follows:
	<-- HDR, SAr1, KEr, [QSKEr,]		This hybrid post-quantum IKEv2 key exchange can occur in IKE_SA_INIT
	Nr, [CERTREQ]		or CREATE_CHILD_SA message pair which contains various payloads for
			negotiating cryptographic algorithms, exchanging nonces, and
			performing a Diffie-Hellman shared secret exchange for an IKE SA or a
			Child SA. These payloads are chained together forming a linked-list
			and this flexible structure allows additional key exchange payloads
			to be introduced. The additional key exchange uses algorithms that
			are currently considered to be resistant to quantum computer attacks.
			These algorithms are collectively referred to as post-quantum
			algorithms in this document.
	The QSKEr payload completes the quantum-safe shared secret between		3.2. Overall Protocol
	the initiator and responder.
	At this point in the negotiation, both initiator and responder is		In the following we overview the two protocol rounds involved in the
	able to compute:		hybrid post-quantum protocol.
	o a shared Diffie-Hellman secret from KEi and KEr pair, and		3.2.1. First Protocol Round
	o a quantum-safe shared secret from QSKEi and QSKEr pair.		In the first round, the IKE_SA_INIT request and response messages are
			used to negotiate the hybrid group. The method to negotiate and
			exchange post-quantum policies is achieved using the key exchange
			payload (with a Diffie-Hellman Group Num of #TBA). The KE payload
			with group number #TBA does not contain Diffie-Hellman or post-
			quantum public values, but proposed post-quantum algorithms and the
			policy for the post-quantum ciphers.
	Using these two shared secrets, each peer generates SKEYSEED, from		The initiator negotiates cryptographic suites as per RFC7296, the
	which all keying materials for protection of the IKE SA are derived.		only exception is, the Diffie-Hellman KE payload is not populated
	The quantity SKEYSEED is computed as follows:		with a keyshare, but rather the KE payload contains the proposed
			post-quantum algorithms and policies. The Diffie-Hellman groups are
			negotiated in the security association payload as per RFC7296 and the
			public values sent in the next round of exchange.
	SKEYSEED = prf(Ni | Nr, g^ir | QSSS)		When a responder that supports the hybrid exchange, receives an
			IKE_SA_INIT message with a KE payload with group number #TBA, it
			performs a lookup of the policies and algorithms contained within the
			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 also selects the
			cryptographic suites, including the chosen Diffie-Hellman Group Num
			in the security association payload as per RFC7296. In this exchange
			the Diffie-Hellman public value is not sent in the KE payload.
	where prf, Ni, Nr, and g^ir are defined as in IKEv2 [RFC7296]. QSSS		The initiator can signal support of IKE_SA_INIT message fragmentation
	is represented as an octet string. The seven secrets derived from		by including a payload fragmentation Notify payload. The responder
	SKEYSEED, namely SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr,		can also include this Notify payload to indicate support of
	are generated as defined in IKEv2 [RFC7296].		IKE_SA_INIT message fragmentation.
	Because the initiator sends a QSKE payload, which contains quantum-		The responder may choose to allocate state to the session, as the
	safe data, in the IKE_SA_INIT, it must guess a Q-S group that the		initial message is used in authenticating the IKE SA messages.
	responder will select from its list of proposed groups. If the		Optionally, the responder may prefer not to allocate any state and
	initiator guesses incorrectly, the responder will respond with a		reply with a cookie instead. The cookie can provide two functions.
	Notify payload of type INVALID_QSKE_PAYLOAD indicating the selected		One being the standard RFC7296 behaviour. The other benefit of using
	Q-S group and the initiator MUST retry the IKE_SA_INIT with the		the cookie is to provide fast detection of a downgrade attack without
	corrected Q-S group. There are two octets of data associated with		running into the risk of state exhaustion attacks. Whether or not
	this notification, which contains the accepted Quantum-Safe Group		any states are allocated, the responder detects the post-quantum
	Transform Type number in big endian order. As in the case of		cryptographic algorithms and policies that do not match and can then
	INVALID_KE_PAYLOAD, the initiator MUST again propose its full set of		abort the session prior to calculating the shared secrets. See
	acceptable cryptographic suites because the rejection message was not		Section 3.7 for more information on cookie and downgrade attack
	authenticated, which may lead to any potential vulnerabilities		prevention.
	exploitation.
	2.3. CREATE_CHILD_SA Exchange		Initiator Responder
			--------------------------------------------------------------
			HDR, SAi1, KEi(#TBA),
			Ni, [N(Pay Frag)] -->
	The CREATE_CHILD_SA exchange is used to create new Child SAs and to		<-- HDR, SAr1, KE(#TBA),
	rekey both IKE SAs and Child SAs. If the CREATE_CHILD_SA request		Nr, [N(Pay Frag),]
	contains a KE payload, it MAY also contain an optional QSKE payload		[N(COOKIE)]
	to enable quantum-safe forward secrecy for the Child SA. The keying
	material for the Child SA is a function of Sk_d established during
	the establishment of the IKE SA, the nonces exchanged during the
	CREATE_CHILD_SA exchange, the Diffie-Hellman value, and the quantum-
	safe data (if QSKE payload is included in the CREATE_CHILD_SA
	exchange).
	If a CREATE_CHILD_SA request includes a QSKEi payload, at least one		By using the KE payload, peers that do not support the hybrid
	of the SA offers MUST include a Q-S group in one of its transform		exchange will reject the initial negotiation and assuming that a
	structures. The Q-S group MUST be an element of the group that the		Diffie-Hellman Group Num contained in the Diffie-Hellman Group
	initiator expects the responder to accept. If the responder selects		Transform IDs was acceptable, the peer will send an
	a different Q-S group, the responder MUST reject the request by		INVALID_KE_PAYLOAD message to indicate its preferred Diffie-Hellman
	sending INVALID_QSKE_PAYLOAD Notify payload. The responder's		group. Note that using the KE payload enables backward compatibility
	preferred Q-S group is indicated in this notify payload. In the case		with existing RFC7296 implementations. If this scenario occurs, the
	of a rejection, the initiator should retry with another		initiator SHOULD retry the hybrid exchange. Dependent on policies,
	CREATE_CHILD_SA request containing a Q-S group that was indicated in		the initiator may retry the exchange as per RFC7296, and if this
	the INVALID_QSKE_PAYLOAD Notify payload.		occurs then the N(PQ_ALGO_POLICIES) notify payload MUST be included
			to prevent downgrade attacks. The N(PQ_ALGO_POLICIES) notify payload
			contains the same post-quantum algorithms and policies that were sent
			in the KE(#TBA) payload in the first round of IKE_SA_INIT request.
	2.3.1. New Child SAs from the CREATE_CHILD_SA Exchange		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 required to ensure that the post-
			quantum algorithms were not amended in the initial exchange,
			resulting in a downgrade attack.
	The CREATED_CHILD_SA request and response pair to create a new Child		Should the proposed post-quantum algorithms not be acceptable to the
	SA is shown below:		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 acceptable, but the post-quantum algorithms are 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 exchange and include the
			N(PQ_ALGO_POLICIES) payload to prevent downgrade attacks. Below is
			an example that shows the proposed hybrid group is not supported by
			the responder and that the responder prefers a Diffie-Hellman Group
			19 (P-256), assuming that this group is in the list proposed
			(although it 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 use of hybrid exchange,
			these MUST not revert to using the classical IKEv2 exchange. This
			should be a configurable parameter in implementations.
			As per RFC7296, should the responder not accept any of the
			cryptographic suites that were sent in the security association
			payload, a NO_PROPOSAL_CHOSEN message is responded, as depicted
			below.
	Initiator Responder		Initiator Responder
	--------------------------------------------------------------		--------------------------------------------------------------
	HDR, SK {SA, Ni,		HDR, SAi1, KEi(#TBA),
	[KEi,] [QSKEi,] TSi, TSr} -->		Ni, [N(Pay Frag)] -->
	<-- HDR, SK {SA, Nr,		<-- HDR, N(NO_PROPOSAL_CHOSEN)
	[KEr,] [QSKEr,] TSi, TSr}
	The initiator sends an encrypted request containing SA offer(s), a		3.2.2. Second Protocol Round
	nonce, optional Diffie-Hellman and quantum-safe key exchange data and
	the proposed Traffic Selectors.
	The responder replies with an encrypted response containing the		In the second protocol round, the initiator sends again the
	accepted SA offer, a nonce, a Diffie-Hellman value if KEi was		IKE_SA_INIT request. The main difference is that this message
	included in the request and the expected Diffie-Hellman group was		includes the key-shares associated to each of the post-quantum
	selected, a quantum-safe data if QSKEi was included in the request		algorithms agreed in the previous round. Each key-share is
	and the expected Q-S group was selected, and the accepted Traffic		transported in a KE payload, and therefore there may exist multiple
	Selectors.		KE payloads in the second round of the IKE_SA_INIT message.
			Furthermore, these KE payloads may be fragmented if the key-shares
			are large and both peers indicate the support of fragmentation.
	The keying material of these CREATE_CHILD_SA exchanges that have both		In a general hybrid arrangement, the RFC7296 Diffie-Hellman public
	KE and QSKE payloads is defined as:		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 ordering is not mandatory.
	KEYMAT = prf+(SK_d, QSSS (new) | g^ir (new) | Ni | Nr)		If the responder sent a cookie in the first round of exchange, the
			initiator MUST 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 type #TBA sent in the first
			round of the exchange, in a notify payload N(PQ_ALGO_POLICIES). The
			responder MUST examine the post-quantum algorithms and policies, and
			confirm that the presented KE payloads match those represented by the
			cookie, see Section 3.7 for more information. Should an anomaly or a
			mismatch be detected, the responder MUST abort the session. On the
			other hand, if the validation passes, then the responder can proceed
			to compute a shared secret as detailed in Section 3.3.
	where prf+, Sk_d, g^ir (new), Ni and Nr are defined in IKEv2		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 initiator has
			received all key-shares from the responder, the initiator can compute
			the same shared secret following the description in Section 3.3.
	[RFC7296], and QSSS (new) is the shared secret from the ephemeral		Below is an example message exchanged in the second round of
	quantum-safe key exchange. The QSSS quantity is represented as an		IKE_SA_INIT message.
	octet string.
	2.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange		Initiator Responder
			--------------------------------------------------------------
			HDR, [N(COOKIE),] SAi1,
			KEi1[, KEi2, ..., KEiX,]
			Ni[, N(PQ_ALGO_POLICIES)] -->
	The CREATE_CHILD_SA request and response pair for rekeying an IKE SA		<-- HDR, SAr1, KEr1[, KEr2,
	is shown below:		..., KErX,] Nr
	Initiator Responder		For implementations that are to be used by peers that are pre-
			configured with matching hybrid policies, resulting in the initial
			exchange used to negotiate the post-quantum policies and algorithms
			contained in the first round of exchanges being redundant, the
			initiator can skip the first round of exchanges by sending the
			IKE_SA_INIT containing the key-shares. However the initiator MUST be
			sure that the responder will accept the presented key-shares. In this
			instance the responder is open to abuse by fragmentation related
			attacks and MUST revert to using the initial exchange, should it find
			itself under any form of attack.
			3.2.3. Child SA Negotiation
			After the initial IKE SA is negotiated, either side may later
			negotiate child SAs or rekey the IKE SA which may involve a fresh key
			exchange. If a hybrid group is desired, then the initiator proposes
			a Transform Type 4 (Diffie-Hellman) of (TBA); he includes the KE
			payloads for the key exchange types that were negotiated for the
			child SAs during the initial negotiation (see Section 3.5.1). The
			responder replies with the corresponding KE payloads, and both use
			the shared secrets to generate the child SA keying material (see
			section 3.3). If hybrid groups were not initially negotiated as a
			part of the initial key exchange, then child SAs MUST NOT propose a
			hybrid group.
			Specifically, the key exchange for creating a child SA using a hybrid
			group is:
			Initiator Responder
	--------------------------------------------------------------		--------------------------------------------------------------
	HDR, SK{SA, Ni,		HDR, SK{SA, Ni, KEi1, KEi2,
	KEi[, QSKEi]} -->		..., KEiN, TSi, TSr} -->
	<-- HDR, SK {SA, Nr,		<-- HDR, SK{SA, Nr, KEr1, KEr2,
	KEr[, QSKEr]}		..., KErN, TSi, TSr}
	The initiator sends an encrypted request containing amongst other		where both SA payloads include a transform type 4 of (TBA), and the
	payloads, a KEi payload which carries a Diffie-Hellman value, and an		KEi1, ..., KEiN, KEr1, ..., KErN are the KE types there were
	OPTIONAL QSKEi payload which carries a quantum-safe data.		initially negotiated.
	The responder replies with an encrypted response containing a number		3.3. Computation of a Post-Quantum Shared Secret
	of payloads. If the responder selects a Diffie-Hellman group that
	matches one of the proposed group(s), a KEr payload containing a
	Diffie-Hellman public value is replied in the encrypted response. If
	the request contains a QSKEr payload and the responder selects a Q-S
	group that matches one of the proposed group(s), a QSKEr payload
	containing quantum-safe data is sent in the reply.
	The quantity SKEYSEED for the new IKE SA is computed as follows:		After the second protocol round detailed in Section 2.2., both
			initiator and responder can compute the common shared secrets to
			generate an SKEYSEED, from which all keying materials for protection
			of the IKE SA are derived. The quantity SKEYSEED is computed as
			follows:
	SKEYSEED = prf(SK_d (old), QSSS (new) | g^ir (new) | Ni | Nr)		SKEYSEED = prf(Ni | Nr, SS1 | SS2 | ...| SSN)
	where prf, SK_d (old), g^ir (new), Ni and Nr are defined in IKEv2		where prf, Ni and Nr are defined as in IKEv2 [RFC7296], SSi
	[RFC7296], QSSS (new) is the shared secret from the ephemeral		represents the i-th shared secret computed from the i-th key exchange
	quantum-safe key exchange. The QSSS quantity is represented as an		algorithm contained in the hybrid group that was negotiated in the
	octet string.		protocol. Note that if at least one of these SSi is a classical
			shared secret that is FIPS approved, then FIPS compliance design
			criteria as outlined in Section 2 is achieved. The seven secrets
			derived from SKEYSEED, namely SK_d, SK_ai, SK_ar, SK_ei, SK_er,
			SK_pi, and SK_pr, are generated as defined in IKEv2 [RFC7296].
	2.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange		For child SAs that are negotiated using a hybrid group, the keying
			material is defined as:
	The CREATE_CHILD_SA request and response pair for rekeying a Child SA		KEYMAT = prf+(SK_d, SS1 | SS2 | ... | SSN | Ni | Nr)
	is shown below:
	Initiator Responder		where SSi represents the i-th shared secret computed from the i-th
	--------------------------------------------------------------		key exchange algorithm that was performed during the negotiation of
	HDR, SK {N(REKEY_SA), SA,		the child 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		When rekeying an IKE SA using a hybrid group, the new SKEYSEED is
	payloads, which are sent encrypted by the initiator, carry a Diffie-		computed as:
	Hellman value and quantum-safe data respectively.
	If the CREATE_CHILD_SA request includes KEi and QSKEi payloads,		SKEYSEED = prf(SK_d (old), SS1 | SS2 | ... | SSN | Ni | Nr)
	provided that a Diffie-Hellman group and a Q-S group are present in
	the SA offers, the responder replies with an encrypted response
	containing both KEr and QSKEr payloads.
	The keying material computation of this exchange is the same as that		where SSi represents the i-th shared secret computed from the i-th
	defined in [Section 2.3.1].		key exchange algorithm that was performed during the negotiation of
			the new IKE SA.
	2.4. QSKE Payload Format		3.4. Post-Quantum Group Transform Type and Group Identifiers
	The quantum-safe key exchange payload, denoted QSKE in this document,		In generating keying material within IKEv2, both initiator and
	is used to exchange a quantum-safe shared secret between two IKE		responder negotiate up to four cryptographic algorithms in the SA
	peers. The QSKE payload consists of the IKE generic payload header,		payload of an IKE_SA_INIT or a CREATE_CHILD_SA exchange. One of the
	a two-octet value denoting the Quantum-Safe Group number, and		negotiated algorithms is a Diffie-Hellman algorithm, which is used
	followed by the quantum-safe data itself. The format of the QSKE		for key exchange. This negotiation is done using the Transform Type
	payload is shown below.		4 (Diffie-Hellman Group) where each Diffie-Hellman group is assigned
			a unique value.
			In order to enable a post-quantum key exchange in IKEv2, the various
			post-quantum algorithms MUST be negotiated between two IKEv2 peers.
			To this end, this draft assigns new meanings to various transforms of
			transform type 4 ("Diffie-Hellman group"). It assigns identifiers to
			each of the various post-quantum algorithms (even though they are not
			actually Diffie-Hellman groups, they are methods of performing key
			exchange). In addition, it assigns two artificial values that are
			not actually key exchange mechanisms, but are used as a part of the
			negotiation.
			We expect that in the future, IANA will assign permanent values to
			these transforms. Until it does, we will use the following mappings
			in the 'reserved for private use space':
			0x9000 HYBRID - this signifies that we are negotiating a hybrid
			group, the details are listed in the KE payload.
			The following values are reserved for the below key exchanges: 0x9100
			- 0xXXXX. The following abstract identifiers are used to illustrate
			their usage in our framework. Actual identifiers will be maintained
			by IANA and updated during the NIST standardization process.
			Name Number Key exchange
			--------------------------------------------------
			NIST_CANDIDATE_1 0x9100 The 1st candidate of
			NIST PQC submission
			NIST_CANDIDATE_2 0x9101 The 2nd candidate of
			NIST PQC submission
			Because we are using transforms in the private use space, both the
			initiator and responder must include a vendor id with this payload:
			d4 48 11 94 c0 c3 4c 9d d1 22 76 aa 9a 4e 80 d5
			This payload is the MD5 hash of "IKEv2 Quantum Safe Key Exchange
			v1"). If the other side does not include this vendor id, an
			implementation MUST NOT process these private use transforms as
			listed in this draft.
			3.5. Hybrid Group Negotiation
			Most post-quantum key agreement algorithms are relatively new, and
			thus are not fully trusted. There are also many proposed algorithms,
			with different trade-offs and relying on different hard problems.
			The concern is that some of these hard problems may turn out to be
			easier to solve than anticipated (and thus the key agreement
			algorithm not be as secure as expected).
			A hybrid solution allows us to deal with this uncertainty by
			combining classical key exchanges with post-quantum key agreements.
			However, there are many post-quantum proposals that when combined can
			lead to many potential hybrid groups. Furthermore, different
			organizations might have different requirements when using a hybrid
			group. For instance, the type of underlying problem that is trusted,
			the minimum number of algorithms that should be used in a hybrid
			group, or the security strength of each of the algorithms. For these
			reasons, hybrid groups might lead to many potential combinations
			difficult to define, maintain and standardize. This motivates our
			hybrid group negation protocol.
			Our hybrid group negotiation protocol allows the initiator and
			responder to agree on a common hybrid group based on their respective
			policies. The protocol categorizes each type of key exchange into a
			type T, which is based on the type of hard problem it relies upon.
			We use the aforementioned abstract identifiers to illustrate the
			idea.
			Given this categorization of the key agreement protocols, initiator
			and responder have security policies that define the minimum number
			of post-quantum algorithms that they require in a hybrid group and
			also the types of key agreement protocols that they support (and
			therefore, trust). The initiator and responder can then engage in a
			simple protocol that allows them to compute a common hybrid group
			fulfilling their policies. The protocol for the initiator and
			responder is described below.
			Note that it would be possible for the responder to search for a
			mutually acceptable combination without specifying the key exchange
			types, however the algorithm to search for such a combination would
			be considerably more complex. This design assumes that the security
			policies of the initiator and the responder will rely on key
			exchanges based upon distinct types of hard problems, and hence the
			additional complexity of the more general algorithm is not warranted.
			3.5.1. Protocol for the Initiator
			To define the protocol, we first define a "DH_Group_List", this is a
			list of groups of a specific type; it has the format:
			1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+---------------------------------------------------------------+
			| T | N |
			+---------------------------------------------------------------+
			| PQC_ID_1 | PQC_ID_2 |
			~ ... ~ ... ~
			| PQC_ID_N | 0 |
			+---------------------------------------------------------------+
			where
			o T is the type of the groups that are in this list, with this
			proposed encoding:
			- 0x0001 is classical
			- 0x0002 is lattice
			- 0x0003 is code-based
			- 0x0004 is isogeny-based
			- 0x0005 is symmetric (preshared key)
			o N is the number of groups that make up the list. The semantics
			of this proposal is that the initiator is proposing M different
			types of groups; any selection of one group from K different
			types will be acceptable.
			o PQC_ID_1, PQC_ID_2, PQC_ID_N, such as NIST_CANDIDATE_1, is the
			identifier for the PQC algorithm to be used for negotiation, in
			order of preference.
			o 0 is padding, present if N is odd.
			The semantics of this list is that these are the groups of PQC
			algorithms of type T that are acceptable to the initiator.
			We now define a "DH_Group_Policy"; this is a list of group types that
			are negotiated together. It has the format:
			1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+---------------------------------------------------------------+
			| K | M |
			+---------------------------------------------------------------+
			| DH Group List 1 |
			+---------------------------------------------------------------+
			| DH Group List 2 |
			~ ... ~
			| DH Group List M |
			+---------------------------------------------------------------+
			where:
			o K is the minimum number of group lists that must be satisfied;
			o M is the number of group lists;
			o DH_Group_LIST_1, ..., DH_Group_List_M are the lists of
			different types of DH groups, in order of preference.
			The semantics of this proposal is that the initiator is proposing M
			different types of groups; any selection of one group from K
			different types will be acceptable.
			For example, suppose our policy is "we must agree on at least 2
			groups from the list (P-256, P-384), (NIST_CANDIDATE_1,
			NIST_CANDIDATE_2; both of type lattice) and (NIST_CANDIDATE_1 of type
			isogeny), where NIST_CANDIDATE_1 and NIST_CANDIDATE_2 of type lattice
			are assigned group numbers 40 and 41 respectively, and
			NIST_CANDIDATE_1 of type isogeny is assigned group number 60"; we
			have the following list (in hexadecimal)
			0002 0003 0001 0002 0013 0014 0002
			0002 0028 0029 0004 0001 003c 0000
			which is parsed as
			0002 K = 2
			0003 We have 3 group lists
			0001 0002 First list is of type classical, and consists of two
			groups
			0013 0014 Group 19 (P-256) and group 20 (P-384)
			0002 0002 Second list is of type lattice, and consists of two
			groups
			0028 0029 Group 40 (NIST_CANDIDATE_1 of type lattice) and group
			41 (NIST_CANDIDATE_2 of type lattice)
			0004 0001 Third list is of type isogeny, and consists of one
			group
			003c Group 60 (NIST_CANDIDATE_1 of type isogeny)
			0000 Zero-pad
			We can now give the format that the initiator sends to the responder
			in the KEi payload. 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 negotiated for both the initial IKE exchange, as well as any child
			SA exchanges. If the initiator uses the second format, then the
			first policy listed will be used for the initial IKE exchange; the
			second policy listed will be used for any child SA negotiations.
			3.5.2. Protocol from the Responder
			If the responder finds a combination of groups that are mutually
			acceptable, then it responds with the KEr payload in one of the
			following two formats:
			1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+---------------------------------------------------------------+
			| 0 | N |
			+---------------------------------------------------------------+
			| DH_1 | DH_2 |
			~ ... ~ ... ~
			| DH_N | 0 |
			+---------------------------------------------------------------+
			1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+---------------------------------------------------------------+
			| 0 | N_Initial |
			+---------------------------------------------------------------+
			| DH_1 | DH_2 |
			~ ... ~ ... ~
			| DH_N_Initial | 0 |
			+---------------------------------------------------------------+
			| 0 | N_Child |
			+---------------------------------------------------------------+
			| DH_1 | DH_2 |
			~ ... ~ ... ~
			| DH_N_Child | 0 |
			+---------------------------------------------------------------+
			where
			o 0 is a fixed 0000 pattern;
			o N, N_Initial, N_Child is the number of groups that 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 SA and 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 negotiate. To search the initiator's vector to
			find such a mutually acceptable combination, the responder can run
			the following algorithm.
			1. Set list of accepted DH groups to empty
			2. Set K to the maximum of (minimum number 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 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 message size exceeds the path MTU, the IKE messages are
			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 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 is a high
			chance that IP fragmentation will occur in IKE_SA_INIT messages.
			The maximum length of an IKE payload is 65,535 octets. It is
			anticipated that some post quantum algorithms will require a key
			exchange payload size that is greater than 65,535 octets.
			Furthermore, CERT payloads in IKE_AUTH messages are expected to
			exceed 65,565 octets when sending certificates containing post
			quantum public keys and signatures.
			To overcome these limitations we present a method to split any
			payload into multiple fragments and optionally send these fragments
			in separate IKE_SA_INIT messages.
			3.6.2. Fragmentation Solution
			To enable fragmentation of IKE payloads, we introduce new
			FRAG_POINTER and FRAG_BODY payloads. Further, we introduce a method
			of sending payload fragments in multiple IKE_SA_INIT messages as well
			as a method of sending payload fragments in encrypted IKE messages
			which then may or may not be fragmented using RFC 7383's IKEv2
			message fragmentation.
			3.6.2.1. Fragmentation Pointer Payload
			In place of any payload within an IKE packet, the sender may replace
			it with a FRAG_POINTER payload; this FRAG_POINTER type (rather than
			the original payload type) will appear in the next payload field of
			the previous payload (or IKE header). This payload has the following
			format
			1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Next Payload |C| RESERVED | Payload Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Payload Type | Fragment Identifier |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Total Payload Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Fragment Length | RESERVED |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			where:
			o C is the Critical flag for the original payload.
			o Payload Type is the payload type of the original payload; e.g. if
			this payload is a KE payload, this will be the value 34.
			o Fragment Identifier is a 24 bit value that the sender does not
			reuse often, that is, within the timeout period of this IKE
			packet. It is intended to be used to allow the receiver to
			correlate the fragments (contained in other packets) to the
			payload within the original IKE packet.
			o Total Payload Length is the length of the original payload. Note
			that this draft allows the transmission of payloads greater than
			64k, if necessary.
			o Fragment Length is the amount of data contained within each
			fragment (except for the last fragment, which may be smaller).
			o RESERVED will be an all-0's field.
			3.6.2.2. Fragmentation Body Payload
			The sender can split the contents of any payload across one or more
			FRAG_BODY payloads. This payload has the format:
			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 | Fragment Number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			~ Payload Data ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			where:
			o Next Payload is the identifier for the payload type of the next
			payload in the message. There may be additional restrictions on
			the value of Next Payload during the fragmentation of an
			IKE_SA_INIT message, see Section 3.6.2.3 below.
			o Payload Type, Fragment Identifier, Total Payload Length, Fragment
			Length are the same as the corresponding fields in the
			FRAG_POINTER payload. Take careful note, like the other fields
			described here the Fragment Length field will be identical across
			all fragments. Thus, if this is the last fragment, Fragment
			Length could be longer than the size of the Payload Data field.
			o Fragment Number is the current fragment message number, starting
			from 1. 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 Payload Data of the fragment, but any additional payload
			header fields after the Generic Payload Header MUST be included.
			The Generic Payload Header cannot be included because it includes
			the 16-bit Payload Length field, however the length of a
			fragmented payload may require more than 16 bits to be stored.
			The logical contents of the reassembled payload will be
			Payload Data[1] | PayloadData[2] | ... | PayloadData[N]
			where N = Total Payload Length / Fragment Length (rounded up).
			As an example, the following KE payload could be fragmented into a
			FRAG_POINTER and two FRAG_BODY payloads with Fragment Length of 1000
			as follows:
	1 2 3		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 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 |		| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Quantum-Safe Group Num | RESERVED |		| Diffie-Hellman Group Num | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Quantum-Safe Data ~		~ 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
	The length of the quantum-safe data varies depending on the type of		1 2 3
	quantum-safe cipher. The content type of quantum-safe data is also		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
	dependent on the type of quantum-safe cipher. For quantum-safe		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	ciphers that use Diffie-Hellman-like key exchange, the content of the		| Next Payload |C| RESERVED | Payload Length |
	quantum-safe data is the proposed/accepted cipher's public value.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	For ciphers that use KEM, the content is either a random public-key		| KE | Fragment Identifier |
	of the proposed quantum-safe cipher in the case of QSKEi payload, or		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	the content is a ciphertext produced using the received public-key in		| Total Payload Length (1504) |
	the case of QSKEr payload.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 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.
	The Quantum-Safe Group Num identifies the quantum-safe cipher with		1 2 3
	which the quantum-safe data was computed. The Quantum-Safe Group Num		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
	MUST match the Q-S group specified in a proposal in the SA payload		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	sent in the same message. If the proposal in the SA payload does not		| Next Payload |C| RESERVED | Payload Length |
	specify a quantum-safe cipher, the QSKE payload MUST NOT be present.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	If the responder selects a Q-S group that does not match the proposed		| KE | Fragment Identifier |
	group, the quantum-safe key exchange MUST be rejected with a Notify		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	payload of type INVALID_QSKE_PAYLOAD. The chosen Q-S group is		| Total Payload Length (1504) |
	indicated in the INVALID_QSKE_PAYLOAD Notify payload and the		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	initiator can restart the exchange with that group.		| Fragment Length (1000) | Fragment Number (2) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			~ Key Exchange Data[996..1499] (504 bytes) ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 4: Example FRAG_BODY Payload 2 for KE Payload
	The payload type for the QSKE payload is TBA (TBA).		3.6.2.3. Fragmentation Semantics
	3. Design Rationale		If the receiver supports this fragmentation extension, the sender may
			fragment any payload by replacing the payload with a FRAG_POINTER
			payload and one of more FRAG_BODY payloads. If IP fragmentation is
			not a concern (e.g. when IKEv2 fragmentation is achieved using
			encrypted fragment payloads, or it's known that IP fragmentation of
			IKE_SA_INIT won't be an issue) then the corresponding FRAG_BODY
			payloads MUST appear anywhere after the FRAG_POINTER in an IKE
			message.
	In general, the size of QSKE payload is larger than that of the KE		An IKE_SA_INIT message may be fragmented across multiple IKE messages
	counterpart and sending it in the IKE_SA_INIT may prevent peers from		using this payload fragmentation. In this case the sender first
	establishing IPSec Security Association (SA) due to fragmentation.		sends an IKE_SA_INIT message containing the FRAG_POINTER payloads and
	While the fragmentation issue may be addressed by sending QSKE in the		any unfragmented payloads. Then it sends one IKE_SA_INIT message per
	IKE_AUTH exchange, it is decided that QSKE should still be exchanged		FRAG_BODY payload generated from the original IKE_SA_INIT message.
	in the IKE_SA_INIT. The rationale behind this decision is discussed		Each IKE_SA_INIT message must be sent with a Message ID of 0. Each
	below.		IKE_SA_INIT message subsequent to the first one MUST contain one
			FRAG_BODY payload, MAY contain a COOKIE notification and SHOULD NOT
			contain any other payloads. Since FRAG_POINTER support is negotiated
			in an initial IKE_SA_INIT round-trip which didn't generate any shared
			keys, the responder had the opportunity to send a COOKIE notify
			payload back to the initiator. This COOKIE can be used by the
			responder as a denial-of-service prevention measure. If the sender
			received a COOKIE notification payload in the initial exchange, it
			MUST include the COOKIE notify payload in each fragmented IKE_SA_INIT
			message that it sends. This allows the receiver to reject any
			IKE_SA_INIT messages without a COOKIE or with an unrecognized COOKIE,
			thus mitigating a DoS attack where an attacker sends malformed
			IKE_SA_INIT messages containing a FRAG_BODY payload which the
			receiver would enqueue, filling up its receiving buffers. Note, this
			does not prevent an attack where the attacker listens in on messages
			to determine a valid COOKIE and emits malformed IKE_SA_INIT messages
			with that cookie, or where it sends a valid initial round IKE_SA_INIT
			message to received a valid cookie and then emit malformed messages
			using that cookie.
	3.1. Threat Categories		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 contained in the IKE
			message, if they are not the receiver MUST reject the IKE message.
	The treats to the IKE exchange can be broken into two categories:		When the receiver receives an IKE_SA_INIT message, is may have to
			process several IKE_SA_INIT messages to reconstruct the original
			unfragmented message. If it receives the initial message containing
			the FRAG_POINTER payloads, it enqueues that message and awaits the
			corresponding IKE_SA_INIT messages containing the FRAG_POINTER
			payloads needed to reconstruct the original message. In addition, if
			it receives a FRAG_BODY message without receiving a corresponding
			FRAG_POINTER payload first, it may enqueue that payload.
	1. From current day until general purpose quantum computers are		The receiver may vet the declared payload length, and reject it if it
	available.		decides that the length is too long.
	The addition of the QSKE allows the IKEv2 exchange to be		Also note that we allow the FRAG_BODY payload to consist of the
	secured against an adversary who captures all control plane		entire payload; this can happen if (for example) the MTU size is
	(IKE) and data plane (ESP) traffic, with the intention of		1500, and we want to transmit a 1300 byte KE payload, in addition to
	breaking the IKE exchange (when quantum computers become		400 bytes of other IKE data.
	available) and subsequently being able to view the data plane
	traffic. The use of the QSKE in the IKE_SA_INIT results in
	the IKE SA becoming quantum secure against future attacks.
	2. After general purpose quantum computers are available.		Once all the FRAG_BODY payloads have been received and reassembled,
			the IKE receiver may commence parsing the IKE packet. This proceeds
			as normal, except that when it sees a payload of type FRAG_POINTER,
			it looks into the FRAG_POINTER payload to see the actual payload type
			and length, and refers to the reassembly buffer for the actual
			payload data.
	Once general purpose quantum computers are available there are		Note about the criticality field; a FRAG_POINTER field may be marked
	two types of attack:		as noncritical, which means that the IKE parser may ignore it if it
			does not understand the payload type within the FRAG_POINTER payload.
			However, even if it does that, it MUST still reassemble all the
			FRAG_BODY payloads (because of the IKE AUTH processing depends on
			them).
	o Active attack		3.6.2.4. IKE AUTH Processing
	Assuming that a general purpose quantum computer is		When generating the IKE AUTH payload, the reassembled texts contained
	available and an adversary can manipulate the IKE exchange		within the FRAG_BODY payloads is logically appended to the IKE
	in real time. The attacker can break Diffie-Hellman in		message (and before the nonce). Specifically, we modify how
	real time, but not the QSKE. This results in the IKE_AUTH		InitiatorSignedOctets and ResponderSignedOctets are computed as
	exchange being secure as the QSKE is included in the		follows:
	derivation of key material used to secure the IKE_AUTH
	exchange.
	However, an active attacker who can sit between two hosts		InitiatorSignedOctets = RealMessage1 | PayloadData1 |
	and impersonate each host can perform a man-in-the-middle		PayloadData2 | ... | PayloadDataN |
	(MitM) attack when the authentication method is not quantum		NonceRData | MACedIDForI
	secure. This includes any asymmetric authentication method
	and non-quantum computer resistant Extensible
	Authentication Protocol (EAP) authentication. For
	authentication methods which are quantum secure, such as
	using shared key message integrity code comprising a
	shared-secret with sufficient entropy (256 bits), this
	allows for the IKEv2 exchange to be secured against an
	active adversary when including the QSKE.
	o Passive attack		ResponderSignedOctets = RealMessage2 | PayloadData1 |
			PayloadData2 | ... | PayloadDataN |
			NonceIData | MACedIDForR
	As per the first category, the addition of the QSKE allows		where PayloadData1, ..., PayloadDataN are the fields from the
	the IKEv2 exchange to be secured against an adversary who		FRAG_BODY payloads associated with the IKE message being
	captures all control plane (IKE) and data plane (ESP)		authenticated, in the same order that the corresponding FRAG_POINTERS
	traffic, with the intention of breaking the IKE exchange.		appear in, and for payloads from the same FRAG_POINTER, in increasing
			FRAGMENT_NUMBER order.
	3.2. Dealing with Fragmentation		3.6.2.5. Design Rationale
	In some instances, the QSKE public value will be large enough to		The contents of the FRAG_POINTER/FRAG_BODY payloads were designed to
	cause fragmentation to occur at the IP layer. In practice, there		make it easy to reassemble. The initial segments of the payloads
	will be cases where IKE traffic fragmented at the IP layer will be		were intentionally kept identical (to simply the processing if the
	dropped by network devices such as NAT/PAT gateways, Intrusion		FRAG_BODY arrived first); the receiver always knows how long the
	Prevention System (IPS), firewalls and proxies, that cannot handle IP		payload will be (allowing the allocation of buffers, if required);
	fragments or are configured to block IP fragments. This blocked		the receiver always knows the location in the payload data of each
	traffic will prevent the IKE session from being established. The		fragment (and so is able to save the data immediately into the
	issue with fragmentation can easily be avoided by moving the QSKE to		buffer), and the receiver can compute the number of fragments up
	the IKE_AUTH exchange and by employing IKEv2 Message Fragmentation		front (and hence can easily tell when all fragments have been
	[RFC7383]. The implication of this is that while all the Child SAs,		received).
	which carry the data traffic, would be quantum secure, the IKE SA
	itself would not be, resulting in the disclosure of IKE identities
	and IPsec proxies. Furthermore by sending the QSKE in IKE_AUTH and
	not IKE_SA_INIT would allow an active attacker with a quantum
	computer to perform attacks against IKE such as forging an identity
	used for authentication, abuse of attributes sent in the CFG
	exchange, MitM attack, DoS, etc. It is believed that the trade off
	to deliver a quantum resistant IKE SA is of greater security benefit
	than the issues that could be encountered due to fragmentation at the
	IP layer. It is worth noting that encapsulating IKE traffic within
	TCP [IKETCPENCAP] is a simple method to prevent IKE_SA_INIT traffic
	being fragmented at the IP layer.
	The following table gives an idea of the common size of the QSKE		The method of performing IKE AUTH processing was also designed to
	payload in the proposed schemes.		make it easy to implement; that PayloadData1 | PayloadData2 | ... |
			PayloadDataN is just the reassembled payloads concatenated together.
	Scheme QSKE size (octets)		3.7. Protection against Downgrade Attacks
	-------------------------------------
	RLWE 128 4096
	NewHope 128 1792
	NTRU EES743EP1 1030
	NTRU-Prime 216 1200
	It is evident that both NewHope 128 and RLWE 128 will naturally		In RFC7296, man-in-the-middle (MitM) downgrade attack is prevented by
	increase an IP Maximum Transmission Unit (MTU) to be larger than 1500		always resending the full set of group proposal in subsequent
	octets which is common for most Internet traffic, resulting in the		IKE_SA_INIT messages if the responder chooses a different Diffie-
	IKE_SA_INIT being fragmented at the IP layer.		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 a genuine
			response from a responder that does not understand or support the
			selected hybrid key exchange, or it could also be a malicious
			downgrade response from an MitM attacker. The initiator, on the
			second round of the exchange, MUST send the same cipher proposals and
			policies as in the first exchange round to indicate that the
			initiator would have preferred to use the hybrid key exchange. The
			responder MUST check that the chosen proposal is indeed not caused by
			a downgrade attack. If the check fails, it indicates a potential
			downgrade attack and the connection SHALL be dropped immediately.
	3.3. Removal of the Diffie-Hellman exchange		In order to check the proposals and policies, the responder may
			choose to maintain states between IKE_SA_INIT rounds. However, this
			increases the risk of state exhaustion attack. Of course, the
			responder may decide not to allocate any states and rely on the
			authentication in IKE_AUTH for any tampering of the exchange.
			Unfortunately, this option does not offer the benefit of an early
			downgrade attack detection; the responder will have to spend
			resources computing entities such as shared secrets and
			authentication code before knowing whether or not there is a
			downgrade attack. Such a benefit may be obtained by encoding some
			information into a cookie (Section 2.6. RFC7296).
	The IKE_SA_INIT exchange currently mandates the use of the Diffie-		Whilst this document does not mandate how information should be
	Hellman. As the Diffie-Hellman exchange is not quantum secure and		encoded to form the cookie, it could be efficiently done as follows
	the QSKE exchange is quantum secure, the addition of the QSKE can be
	thought of making the Diffie-Hellman redundant. This draft does not
	advise removing the use of Diffie-Hellman, though future
	implementations that have migrated to using QSKE could remove the
	requirement to send the Diffie-Hellman exchange with the QSKE
	providing the same functionality. Sending the QSKE in the
	IKE_SA_INIT allows for a simple transition to only using QSKE should
	the need to remove the Diffie-Hellman exchange occur.
	4. Security Considerations		Cookie = <VersionIDofSecret> | Hash(KEi(#TBA) | <secret>)
			where KEi(#TBA) is the KE payload in the first round of IKE_SA_INIT
			exchange, <secret> is a randomly entity generated by the responder
			which SHOULD be changed periodically as suggested in RFC7296, and the
			entity <VersionIDofSecret> should be updated whenever <secret> is
			changed. In this scenario, the responder calculates a cookie value
			from the first round of the IKE_SA_INIT request message and sends it
			to the initiator as part of the first round IKE_SA_INIT response
			message. The initiator echoes back the cookie and a
			N(PQ_ALGO_POLICIES) notify payload along with other IKE_SA_INIT
			attributes. When the responder receives the second round of the
			IKE_SA_INIT message, it recalculates the cookie value and checks
			whether or not this value is the same as the one in the previous
			round of the exchange, which is available from N(PQ_ALGO_POLICIES).
			If they mismatch, it indicates an attempt to force a downgrade attack
			and therefore the connection SHALL be terminated. As before, any
			attempts of the attacker to modify the packets so that cookie
			validation passes will be detectable in IKE_AUTH stage.
			In the event of the value <secret> goes out-of-sync, as suggested in
			RFC7296, the responder MAY reject the request by responding with a
			new cookie, or it MAY keep using the old value of <secret> for a
			short time and accept cookies computed from either one.
			The complete two-round IKE_SA_INIT message exchange flow with cookie
			is shown below. In this particular example, the responder
			understands and accepts the hybrid key exchange proposed in the first
			IKE_SA_INIT round.
			Initiator Responder
			--------------------------------------------------------------
			HDR, SAi1, KEi(#TBA),
			Ni, [N(Pay Frag)] -->
			<-- HDR, SAr1, KE(#TBA),
			Nr, N(COOKIE),
			[N(Pay Frag),]
			HDR, N(COOKIE), SAi1,
			KEi1[, KEi2, ..., KEiX,]
			Ni, N(PQ_ALGO_POLICIES) -->
			<-- HDR, SAr1, KEr1[, KEr2,
			..., KErX,] Nr
			The following shows the flow whereby the responder does not support
			the proposed hybrid key exchange and proposes to switch to classical
			Diffie-Hellman key exchange of 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 amends the
			KE(#TBA) payload in the first IKE_SA_INIT request round and also then
			amends the N(PQ_ALGO_POLICIES) payload in the second IKE_SA_INIT
			request round to create a match. In this instance, IKE_AUTH
			authentication SHALL fail due to the InitiatorSignedOctets being
			inconsistent between both peers.
			The decision to use a cookie or allocate state SHOULD be a decision
			taken by the responder. This should be a configurable value, and/or
			activated when a certain threshold of half open connections is
			reached. The cookie is sent in addition to the other attributes
			contained in first round of IKE_SA_INIT response.
			The cookie does not mitigate an attack whereby an adversary cause the
			responder to perform many lookups for the post-quantum algorithms and
			policies, resulting in a denial-of-service (DoS) condition. In order
			to mitigate this type of attack, the RFC7296 cookie mechanism or a
			puzzle-solving mechanism as described in RFC8019 SHOULD be used. A
			responder MAY decide to combine DoS and downgrade prevention cookies,
			in which case, the combined cookie may be encoded as follows
			Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi |
			KEi(#TBA) | <secret>)
			where Ni, IPi and SPIi are as described in 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 introducing unnecessary notify payloads,
			we considered communicating the hybrid post-quantum proposal in
			the KE payload during the first pass of the protocol exchange.
			Unfortunately, this design is susceptible to the following
			downgrade attack. Consider the scenario where there is an MitM
			attacker sitting between an initiator and a responder. The
			initiator proposes, through SAi payload, to use a hybrid post-
			quantum group and as a backup a Diffie-Hellman group, and through
			KEi payload, the initiator proposes a list of hybrid post-quantum
			proposals and policies. The MitM attacker intercepts this traffic
			and replies with N(INVALID_KE_PAYLOAD) suggesting to downgrade to
			the backup Diffie-Hellman group instead. The initiator then
			resends the same SAi payload and the KEi payload containing the
			public value of the backup Diffie-Hellman group. Note that the
			attacker may forward the second IKE_SA_INIT message only to the
			responder, and therefore at this point in time, the responder will
			not have the information that the initiator prefers the hybrid
			group. Of course, it is possible for the responder to have a
			policy to reject an IKE_SA_INIT message that (a) offers a hybrid
			group but not offering the corresponding public value in the KEi
			payload; and (b) the responder has not specifically acknowledged
			that it does not supported the requested hybrid group. However,
			the checking of this policy introduces unnecessary protocol
			complexity. Therefore, in order to fully prevent any downgrade
			attacks, using KE payload alone is not sufficient and that the
			initiator MUST always indicate its preferred post-quantum
			proposals and policies in a notify payload in the subsequent
			IKE_SA_INIT messages following a N(INVALID_KE_PAYLOAD) response.
			o New payload types to negotiate hybrid proposal and to carry post-
			quantum public values
			Semantically, it makes sense to use a new payload type, which
			mimics the SA payload, to carry a hybrid proposal. Likewise,
			another new payload type that mimics the KE payload, could be used
			to transport hybrid public value. Although, in theory a new
			payload type could be made backwards compatible by not setting its
			critical flag as per Section 2.5 of RFC7296, we believe that it
			may not be that simple in practice. Since the original release of
			IKEv2 in RFC4306, no new payload type has ever been proposed and
			therefore, this creates a potential risk of having a backward
			compatibility issue from non-conforming RFC IKEv2 implementations.
			Since we could not see any other compelling advantages apart from
			a semantic one, we use the existing KE and notify payloads
			instead. In fact, as described above, we use the KE payload in
			the first IKE_SA_INIT request round and the notify payload to
			carry the post-quantum proposals and policies. We use one or more
			of the existing KE payloads to carry the hybrid public values.
			o Hybrid public value payload
			One way to transport the negotiated hybrid public payload, which
			contains one classical Diffie-Hellman public value and one or more
			post-quantum public values, is to bundle these into a single KE
			payload. Alternatively, these could also be transported in a
			single new hybrid public value payload, but following the same
			reasoning as above, this may not be a good idea from a backward
			compatibility perspective. Using a single KE payload would
			require an encoding or formatting to be defined so that both peers
			are able to compose and extract the individual public values.
			However, we believe that it is cleaner to send the hybrid public
			values in multiple KE payloads--one for each group or algorithm.
			Furthermore, at this point in the protocol exchange, both peers
			should have indicated support of handling multiple KE payloads.
			o Fragmentation
			Handling of large IKE_SA_INIT messages has been one of the most
			challenging tasks. A number of approaches have been considered
			and the two prominent ones that we have discarded are outlined as
			follows.
			The first approach was to treat the entire IKE_SA_INIT message as
			a stream of bytes, which we then split it into a number of
			fragments, each of which is wrapped onto a payload that would fit
			into the size of the network MTU. The payload that wraps each
			fragment is a new payload type and it was envisaged that this new
			payload type will not cause a backward compatibility issue because
			at this stage of the protocol, both peers should have indicated
			support of fragmentation in the first pass of the IKE_SA_INIT
			exchange. The negotiation of fragmentation is performed using a
			notify payload, which also defines supporting parameters such as
			the size of fragment in octets and the fragment identifier. The
			new payload that wraps each fragment of the messages in this
			exchange is assigned the same fragment identifier. Furthermore, it
			also has other parameters such as a fragment index and total
			number of fragments. We decided to discard this approach due to
			its blanket approach to fragmentation. In cases where only a few
			payloads need to be fragmented, we felt that this approach is
			overly complicated.
			Another idea that was discarded was fragmenting an individual
			payload without introducing a new payload type. The idea was to
			use the 9-th bit (the bit after the critical flag in the RESERVED
			field) in the generic payload header as a flag to mark that this
			payload is fragmented. As an example, if a KE payload is to be
			fragmented, it may look as follows.
			1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Next Payload |C|F| RESERVED | Payload Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Diffie-Hellman Group Number | Fragment Identifier |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Fragment Index | Total Fragments |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Total KE Payload Data Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			~ Fragmented KE Payload ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			When the flag F is set, this means the current KE payload is a
			fragment of a larger KE payload. The Payload Length field denotes
			the size of this payload fragment in octets--including the size of
			the generic payload header. The two-octet RESERVED field
			following Diffie-Hellman Group Number was to be used as a fragment
			identifier to help assembly and disassembly of fragments. The
			Fragment Index and Total Fragments fields are self-explanatory.
			The Total KE Payload Data Length indicates the size of the
			assembled KE payload data in octets. Finally, the actual fragment
			is carried in Fragment KE Payload field.
			We discarded this approach because we believe that the working
			group may not be happy using the RESERVED field to change the
			format of a packet and that implementers may not like the
			complexity added from checking the fragmentation flag in each
			received payload. Furthermore, we dismissed this idea in favour
			of the idea present in Section 3.6 due to the handling of the
			total IKEv2 payload size. There was not a clean method for the
			receiver to determine the total size of all the IKEv2 fragmented
			payloads. The method defined in Section 3.6 allows for a clean
			method for implementations to 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 be made on a particular post-quantum algorithm by assigning
			additional value alongside the group identifier. This sub-
			identifier value may be used to assign different security
			parameter sets to a given post-quantum algorithm. However, this
			level of details does not fit the principles of the document where
			it should deal with generic hybrid key exchange protocol, not a
			specific ciphersuite. Furthermore, there are enough Diffie-
			Hellman group identifiers should this be required in the future.
			o State Keeping in Downgrade Attack Protection
			Another way of checking whether or not a downgrade attack is in
			effect is to have a responder to commit the state of the first-
			pass of the IKE_SA_INIT message onto memory or a temporary
			database. When the responder receives the second-pass of the
			exchange, it can verify it against the saved state to determine
			whether or not a downgrade attack is in effect. While this simple
			verification does offer protection against downgrade attack, it is
			susceptible to state exhaustion attack. While we do not discard
			this idea, it is RECOMMENDED to use the other two downgrade
			protection mechanisms described in Section 3.7.
			5. Security considerations
	The key length of the Encryption Algorithm (Transform Type 1), the		The key length of the Encryption Algorithm (Transform Type 1), the
	Pseudorandom Function (Transform Type 2) and the Integrity Algorithm		Pseudorandom Function (Transform Type 2) and the Integrity Algorithm
	(Transform Type 3), all have to be of sufficient length to prevent		(Transform Type 3), all have to be of sufficient length to prevent
	attacks using Grover's algorithm [GROVER]. In order to use the		attacks using Grover's algorithm [GROVER]. In order to use the
	extension proposed in this document, the key lengths of these		extension proposed in this document, the key lengths of these
	transforms SHALL be at least 256 bits long in order to prevent any		transforms SHALL be at least 256 bits long in order to provide
	quantum attacks from succeeding. Accordingly the post-quantum		sufficient resistance to quantum attacks. Accordingly the post-
	security level achieved is at least 128 bits.		quantum security level achieved is at least 128 bits.
	The quantities SKEYSEED and KEYMAT are calculated from shared
	secrets, g^ir and QSSS, using an algorithm defined in Transform Type
	2. While a quantum attacker may learn the value of g^ir, the
	quantity QSSS ensures that neither SKEYSEED nor KEYMAT is
	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 of several		SKEYSEED is calculated from shared, KEx, using an algorithm defined
	KB, a IKEv2 message that contains such a QSKE payload will exceed the		in Transform Type 2. While a quantum attacker may learn the value of
	path Maximum Transmission Unit (MTU) and the message may be		KEx', if this value is obtained by means of a classical key exchange,
	fragmented at the IP level. This presents the possibility of an		other KEx values generated by means of a quantum-resistant algorithm
	attack vector that relies on IP fragmentation. One such attack		ensure that SKEYSEED is not compromised. This assumes that the
	vector is to mount a denial of service by swamping a receiver with IP		algorithm defined in the Transform Type 2 is post-quantum.
	fragments [DOSUDPPROT]. This issue could be mitigated by employing
	TCP encapsulation [IKETCPENCAP].
	The authenticity of the SAs established under IKEv2 is protected		The main focus of this document is to prevent a passive attacker
	using a pre-shared key, RSA, DSS, or ECDSA algorithms. Whilst the		performing a "harvest and decrypt" attack. In other words, an
	pre-shared key option, provided the key is long enough, is quantum-		attacker that records messages exchanges today and proceeds to
	safe, the other algorithms are not. Moreover, in implementations		decrypt them once he owns a quantum computer. This attack is
	where scalability is a requirement, the pre-shared key method may not		prevented due to the hybrid nature of the key exchange. Other
	be suitable. Quantum-safe authenticity may be provided by using a		attacks involving an active attacker using a quantum-computer are not
	quantum-safe digital signature and several quantum-safe digital		completely solved by this document since the authentication step
	signature methods are being explored by IETF. For example the hash		remains classical. In particular, the authenticity of the SAs
	based method, XMSS has the status of an Internet Draft, see [XMSS].		established under IKEv2 is protected using a pre-shared key, RSA,
	Currently, quantum-safe authentication methods are not specified in		DSA, or ECDSA algorithms. Whilst the pre-shared key option, provided
	this document, but are planned to be incorporated in due course.		the key is long enough, is post-quantum, the other algorithms are
			not. Moreover, in implementations where scalability is a
			requirement, the pre-shared key method may not be suitable. Quantum-
			safe 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 algorithms is to		It should be noted that the purpose of post-quantum algorithms is to
	prevent attacks, mounted in the future, from succeeding. The current		provide resistance to attacks mounted in the future. The current
	threat is that encrypted sessions may be subject to eavesdropping and		threat is that encrypted sessions are subject to eavesdropping and
	archived with decryption by quantum computers taking place at some		archived with decryption by quantum computers taking place at some
	point in the future. Until quantum computers become available there		point in the future. Until quantum computers become available there
	is no point in attacking the authenticity of a connection because		is no point in attacking the authenticity of a connection because
	there are no possibilities for exploitation. These only occur at the		there are no possibilities for exploitation. These only occur at the
	time of the connection, for example by mounting a MitM attack.		time of the connection, for example by mounting a MitM attack.
	Consequently there is not such a pressing need for quantum-safe		Consequently there is not such a pressing need for quantum-safe
	authenticity.		authenticity.
	The use of the QSKE provides an method for malicious parties to send		The key exchange mechanism in this document provides a method for
	IKE_SA_INIT initiator messages containing QSKE of type KEM and with		malicious parties to send multiple KE payloads, where each of which
	random values. As the standard behavior is for the responder to		could be large, to a responder. As the standard behavior is for the
	generate a random entity, encrypt it using the received public key		responder to consume computational resources to compute and send
	(which would be a random value), and sends the encrypted quantity to		multiple KE payloads back to the initiator, this allows for a simple
	the initiator in QSKEr payload. This allows for a simply method for		method for malicious parties to cause a VPN gateway to perform
	malicious parties to cause a VPN gateway to perform excessive		excessive processing. In order to mitigate against this threat,
	processing. To mitigate against this threat, implementations can		implementations MAY make use of the DoS prevention COOKIE
	make use of the COOKIE notification as defined in [RFC7296], to		notification as defined in [RFC7296], to mitigate spoofed traffic and
	mitigate spoofed traffic and [RFC8019] to minimize the impact from		a puzzle-solving notification [RFC8019] to minimize the impact from
	hosts who use their own IP address.		hosts who use their own IP address.
	5. IANA Considerations		Cookie notification is used to prevent downgrade attacks. The cookie
			SHALL NOT be of arbitrary length, otherwise it will be susceptible to
	This document defines a new IANA registry for IKEv2 Transform Types.		SLOTH attack as described in [BL]. It is RECOMMENDED that the length
			of the cookie be no longer than 64 octets.
	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 to establish a quantum-safe
	SA, this extension registers a new key exchange payload in the IKEv2
	Payload Types of the IANA registry:
	Description Notation Value
	---------------------------------
	QSKE Payload QSKE tba
	This extension also specifies a new error type in the IKEv2 Notify
	Message Types - Error Types of the IANA registry:
	Error Type Value
	------------------------------
	INVALID_QSKE_PAYLOAD tba
	6. References		6. References
	[ADPS] Alkim, E., Ducas, L., Poppelmann, T., and Schwabe, P.,		[ADPS] Alkim, E., Ducas, L., Poppelmann, T., and Schwabe, P.,
	"Post-quantum Key Exchange - a New Hope", 25th USENIX		"Post-quantum Key Exchange - a New Hope", 25th USENIX
	Security Symposium, pp. 327-343, 2016.		Security Symposium, pp. 327-343, 2016.
	[AH] Kent, S., "IP Authentication Header", RFC 4302, December		[AH] Kent, S., "IP Authentication Header", RFC 4302, December
	2005, <http://www.rfc-editor.org/info/rfc4302>.		2005, <http://www.rfc-editor.org/info/rfc4302>.
	[BCNS15] Bos, J., Costello, C., Naehrig, M., and Stebila, D.,		[BL] Bhargavan, K. and Leurent, G., "Transcript Collision
	"Post-quantum Key Exchange for the TLS Protocol from the		Attacks: Breaking Authentication in TLS, IKE, and SSH",
	Ring Learning with Errors Problem", IEEE Symposium on		Network and Distributed System Security Symposium, 2016.
	Security and Privacy, pp. 553-570, 2015.
	[DH] Diffie, W., and Hellman, M., "New Directions in
	Cryptography", IEEE Transactions on Information Theory,
	V.IT-22 n. 6, June 1977.
	[DOSUDPPROT]
	Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS
	protection for UDP-based protocols", ACM Conference on
	Computer and Communications Security, October 2003.
	[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC		[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
	4303, December 2005, <http://www.rfc-		4303, December 2005, <http://www.rfc-
	editor.org/info/rfc4303>.		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		[GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for
	Database Search", Proc. of the Twenty-Eighth Annual ACM		Database Search", Proc. of the Twenty-Eighth Annual ACM
	Symposium on the Theory of Computing (STOC 1996), 1996		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]		[IKEV2IANA]
	IANA, "Internet Key Exchange Version 2 (IKEv2)		IANA, "Internet Key Exchange Version 2 (IKEv2)
	Parameters", <http://www.iana.org/assignments/ikev2-		Parameters", <http://www.iana.org/assignments/ikev2-
	parameters/>.		parameters/>.
	[LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,		[LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,
	Green, M., Halderman, J., Heninger, N., Springall, D.,		Green, M., Halderman, J., Heninger, N., Springall, D.,
	Thome, E., Valenta, L., VanderSloot, B., Wustrow, E.,		Thome, E., Valenta, L., VanderSloot, B., Wustrow, E.,
	Beguelin, S., and Zimmermann, P., "Imperfect forward		Beguelin, S., and Zimmermann, P., "Imperfect forward
	secrecy: How Diffie-Hellman fails in practice", Proc. 22rd		secrecy: How Diffie-Hellman fails in practice", Proc. 22rd
	ACM SIGSAC Conference on Computer and Communications		ACM SIGSAC Conference on Computer and Communications
	Security, pp. 5-17, 2015.		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		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and
	Kivinen, T., "Internet Key Exchange Protocol Version 2		Kivinen, T., "Internet Key Exchange Protocol Version 2
	(IKEv2)", RFC 7296, October 2014.		(IKEv2)", RFC 7296, October 2014.
	[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2		[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
	(IKEv2) Message Fragmentation", RFC 7383, November 2014.		(IKEv2) Message Fragmentation", RFC 7383, November 2014.
	[RFC8019] Nir, Y., Smyslov, V., "Protecting Internet Key Exchange		[RFC8019] Nir, Y., Smyslov, V., "Protecting Internet Key Exchange
	Protocol Version 2 (IKEv2) Implementations from		Protocol Version 2 (IKEv2) Implementations from
	Distributed Denial-of-Service Attacks", RFC 8019, November		Distributed Denial-of-Service Attacks", RFC 8019, November
	2016.		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] Huelsing, A., Butin, D., Gazdag, S., and Mohaisen, A.,
	"XMSS: Extended Hash-Based Signatures", Crypto Forum		"XMSS: Extended Hash-Based Signatures", Crypto Forum
	Research Group Internet Draft, 2017		Research Group Internet Draft, 2017
	Appendix A. Quantum-safe Ciphers		Acknowledgements
	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. 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 to use a random coefficient
	array {a} for each key exchange 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 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 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 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 to minimize the public key size and		The authors would like to thanks Frederic Detienne and Olivier
	key encapsulation data by using streamlined data packing and the		Pelerin for their comments and suggestions, including the idea to
	resulting QSKE public value is 1200 octets long. The ciphertext		negotiate the post-quantum algorithms using the existing KE payload.
	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.
	Authors' Addresses		Authors' Addresses
	C. Tjhai		C. Tjhai
	Post-Quantum		Post-Quantum
	EMail: cjt@post-quantum.com		email: cjt [at] post-quantum.com
	M. Tomlinson		M. Tomlinson
	Post-Quantum		Post-Quantum
	EMail: mt@post-quantum.com		email: mt [at] post-quantum.com
	A. Cheng
	Post-Quantum
	EMail: ac@post-quantum.com
	G. Bartlett		G. Bartlett
	Cisco Systems		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
End of changes. 120 change blocks.
	803 lines changed or deleted		1337 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/