< draft-tjhai-ipsecme-hybrid-qske-ikev2-01.txt		draft-tjhai-ipsecme-hybrid-qske-ikev2-02.txt >
	Internet Engineering Task Force C. Tjhai		Internet Engineering Task Force C. Tjhai
	Internet-Draft M. Tomlinson		Internet-Draft M. Tomlinson
	Intended Status: Informational Post-Quantum		Intended status: Informational Post-Quantum
	Expires: July 19, 2018 G. Bartlett		Expires: January 2, 2019 G. Bartlett
	S. Fluhrer		S. Fluhrer
	Cisco Systems		Cisco Systems
	D. Van Geest		D. Van Geest
	ISARA Corporation		ISARA Corporation
	Z. Zhang		Z. Zhang
	Onboard Security		Onboard Security
	O. Garcia-Morchon		O. Garcia-Morchon
	Philips		Philips
	January 15, 2018		July 1, 2018
	Framework to Integrate Post-quantum Key Exchanges		Framework to Integrate Post-quantum Key Exchanges into Internet Key
	into Internet Key Exchange Protocol Version 2 (IKEv2)		Exchange Protocol Version 2 (IKEv2)
	draft-tjhai-ipsecme-hybrid-qske-ikev2-01		draft-tjhai-ipsecme-hybrid-qske-ikev2-02
	Abstract		Abstract
	This document describes how to extend Internet Key Exchange Protocol		This document describes how to extend Internet Key Exchange Protocol
	Version 2 (IKEv2) so that the shared secret exchanged between peers		Version 2 (IKEv2) so that the shared secret exchanged between peers
	has resistance against quantum computer attacks. The basic idea is		has resistance against quantum computer attacks. The basic idea is
	to exchange one or more post quantum key exchange payloads in		to exchange one or more post-quantum key exchange payloads in
	conjunction with the existing (Elliptic Curve) Diffie-Hellman		conjunction with the existing (Elliptic Curve) Diffie-Hellman
	payload. This document also addresses the challenge of fragmentation		payload.
	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 https://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 July 19, 2018.		This Internet-Draft will expire on January 2, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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		(https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3		1.1. Problem Description . . . . . . . . . . . . . . . . . . . 2
	1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . . 3		1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . 3
	1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.4. Document organization . . . . . . . . . . . . . . . . . . 4		1.4. Document organization . . . . . . . . . . . . . . . . . . 4
	2. Design criteria . . . . . . . . . . . . . . . . . . . . . . . 5		2. Design criteria . . . . . . . . . . . . . . . . . . . . . . . 5
	3. The Framework of Hybrid Post-quantum Key Exchange . . . . . . 6		3. The Framework of Hybrid Post-quantum Key Exchange . . . . . . 6
	3.1. Overall design . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Overall design . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . . 7		3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . 7
	3.2.1. First Protocol Round . . . . . . . . . . . . . . . . . 7		3.2.1. First Protocol Round . . . . . . . . . . . . . . . . 8
	3.2.2. Second Protocol Round . . . . . . . . . . . . . . . . 10		3.2.2. IKE_AUX round . . . . . . . . . . . . . . . . . . . . 10
	3.2.3. Child SA Negotiation . . . . . . . . . . . . . . . . . 11		3.2.3. IKE_AUX exchange . . . . . . . . . . . . . . . . . . 11
	3.3. Computation of a Post-Quantum Shared Secret . . . . . . . 12		3.3. Post-quantum Group Transform Type and Group Identifiers . 11
	3.4. Post-Quantum Group Transform Type and Group Identifiers . 12		3.4. Hybrid Group Negotiation . . . . . . . . . . . . . . . . 12
	3.5. Hybrid Group Negotiation . . . . . . . . . . . . . . . . . 13		3.5. Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.5.1. Protocol for the Initiator . . . . . . . . . . . . . . 14		4. Alternative Design . . . . . . . . . . . . . . . . . . . . . 12
	3.5.2. Protocol from the Responder . . . . . . . . . . . . . . 17		5. Security considerations . . . . . . . . . . . . . . . . . . . 16
	3.6. Fragmentation Support . . . . . . . . . . . . . . . . . . 19		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	3.6.1. Fragmentation Problem Description . . . . . . . . . . 19		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
	3.6.2. Fragmentation Solution . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	3.6.2.1. Fragmentation Pointer Payload . . . . . . . . . . 19
	3.6.2.2. Fragmentation Body Payload . . . . . . . . . . . . 20
	3.6.2.3. Fragmentation Semantics . . . . . . . . . . . . . 23
	3.6.2.4. IKE AUTH Processing . . . . . . . . . . . . . . . 24
	3.6.2.5. Design Rationale . . . . . . . . . . . . . . . . . 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 (DH) or Elliptic Curve Diffie-		[RFC7296] uses the Diffie-Hellman (DH) or Elliptic Curve Diffie-
	Hellman (ECDH) algorithm to establish a shared secret between an		Hellman (ECDH) algorithm to establish a shared secret between an
	initiator and a responder. The security of the DH and ECDH		initiator and a responder. The security of the DH and ECDH
	algorithms relies on the difficulty to solve a discrete logarithm		algorithms relies on the difficulty to solve a discrete logarithm
	problem in multiplicative and elliptic curve groups respectively when		problem in multiplicative and elliptic curve groups respectively when
	the order of the group parameter is large enough. While solving such		the order of the group parameter is large enough. While solving such
	a problem remains difficult with current computing power, it is		a problem remains difficult with current computing power, it is
	believed that general purpose quantum computers will be able to solve		believed that general purpose quantum computers will be able to solve
	this problem, implying that the security of IKEv2 is compromised.		this problem, implying that the security of IKEv2 is compromised.
	There are, however, a number of cryptosystems that are conjectured to		There are, however, a number of cryptosystems that are conjectured to
	be resistant against quantum computer attack. This family of		be resistant against quantum computer attack. This family of
	cryptosystems are known as post-quantum cryptography (PQC). It is		cryptosystems are known as post-quantum cryptography (PQC). It is
	sometime also referred to as quantum-safe cryptography (QSC) or		ometime also referred to as quantum-safe cryptography (QSC) or
	quantum-resistant cryptography (QRC).		quantum-resistant cryptography (QRC).
	1.2. Proposed Extension		1.2. Proposed Extension
	This document describes a framework to integrate QSC for IKEv2,		This document describes a framework to integrate QSC for IKEv2, while
	whilst maintaining backwards compatibility, to exchange a shared		maintaining backwards compatibility, to derive a set of IKE keys that
	secret such that it has resistance to quantum computer attacks. Our		have resistance to quantum computer attacks. Our framework allows
	framework allows the negotiation of one or more QSC algorithm to		the negotiation of one or more QSC algorithm to exchange data, in
	exchange data, in addition to the existing DH or ECDH key exchange		addition to the existing DH or ECDH key exchange data. We believe
	data. We believe that the feature of using more than one post		that the feature of using more than one post-quantum algorithm is
	quantum algorithm is important as many of these algorithms are		important as many of these algorithms are relatively new and there
	relatively new and there may be a need to hedge the security risk		may be a need to hedge the security risk with multiple key exchange
	with multiple key exchange data from several distinct QSC algorithms.		data from several distinct QSC algorithms.
	The secrets established from each key exchange are combined in a way		The secrets established from each key exchange are combined in a way
	such that should the post quantum secrets not be present, the derived		such that should the post-quantum secrets not be present, the derived
	shared secret is equivalent to that of the standard IKEv2; on the		shared secret is equivalent to that of the standard IKEv2; on the
	other hand, a post quantum shared secret is obtained if both		other hand, a post-quantum shared secret is obtained if both
	classical and post quantum key exchange data are present. This		classical and post-quantum key exchange data are present. This
	framework also applies to key exchanges in IKE Security Associations		framework also applies to key exchanges in IKE Security Associations
	(SAs) for Encapsulating Security Payload (ESP) [ESP] or		(SAs) for Encapsulating Security Payload (ESP) [ESP] or
	Authentication Header (AH) [AH], i.e. Child SAs, in order to provide		Authentication Header (AH) [AH], i.e. Child SAs, in order to provide
	a stronger guarantee of forward security.		a stronger guarantee of forward security.
	One of the key challenges in this framework is fragmentation handling		Some post-quantum key exchange payloads may have size larger than the
	during the first message pair of the initial exchange phase, i.e.		standard MTU size, and therefore there could be issues with
	IKE_SA_INIT. Almost all of the known PQC algorithms to date have key		fragmentation at IP layer. IKE does allow transmission over TCP
	exchange data size that exceeds 1K octets. When transmitted		where fragmentation is not an issue [RFC8229]; however, we believe
	alongside other payloads, the total payload size could easily exceed		that a UDP-based solution will be required too. IKE does have a
	the common maximum transmission unit (MTU) size of 1500 octets, and		mechanism to handle fragmentation within UDP [RFC7383], however that
	hence this may lead to IP level fragmentation. While IKEv2 has a		is only applicable to messages exchanged after the IKE_SA_INIT. To
	mechanism to handle fragmentation [RFC7383], it is applicable to		use this mechanism, we use the IKE_AUX exchange as outlined in
	messages exchanged after IKE_SA_INIT. Of course, fragmentation will		[I-D.smyslov-ipsecme-ikev2-aux]. With this mechanism, we do an
	not be an issue if messages are sent over TCP [RFC8229]; however, we		initial key exchange, using a smaller, possibly non-quantum resistant
	believe that a UDP-based solution will also be required. This		primitive, such as ECDH. Then, before we do the IKE_AUTH exchange,
	document describes a simple mechanism to fragment IKE_SA_INIT		we perform one or more IKE_AUX exchanges, each of which includes a
	messages, which also allows exchanges for payload larger than 65,535		secondary key exchange. As the IKE_AUX exchange is encrypted, the
	octets.		IKE fragmentation protocol RFC7383 can be used. The IKE SK values
			will be updated after each exchange, and so the final IKE SK values
			will depend on all the key exchanges, hence they are secure if any of
			the key exchanges are secure.
	Note that readers should consider the approach in this document as		Note that readers should consider the approach in this document as
	providing a long term solution in upgrading the IKEv2 protocol to		providing a long term solution in upgrading the IKEv2 protocol to
	support post quantum algorithms. A short term solution to make IKEv2		support post-quantum algorithms. A short term solution to make IKEv2
	key exchange quantum secure is to use post quantum pre-shared keys as		key exchange quantum secure is to use post-quantum pre-shared keys as
	discussed in [FMKS].		discussed in [I-D.ietf-ipsecme-qr-ikev2].
	1.3. Changes		1.3. Changes
	Changes in this draft in each version iterations.		Changes in this draft in each version iterations.
			draft-tjhai-ipsecme-hybrid-qske-ikev2-01
			o Use IKE_AUX to perform multiple key exchanges in succession.
			o Handle fragmentation by keeping the first key exchange (a standard
			IKE_SA_INIT with a few extra notifies) small, and encrypting the
			rest of the key exchanges.
			o Simplify the negotiation of the 'extra' key exchanges.
	draft-tjhai-ipsecme-hybrid-qske-ikev2-00		draft-tjhai-ipsecme-hybrid-qske-ikev2-00
	o We added a feature to allow more than one post quantum key		o We added a feature to allow more than one post-quantum key
	exchange algorithms to be negotiated and used to exchange a post-		exchange algorithms to be negotiated and used to exchange a post-
	quantum shared secret.		quantum shared secret.
	o Instead of relying on TCP encapsulation to deal with IP level		o Instead of relying on TCP encapsulation to deal with IP level
	fragmentation, we introduced a new key exchange payload that can		fragmentation, we introduced a new key exchange payload that can
	be sent as multiple fragments within IKE_SA_INIT message.		be sent as multiple fragments within IKE_SA_INIT message.
	1.4. Document organization		1.4. Document organization
	The remainder of this document is organized as follows. Section 2		The remainder of this document is organized as follows. Section 2
	summarizes design criteria. Section 3 describes how post-quantum key		summarizes design criteria. Section 3 describes how post-quantum key
	exchange is performed between two IKE peers, how keying materials are		exchange is performed between two IKE peers and how keying materials
	derived and how downgrade attack is prevented. This section also		are derived. The rationale behind the approach of this extension is
	specifies we handle fragmentation in IKE_SA_INIT exchanges. A		described in Section 3. Section 4 discusses security considerations
	number of alternative designs to Section 3, which we have considered		an lastly, Section 5 discusses IANA considerations for the name
	but not adopted, are discussed in Section 4. Lastly, Section 5		spaces introduced in this document.
	discusses security considerations.
	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].
	2. Design criteria		2. Design criteria
	The design of the proposed post-quantum IKEv2 is driven by the		The design of the proposed post-quantum IKEv2 is driven by the
	following criteria:		following criteria:
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 28 ¶
	is 2040, D is 2020, and T is 30 years. Such a value of T is		is 2040, D is 2020, and T is 30 years. Such a value of T is
	typical in classified or healthcare data.		typical in classified or healthcare data.
	2) Hybrid. Currently, there does not exist a post-quantum key		2) Hybrid. Currently, there does not exist a post-quantum key
	exchange that is trusted at the level that ECDH is trusted		exchange that is trusted at the level that ECDH is trusted
	against conventional (non-quantum) adversaries. A hybrid		against conventional (non-quantum) adversaries. A hybrid
	approach allows introducing promising post-quantum candidates		approach allows introducing promising post-quantum candidates
	next to well-established primitives, since the overall security		next to well-established primitives, since the overall security
	is at least as strong as each individual primitive.		is at least as strong as each individual primitive.
	3) Focus on quantum-resistant confidentiality. A passive attacker		3) Focus on quantum-resistant confidentiality. A passive attacker
	can eavesdrop IPsec communication today and decrypt it once a		can eavesdrop on IPsec communication today and decrypt it once a
	quantum computer is available in the future. This is a very		quantum computer is available in the future. This is a very
	serious attack for which we do not have a solution. An attacker		serious attack for which we do not have a solution. An attacker
	can only perform active attacks such as impersonation of the		can only perform active attacks such as impersonation of the
	communicating peers once a quantum computer is available,		communicating peers once a quantum computer is available,
	sometime in the future. Thus, our design focuses on quantum-		sometime in the future. Thus, our design focuses on quantum-
	resistant confidentiality due to the urgency of this problem.		resistant confidentiality due to the urgency of this problem.
	This document does not address quantum-resistant authentication		This document does not address quantum-resistant authentication
	since it is less urgent at this stage.		since it is less urgent at this stage.
	4) Limit amount of exchanged data. The protocol design should be		4) Limit amount of exchanged data. The protocol design should be
	such that the amount of exchanged data, such as public-keys, is		such that the amount of exchanged data, such as public-keys, is
	kept as small as possible even if initiator and responder need		kept as small as possible even if initiator and responder need
	to agree on a hybrid group or multiple public-keys need to be		to agree on a hybrid group or multiple public-keys need to be
	exchanged.		exchanged.
	5) Future proof. Any cryptographic algorithm could be potentially		5) Future proof. Any cryptographic algorithm could be potentially
	broken in the future by currently unknown or impractical		broken in the future by currently unknown or impractical
	attacks: quantum computers are merely the most concrete example		attacks: quantum computers are merely the most concrete example
	of this. The design does not categorize algorithms as "post-		of this. The design does not categorize algorithms as "post-
	quantum" or "non post-quantum" and does not create assumptions		quantum" or "non post-quantum" and does not create assumptions
	about the properties of the algorithms, meaning that if		about the properties of the algorithms, meaning that if
	algorithms with different properties become necessary in future,		algorithms with different properties become necessary in the
	this framework can be used unchanged to facilitate migration to		future, this framework can be used unchanged to facilitate
	those algorithms.		migration to those algorithms.
	6) Identification of hybrid algorithms. The usage of a hybrid
	approach in which each hybrid combination of several classical
	and post-quantum algorithms leads to a different group
	identifier can lead to an exponential number of combinations.
	Thus, the design should seek an approach in which a hybrid group
	-- comprising multiple post-quantum algorithms -- can be
	efficiently negotiated.
	7) Limited amount of changes. A key goal is to limit the number of		6) Limited amount of changes. A key goal is to limit the number of
	changes required when enabling a post-quantum handshake. This		changes required when enabling a post-quantum handshake. This
	ensures easier and quicker adoption in existing implementations.		ensures easier and quicker adoption in existing implementations.
	8) Localized changes. Another key requirement is that changes to		7) Localized changes. Another key requirement is that changes to
	the protocol are limited in scope, in particular, limiting		the protocol are limited in scope, in particular, limiting
	changes in the exchanged messages and in the state machine, so		changes in the exchanged messages and in the state machine, so
	that they can be easily implemented.		that they can be easily implemented.
	9) Deterministic operation. This requirement means that the hybrid		8) Deterministic operation. This requirement means that the hybrid
	post-quantum exchange, and thus, the computed key, will be based		post-quantum exchange, and thus, the computed key, will be based
	on algorithms that both client and server wish to support.		on algorithms that both client and server wish to support.
	10) Fragmentation support. Some PQC algorithms could be relatively		9) Fragmentation support. Some PQC algorithms could be relatively
	bulky and they might require fragmentation. Thus, a design goal		bulky and they might require fragmentation. Thus, a design goal
	is the adaptation and adoption of an existing fragmentation		is the adaptation and adoption of an existing fragmentation
	method or the design of a new method that allows for the		method or the design of a new method that allows for the
	fragmentation of the key shares.		fragmentation of the key shares.
	11) Backwards compatibility and interoperability. This is a		10) Backwards compatibility and interoperability. This is a
	fundamental requirement to ensure that hybrid post-quantum IKEv2		fundamental requirement to ensure that hybrid post-quantum IKEv2
	and a non-post-quantum IKEv2 implementations are interoperable.		and a non-post-quantum IKEv2 implementations are interoperable.
	12) FIPS compliance. IPsec is widely used in Federal Information		11) FIPS compliance. IPsec is widely used in Federal Information
	Systems and FIPS certification is an important requirement.		Systems and FIPS certification is an important requirement.
	However, algorithms that are believed to be post-quantum are not		However, algorithms that are believed to be post-quantum are not
	FIPS compliant yet. Still, the goal is that the overall hybrid		FIPS compliant yet. Still, the goal is that the overall hybrid
	post-quantum IKEv2 design can be FIPS compliant.		post-quantum IKEv2 design can be FIPS compliant.
	3. The Framework of Hybrid Post-quantum Key Exchange		3. The Framework of Hybrid Post-quantum Key Exchange
	3.1. Overall design		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		This design assigns new group identifiers (Transform Type 4) to the
	--------------------------------------------------------------		various post-quantum key exchanges (which will be defined later). We
	<-- First round (hybrid group negotiation) -->		specifically do not make a distinction between classical (DH and
			ECDH) and post-quantum key exchanges, nor post-quantum algorithms
			which are true key exchanges versus post-quantum algorithms that act
			as key transport mechanisms; all are treated equivalently by the
			protocol. In order to support both hybrid key exchanges (that is,
			relying on distinct key exchanges) and fragmentation, the proposed
			hybrid post-quantum IKEv2 protocol extends IKE [RFC7296] by adding
			additional key exchange messages (IKE_AUX) between the IKE_SA_INIT
			and the IKE_AUTH exchanges. In order to minimize communication
			overhead, only the key shares that are agreed to be used are actually
			exchanged. In order to achieve this, the IKE_SA_INIT exchange now
			includes notify payloads that negotiate the extra key exchanges to be
			used. The initiator IKE_SA_INIT message includes a notify that lists
			the extra key exchange policy required by the initiator; the
			responder selects one of the listed policies, and includes that as a
			notify in the response IKE_SA_INIT message. Then, the initiator and
			the responder perform one (or possibly more) IKE_AUX exchange; each
			such exchange includes a KE payload for the key exchange that was
			negotiated.
	<-- Second round (hybrid quantum-safe key exchange) -->		Here is an overview of the initial exchanges:
	This hybrid post-quantum IKEv2 key exchange can occur in IKE_SA_INIT		Initiator Responder
	or CREATE_CHILD_SA message pair which contains various payloads for		--------------------------------------------------------
	negotiating cryptographic algorithms, exchanging nonces, and		<-- IKE_SA_INIT (and extra key exchange negotiation) -->
	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.
	3.2. Overall Protocol		<-- {IKE_AUX (hybrid post-quantum key exchange)} -->
			...
			<-- {IKE_AUX (hybrid post-quantum key exchange)} -->
	In the following we overview the two protocol rounds involved in the		<-- {IKE_AUTH} -->
	hybrid post-quantum protocol.
	3.2.1. First Protocol Round		The extra post-quantum key exchanges can use algorithms that are
			currently considered to be resistant to quantum computer attacks.
			These algorithms are collectively referred to as post-quantum
			algorithms in this document.
	In the first round, the IKE_SA_INIT request and response messages are		3.2. Overall Protocol
	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.
	The initiator negotiates cryptographic suites as per RFC7296, the		In the simplest case, the initiator is happy with a single key
	only exception is, the Diffie-Hellman KE payload is not populated		exchange (and has no interest in supporting multiple), and he is not
	with a keyshare, but rather the KE payload contains the proposed		concerned with possible fragmentation of the IKE_SA_INIT messages
	post-quantum algorithms and policies. The Diffie-Hellman groups are		(either because the key exchange he selects is small enough not to
	negotiated in the security association payload as per RFC7296 and the		fragment, or he is confident that fragmentation will be handled
	public values sent in the next round of exchange.		either by IP fragmentation, or transport via TCP). In the following
			we overview the two protocol rounds involved in the hybrid post-
			quantum protocol.
	When a responder that supports the hybrid exchange, receives an		In this case, the initiator performs the IKE_SA_INIT as standard,
	IKE_SA_INIT message with a KE payload with group number #TBA, it		inserting this prefered key exchange (which is possibly a post-
	performs a lookup of the policies and algorithms contained within the		quantum algorithm) as the listed Transform Type 4, and including the
	KE payload. Assuming that it supports one or more proposed post-		initiator KE payload. If the responder accepts the policy, he
	quantum algorithms, it then indicates these in the KE payload		responds with an IKE_SA_INIT response, and IKE continues as usual.
	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.
	The initiator can signal support of IKE_SA_INIT message fragmentation		If the initiator desires to negotiate multiple key exchanges, or he
	by including a payload fragmentation Notify payload. The responder		needs IKE to handle any possible fragmentation, then he uses the
	can also include this Notify payload to indicate support of		protocol listed below.
	IKE_SA_INIT message fragmentation.
	The responder may choose to allocate state to the session, as the		3.2.1. First Protocol Round
	initial message is used in authenticating the IKE SA messages.
	Optionally, the responder may prefer not to allocate any state and
	reply with a cookie instead. The cookie can provide two functions.
	One being the standard RFC7296 behaviour. The other benefit of using
	the cookie is to provide fast detection of a downgrade attack without
	running into the risk of state exhaustion attacks. Whether or not
	any states are allocated, the responder detects the post-quantum
	cryptographic algorithms and policies that do not match and can then
	abort the session prior to calculating the shared secrets. See
	Section 3.7 for more information on cookie and downgrade attack
	prevention.
	Initiator Responder		In the first round, the IKE_SA_INIT request and response messages
	--------------------------------------------------------------		negotiate the initial IKE SAs (as currently), as well as the key
	HDR, SAi1, KEi(#TBA),		exchanges that will be used within the IKE_AUX phase below.
	Ni, [N(Pay Frag)] -->
	<-- HDR, SAr1, KE(#TBA),		The initiator negotiates cryptographic suites as per RFC7296, with
	Nr, [N(Pay Frag),]		the listed Transform Type 4 (and KE payload) being either the first
	[N(COOKIE)]		key exchange on his desired list of key exchanges, or alternatively a
			small classical one (in order to enable fragmentation support of the
			later key exchanges). In addition, the initial IKE_SA_INIT message
			will include the following two Notify payloads:
	By using the KE payload, peers that do not support the hybrid		o The N(AUX_EXCHANGE_SUPPORTED) notify, as specified in
	exchange will reject the initial negotiation and assuming that a		[I-D.smyslov-ipsecme-ikev2-aux]. This draft makes no requirements
	Diffie-Hellman Group Num contained in the Diffie-Hellman Group		about the included data.
	Transform IDs was acceptable, the peer will send an
	INVALID_KE_PAYLOAD message to indicate its preferred Diffie-Hellman
	group. Note that using the KE payload enables backward compatibility
	with existing RFC7296 implementations. If this scenario occurs, the
	initiator SHOULD retry the hybrid exchange. Dependent on policies,
	the initiator may retry the exchange as per RFC7296, and if this
	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.
	On receipt of the N(PQ_ALGO_POLICIES) payload, the responder MUST		o An N(EXTRA_KEY_EXCHANGE_POLICY) notify, which has a Protocol ID
	validate these post-quantum algorithms and policies against its own		and SPI Size of 0, and includes the below data.
	policies. This validation is required to ensure that the post-
	quantum algorithms were not amended in the initial exchange,
	resulting in a downgrade attack.
	Should the proposed post-quantum algorithms not be acceptable to the		This data will be the list of groups that the initiator is willing to
	responder, the responder SHOULD indicate this by sending the		negotiate during the IKE_AUX phase below. The initiator signifies
	INVALID_KE_PAYLOAD Notify message to indicate its preferred Diffie-		this by specifying the specific list of the sets of key exchanges
	Hellman group or the NO_PROPOSAL_CHOSEN Notify message if no Diffie-		that he will allow. The list MUST be ordered from most prefered to
	Hellman group were acceptable. If the classical cryptographic suite		least prefered. This is encoded as a series of 2 byte values; a
	is acceptable, but the post-quantum algorithms are not, the responder		specified list of acceptable groups is given as the specific
	SHOULD indicate this by specifying the preferred Diffie-Hellman group		Transform IDs, followed by a 0x00 value. For example, if the NewHope
	in the INVALID_KE_PAYLOAD notification. The initiator should then		post-quantum key exchange is 0x40, Round2 is 0x42, and SIKE is 0x47,
	revert to the classical IKEv2 exchange and include the		then the data payload:
	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		0040 0000
	--------------------------------------------------------------		0042 0047 0000
	HDR, SAi1, KEi(#TBA),		0042 0000
	Ni, [N(Pay Frag)] -->
	<-- HDR, N(INVALID_KE_PAYLOAD, 19)		will signify that the initiator is willing to perform IKE_AUX with
	HDR, SAi1, KEi(19),		either NewHope, Round2 followed by SIKE, or only Round2.
	N(PQ_ALGO_POLICIES), -->
	Ni
	For implementations that mandate only the use of hybrid exchange,		If the initiator is willing to skip the IKE_AUX phase, he can signify
	these MUST not revert to using the classical IKEv2 exchange. This		that by including a 0000 value as a list; for example:
	should be a configurable parameter in implementations.
	As per RFC7296, should the responder not accept any of the		0040 0000
	cryptographic suites that were sent in the security association		0042 0047 0000
	payload, a NO_PROPOSAL_CHOSEN message is responded, as depicted		0042 0000
	below.		0000
	Initiator Responder		would signify either (NewHope), (Round2, SIKE), (Round2) or skipping
	--------------------------------------------------------------		the IKE_AUX entirely.
	HDR, SAi1, KEi(#TBA),
	Ni, [N(Pay Frag)] -->
	<-- HDR, N(NO_PROPOSAL_CHOSEN)		When the responder that supports the hybrid exchange receives an
			IKE_SA_INIT message with the AUX_EXHANGE_SUPPORTED and
			EXTRA_KEY_EXCHANGE_POLICY notifies, then (after processing the IKE
			message as normal), it scans through the policy listed within the
			EXTRA_KEY_EXCHANGE_POLICY Notify payload. If the responder finds a
			list of key exchanges that is consistent with its own policy, it
			includes N(AUX_EXCHANGE_SUPPORTED) and N(EXTRA_KEY_EXCHANGE_LIST)
			notifies, which both have 0 Protocol IDs and SPI sizes. The data for
			the EXTRA_KEY_EXCHANGE_LIST notify would have data specifying the
			list of acceptable Transform IDs as a series of 2 byte values. If
			the responder's policy requires it to perform the extra key exchange,
			but none of the key exchange lists are acceptable, it returns an
			error in a notification with type NO_PROPOSAL_CHOSEN.
	3.2.2. Second Protocol Round		For example, if the single transform Round2 is accepted, then the
			data payload will consist of:
	In the second protocol round, the initiator sends again the		0042
	IKE_SA_INIT request. The main difference is that this message
	includes the key-shares associated to each of the post-quantum
	algorithms agreed in the previous round. Each key-share is
	transported in a KE payload, and therefore there may exist multiple
	KE payloads in the 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.
	In a general hybrid arrangement, the RFC7296 Diffie-Hellman public		If the set Round2 and SIKE is accepted, then the data payload will
	value is sent in the first KE payload (denoted KEi1), with one or		consist of:
	more post-quantum key-share being sent in additional KE payloads
	(denoted KEi2, KEi3, etc). However, this ordering is not mandatory.
	If the responder sent a cookie in the first round of exchange, the		0042 0047
	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.
	The responder also sends the IKE_SA-INIT response message including		If no IKE_AUX transforms is desired, then the data payload will be
	its key-shares. As before, if agreed and if required, fragmentation		empty (or alternatively no such notification is included, which
	is handled as described in Section 3.6. Once the initiator has		implies the same thing).
	received all key-shares from the responder, the initiator can compute
	the same shared secret following the description in Section 3.3.
	Below is an example message exchanged in the second round of		On success, the responder will create the IKE SA and SK values based
	IKE_SA_INIT message.		on SAi1, SAr1 and KE payloads as normal.
	Initiator Responder		When the initiator receives the reply IKE_SA_INIT message, it checks
	--------------------------------------------------------------		for the existence of the AUX_EXCHANGE_SUPPORTED and
	HDR, [N(COOKIE),] SAi1,		EXTRA_KEY_EXCHANGE_LIST notifies. If those notifies are not present,
	KEi1[, KEi2, ..., KEiX,]		then the initiator treats it as if no extra key exchanges were chosen
	Ni[, N(PQ_ALGO_POLICIES)] -->		(and then can proceed by either rejecting the exchange, or proceed
			using the single negotiated key exchange, depending on local policy).
	<-- HDR, SAr1, KEr1[, KEr2,		If those notifies are present, then the responder verifies that the
	..., KErX,] Nr		key exchanges listed within the EXTRA_KEY_EXCHANGE_LIST are one of
			the options within its local policy; if so, it processes the
			IKE_SA_INIT message as normal, and then proceeds to the IKE_AUX
			round.
	For implementations that are to be used by peers that are pre-		3.2.1.1. Note on responder policy check
	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		One reason that the initiator may select the initial key exchange
			(the type 4 transform within the SAi1 payload) is not for security,
			but instead to simply establish keys to allow fragmentation of the
			IKE_AUX message. Because of this possibility, if the receiver sees a
			list of key exchanges listed within the EXTRA_KEY_EXCHANGE_LIST that
			satisfies its policies, it SHOULD accept it (assuming that the SAi1
			payload is otherwise acceptable), even if the key payload within the
			SAi1 is not necessary according to its policy.
	After the initial IKE SA is negotiated, either side may later		3.2.2. IKE_AUX round
	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		For each extra key exchange agreed to in the IKE_SA_INIT exchange,
	group is:		the initiator and the responder perform an IKE_SA_AUX exchange, as
			described in [I-D.smyslov-ipsecme-ikev2-aux].
	Initiator Responder		This exchange is as follows:
	--------------------------------------------------------------
	HDR, SK{SA, Ni, KEi1, KEi2,
	..., KEiN, TSi, TSr} -->
	<-- HDR, SK{SA, Nr, KEr1, KEr2,
	..., KErN, TSi, TSr}
	where both SA payloads include a transform type 4 of (TBA), and the		Initiator Responder
	KEi1, ..., KEiN, KEr1, ..., KErN are the KE types there were		-------------------------------------------------
	initially negotiated.		HDR, SK {Ni2, KEi2} -->
			<-- HDR, SK {Nr2, KEr2}
	3.3. Computation of a Post-Quantum Shared Secret		The initiator sends a nonce in the Ni2 payload, and the key exchange
			payload in the KEi2; the group id of the KEi2 payload MUST match the
			negotiated extra key exchange. This packet is encrypted with the
			current IKE SK keys.
	After the second protocol round detailed in Section 2.2., both		On receiving this, the responder sends a nonce in the Nr2 payload,
	initiator and responder can compute the common shared secrets to		and the key exchange payload KEr2; again, this packet is encrypted
	generate an SKEYSEED, from which all keying materials for protection		with the current IKE SA keys.
	of the IKE SA are derived. The quantity SKEYSEED is computed as
	follows:
	SKEYSEED = prf(Ni | Nr, SS1 | SS2 | ...| SSN)		Once this exchange is done, then both sides compute an updated keying
			material:
	where prf, Ni and Nr are defined as in IKEv2 [RFC7296], SSi		SKEYSEED = prf(SK_d(old), KE2result | Ni2 | Nr2)
	represents the i-th shared secret computed from the i-th key exchange
	algorithm contained in the hybrid group that was negotiated in the
	protocol. Note that if at least one of these SSi is a classical
	shared secret that is FIPS approved, then FIPS compliance design
	criteria as outlined in Section 2 is achieved. The seven secrets
	derived from SKEYSEED, namely SK_d, SK_ai, SK_ar, SK_ei, SK_er,
	SK_pi, and SK_pr, are generated as defined in IKEv2 [RFC7296].
	For child SAs that are negotiated using a hybrid group, the keying		where KE2result is the shared secret of the key exchange. Then,
	material is defined as:		SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr are updated as:
	KEYMAT = prf+(SK_d, SS1 | SS2 | ... | SSN | Ni | Nr)		{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
			= prf+ (SKEYSEED, Ni2 | Nr2 | SPIi | SPIr)
	where SSi represents the i-th shared secret computed from the i-th		Note that the negotiated transform types (the encryption type, hash
	key exchange algorithm that was performed during the negotiation of		type, prf type) are not modified.
	the child SA.
	When rekeying an IKE SA using a hybrid group, the new SKEYSEED is		Both the initiator and the responder will use this updated key values
	computed as:		for the next message.
	SKEYSEED = prf(SK_d (old), SS1 | SS2 | ... | SSN | Ni | Nr)		If the EXTRA_KEY_EXCHANGE_LIST has negotiated more than one key
			exchange, then this exchange is performed once for every key exchange
			on the list.
	where SSi represents the i-th shared secret computed from the i-th		3.2.3. IKE_AUX exchange
	key exchange algorithm that was performed during the negotiation of
	the new IKE SA.
	3.4. Post-Quantum Group Transform Type and Group Identifiers		After the IKE_AUX exchanges have completed, then the initiator and
			the responder will perform an IKE_AUTH exchange. This exchange is
			the standard IKE exchange, except that the initiator and responder
			signed octets are modified as described in
			[I-D.smyslov-ipsecme-ikev2-aux].
			3.3. Post-quantum Group Transform Type and Group Identifiers
	In generating keying material within IKEv2, both initiator and		In generating keying material within IKEv2, both initiator and
	responder negotiate up to four cryptographic algorithms in the SA		responder negotiate up to four cryptographic algorithms in the SA
	payload of an IKE_SA_INIT or a CREATE_CHILD_SA exchange. One of the		payload of an IKE_SA_INIT or a CREATE_CHILD_SA exchange. One of the
	negotiated algorithms is a Diffie-Hellman algorithm, which is used		negotiated algorithms is a Diffie-Hellman algorithm, which is used
	for key exchange. This negotiation is done using the Transform Type		for key exchange. This negotiation is done using the Transform Type
	4 (Diffie-Hellman Group) where each Diffie-Hellman group is assigned		4 (Diffie-Hellman Group) where each Diffie-Hellman group is assigned
	a unique value.		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		We expect that in the future, IANA will assign permanent values to
	these transforms. Until it does, we will use the following mappings		these transforms. Until it does, we will use the following values
	in the 'reserved for private use space':		for the below key exchanges (which will need to be specified in more
			detail elsewhere). Official identifiers will be maintained by IANA
	0x9000 HYBRID - this signifies that we are negotiating a hybrid		and updated during the NIST standardization process.
	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		Name Number Key exchange
	--------------------------------------------------		--------------------------------------------------
	NIST_CANDIDATE_1 0x9100 The 1st candidate of		NIST_CANDIDATE_1 0x9100 The 1st candidate of
	NIST PQC submission		NIST PQC submission
	NIST_CANDIDATE_2 0x9101 The 2nd candidate of		NIST_CANDIDATE_2 0x9101 The 2nd candidate of
	NIST PQC submission		NIST PQC submission
	Because we are using transforms in the private use space, both the		Because we are using transforms in the private use space, both the
	initiator and responder must include a vendor id with this payload:		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		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		This payload is the MD5 hash of "IKEv2 Quantum Safe Key Exchange
	v1"). If the other side does not include this vendor id, an		v1"). If the other side does not include this vendor id, an
	implementation MUST NOT process these private use transforms as		implementation MUST NOT process these private use transforms as
	listed in this draft.		listed in this draft.
	3.5. Hybrid Group Negotiation		3.4. Hybrid Group Negotiation
	Most post-quantum key agreement algorithms are relatively new, and		Most post-quantum key agreement algorithms are relatively new, and
	thus are not fully trusted. There are also many proposed algorithms,		thus are not fully trusted. There are also many proposed algorithms,
	with different trade-offs and relying on different hard problems.		with different trade-offs and relying on different hard problems.
	The concern is that some of these hard problems may turn out to be		The concern is that some of these hard problems may turn out to be
	easier to solve than anticipated (and thus the key agreement		easier to solve than anticipated (and thus the key agreement
	algorithm not be as secure as expected).		algorithm not be as secure as expected). A hybrid solution allows us
			to deal with this uncertainty by combining a classical key exchanges
	A hybrid solution allows us to deal with this uncertainty by		with a post-quantum one, as well as leaving open the possibility of
	combining classical key exchanges with post-quantum key agreements.		multiple post-quantum key exchanges.
	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
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Diffie-Hellman Group Num | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	~ Key Exchange Data (1500 bytes) ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Key Exchange Payload to be Fragmented
	1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| KE | Fragment Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Total Payload Length (1504) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Fragment Length (1000) | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Example FRAG_POINTER Payload for KE Payload
	1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| KE | Fragment Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Total Payload Length (1504) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Fragment Length (1000) | Fragment Number (1) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Diffie-Hellman Group Num * | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	~ Key Exchange Data[0..995] (996 bytes) ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Example FRAG_BODY Payload 1 for KE Payload
	(*) Corresponds to the payload-specific header fields beginning
	immediately after the Generic Payload Header of the Key Exchange
	payload being fragmented. This is the beginning of the Payload
	Data field in the FRAG_BODY payload.
	1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| KE | Fragment Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Total Payload Length (1504) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Fragment Length (1000) | Fragment Number (2) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	~ Key Exchange Data[996..1499] (504 bytes) ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Example FRAG_BODY Payload 2 for KE Payload
	3.6.2.3. Fragmentation Semantics
	If the receiver supports this fragmentation extension, the sender may
	fragment any payload by replacing the payload with a FRAG_POINTER
	payload and one of more FRAG_BODY payloads. If IP fragmentation is
	not a concern (e.g. when IKEv2 fragmentation is achieved using
	encrypted fragment payloads, or it's known that IP fragmentation of
	IKE_SA_INIT won't be an issue) then the corresponding FRAG_BODY
	payloads MUST appear anywhere after the FRAG_POINTER in an IKE
	message.
	An IKE_SA_INIT message may be fragmented across multiple IKE messages
	using this payload fragmentation. In this case the sender first
	sends an IKE_SA_INIT message containing the FRAG_POINTER payloads and
	any unfragmented payloads. Then it sends one IKE_SA_INIT message per
	FRAG_BODY payload generated from the original IKE_SA_INIT message.
	Each IKE_SA_INIT message must be sent with a Message ID of 0. Each
	IKE_SA_INIT message subsequent to the first one MUST contain one
	FRAG_BODY payload, MAY contain a COOKIE notification and 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.
	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.
	When the receiver receives an IKE_SA_INIT message, is may have to
	process several IKE_SA_INIT messages to reconstruct the original
	unfragmented message. If it receives the initial message containing
	the FRAG_POINTER payloads, it enqueues that message and awaits the
	corresponding IKE_SA_INIT messages containing the FRAG_POINTER
	payloads needed to reconstruct the original message. In addition, if
	it receives a FRAG_BODY message without receiving a corresponding
	FRAG_POINTER payload first, it may enqueue that payload.
	The receiver may vet the declared payload length, and reject it if it
	decides that the length is too long.
	Also note that we allow the FRAG_BODY payload to consist of the
	entire payload; this can happen if (for example) the MTU size is
	1500, and we want to transmit a 1300 byte KE payload, in addition to
	400 bytes of other IKE data.
	Once all the FRAG_BODY payloads have been received and reassembled,
	the IKE receiver may commence parsing the IKE packet. This proceeds
	as normal, except that when it sees a payload of type FRAG_POINTER,
	it looks into the FRAG_POINTER payload to see the actual payload type
	and length, and refers to the reassembly buffer for the actual
	payload data.
	Note about the criticality field; a FRAG_POINTER field may be marked
	as noncritical, which means that the IKE parser may ignore it if it
	does not understand the payload type within the FRAG_POINTER payload.
	However, even if it does that, it MUST still reassemble all the
	FRAG_BODY payloads (because of the IKE AUTH processing depends on
	them).
	3.6.2.4. IKE AUTH Processing
	When generating the IKE AUTH payload, the reassembled texts contained
	within the FRAG_BODY payloads is logically appended to the IKE
	message (and before the nonce). Specifically, we modify how
	InitiatorSignedOctets and ResponderSignedOctets are computed as
	follows:
	InitiatorSignedOctets = RealMessage1 | PayloadData1 |
	PayloadData2 | ... | PayloadDataN |
	NonceRData | MACedIDForI
	ResponderSignedOctets = RealMessage2 | PayloadData1 |
	PayloadData2 | ... | PayloadDataN |
	NonceIData | MACedIDForR
	where PayloadData1, ..., PayloadDataN are the fields from the
	FRAG_BODY payloads associated with the IKE message being
	authenticated, in the same order that the corresponding FRAG_POINTERS
	appear in, and for payloads from the same FRAG_POINTER, in increasing
	FRAGMENT_NUMBER order.
	3.6.2.5. Design Rationale
	The contents of the FRAG_POINTER/FRAG_BODY payloads were designed to
	make it easy to reassemble. The initial segments of the payloads
	were intentionally kept identical (to simply the processing if the
	FRAG_BODY arrived first); the receiver always knows how long the
	payload will be (allowing the allocation of buffers, if required);
	the receiver always knows the location in the payload data of each
	fragment (and so is able to save the data immediately into the
	buffer), and the receiver can compute the number of fragments up
	front (and hence can easily tell when all fragments have been
	received).
	The method of performing IKE AUTH processing was also designed to
	make it easy to implement; that PayloadData1 | PayloadData2 | ... |
	PayloadDataN is just the reassembled payloads concatenated together.
	3.7. Protection against Downgrade Attacks
	In RFC7296, man-in-the-middle (MitM) downgrade attack is prevented by
	always resending the full set of group proposal in subsequent
	IKE_SA_INIT messages if the responder chooses a different Diffie-
	Hellman group from the one in the initial IKE_SA_INIT message. The
	two-round nature 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.
	In order to check the proposals and policies, the responder may
	choose to maintain states between IKE_SA_INIT rounds. However, this
	increases the risk of state exhaustion attack. Of course, the
	responder may decide not to allocate any states and rely on the
	authentication in IKE_AUTH for any tampering of the exchange.
	Unfortunately, this option does not offer the benefit of an early
	downgrade attack detection; the responder will have to spend
	resources computing entities such as shared secrets and
	authentication code before knowing whether or not there is a
	downgrade attack. Such a benefit may be obtained by encoding some
	information into a cookie (Section 2.6. RFC7296).
	Whilst this document does not mandate how information should be
	encoded to form the cookie, it could be efficiently done as follows
	Cookie = <VersionIDofSecret> | Hash(KEi(#TBA) | <secret>)
	where KEi(#TBA) is the KE payload in the first round of IKE_SA_INIT
	exchange, <secret> is a randomly entity generated by the responder
	which SHOULD be changed periodically as suggested in RFC7296, and the
	entity <VersionIDofSecret> should be updated whenever <secret> is
	changed. In this scenario, the responder calculates a cookie value
	from the first round of the IKE_SA_INIT request message and sends it
	to the initiator as part of 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		The method that we use to perform hybrid key exchange also addresses
	KE(#TBA) payload in the first IKE_SA_INIT request round and also then		the fragmentation issue. The initial IKE_INIT messages do not have
	amends the N(PQ_ALGO_POLICIES) payload in the second IKE_SA_INIT		any inherent fragmentation support within IKE; however that can
	request round to create a match. In this instance, IKE_AUTH		include a relatively short KE payload (e.g. one for group 14, 19 or
	authentication SHALL fail due to the InitiatorSignedOctets being		31). The rest of the KE payloads are encrypted within IKE_AUX
	inconsistent between both peers.		messages; because they are encrypted, the standard IKE fragmentation
			solution [RFC7383] is available.
	The decision to use a cookie or allocate state SHOULD be a decision		3.5. Child SAs
	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		This method of performing hybrid key exchanges, by performing
	responder to perform many lookups for the post-quantum algorithms and		multiple exchanges in series, solves the issue by making the IKE SK
	policies, resulting in a denial-of-service (DoS) condition. In order		values be a function of all the key exchanges performed. Hence, we
	to mitigate this type of attack, the RFC7296 cookie mechanism or a		achieve the goal of making the IKE exchange secure if any of the key
	puzzle-solving mechanism as described in RFC8019 SHOULD be used. A		exchanges are secure.
	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 |		This proposal allows the support of multiple post-quantum algorithms
	KEi(#TBA) | <secret>)		(in case we don't have full confidence in any one); this is
			implemented by having the initiator list all the combinations of
			extra key exchanges he finds acceptable. It is not anticipated that
			there will be a need for a large number of different combinations of
			key exchanges, hence this relatively simple encoding method was
			selected as a reasonable compromise between simplicity and
			functionality.
	where Ni, IPi and SPIi are as described in RFC7296.		This method also allows us to fragment large post-quantum key
			exchanges; all the initiator needs to assure is that the initial key
			exchange (which has the KE payloads exchanged during IKE_SA_INIT) is
			small enough not to cause fragmentation.
	4. Alternative Design		4. Alternative Design
	This section gives an overview on a number of alternative approaches		This section gives an overview on a number of alternative approaches
	that we have considered, but later discarded. These approaches are:		that we have considered, but later discarded. These approaches are:
			o Sending the classical and post-quantum key exchanges as a single
			transform
			We considered combining the various key exchanges into a single
			large KE payload; this effort is documented in a previous version
			of this draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This
			does allow us to cleanly apply hybrid key exchanges during the
			child SA; however it does add considerable complexity, and
			requires an independant fragmentation solution.
	o Sending post-quantum proposals and policies in KE payload only		o Sending post-quantum proposals and policies in KE payload only
	With the objective of not introducing unnecessary notify payloads,		With the objective of not introducing unnecessary notify payloads,
	we considered communicating the hybrid post-quantum proposal in		we considered communicating the hybrid post-quantum proposal in
	the KE payload during the first pass of the protocol exchange.		the KE payload during the first pass of the protocol exchange.
	Unfortunately, this design is susceptible to the following		Unfortunately, this design is susceptible to the following
	downgrade attack. Consider the scenario where there is an MitM		downgrade attack. Consider the scenario where there is an MitM
	attacker sitting between an initiator and a responder. The		attacker sitting between an initiator and a responder. The
	initiator proposes, through SAi payload, to use a hybrid post-		initiator proposes, through SAi payload, to use a hybrid post-
	quantum group and as a backup a Diffie-Hellman group, and through		quantum group and as a backup a Diffie-Hellman group, and through
	skipping to change at page 29, line 24 ¶		skipping to change at page 14, line 10 ¶
	Semantically, it makes sense to use a new payload type, which		Semantically, it makes sense to use a new payload type, which
	mimics the SA payload, to carry a hybrid proposal. Likewise,		mimics the SA payload, to carry a hybrid proposal. Likewise,
	another new payload type that mimics the KE payload, could be used		another new payload type that mimics the KE payload, could be used
	to transport hybrid public value. Although, in theory a new		to transport hybrid public value. Although, in theory a new
	payload type could be made backwards compatible by not setting its		payload type could be made backwards compatible by not setting its
	critical flag as per Section 2.5 of RFC7296, we believe that it		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		may not be that simple in practice. Since the original release of
	IKEv2 in RFC4306, no new payload type has ever been proposed and		IKEv2 in RFC4306, no new payload type has ever been proposed and
	therefore, this creates a potential risk of having a backward		therefore, this creates a potential risk of having a backward
	compatibility issue from non-conforming RFC IKEv2 implementations.		compatibility issue from non-conforming RFC IKEv2 implementations.
	Since we could not see any other compelling advantages apart from		Since we could not see any other compelling advantages apart from
	a semantic one, we use the existing KE and notify payloads		a semantic one, we use the existing transform type and notify
	instead. In fact, as described above, we use the KE payload in		payloads instead. In fact, as described above, we use the KE
	the first IKE_SA_INIT request round and the notify payload to		payload in the first IKE_SA_INIT request round and the notify
	carry the post-quantum proposals and policies. We use one or more		payload to carry the post-quantum proposals and policies. We use
	of the existing KE payloads to carry the hybrid public values.		one or more of the existing KE payloads to carry the hybrid public
			values.
	o Hybrid public value payload		o Hybrid public value payload
	One way to transport the negotiated hybrid public payload, which		One way to transport the negotiated hybrid public payload, which
	contains one classical Diffie-Hellman public value and one or more		contains one classical Diffie-Hellman public value and one or more
	post-quantum public values, is to bundle these into a single KE		post-quantum public values, is to bundle these into a single KE
	payload. Alternatively, these could also be transported in a		payload. Alternatively, these could also be transported in a
	single new hybrid public value payload, but following the same		single new hybrid public value payload, but following the same
	reasoning as above, this may not be a good idea from a backward		reasoning as above, this may not be a good idea from a backward
	compatibility perspective. Using a single KE payload would		compatibility perspective. Using a single KE payload would
	skipping to change at page 30, line 14 ¶		skipping to change at page 14, line 49 ¶
	follows.		follows.
	The first approach was to treat the entire IKE_SA_INIT message as		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		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		fragments, each of which is wrapped onto a payload that would fit
	into the size of the network MTU. The payload that wraps each		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		fragment is a new payload type and it was envisaged that this new
	payload type will not cause a backward compatibility issue because		payload type will not cause a backward compatibility issue because
	at this stage of the protocol, both peers should have indicated		at this stage of the protocol, both peers should have indicated
	support of fragmentation in the first pass of the IKE_SA_INIT		support of fragmentation in the first pass of the IKE_SA_INIT
	exchange. The negotiation of fragmentation is performed using a		exchange. The negotiation of fragmentation is performed using a
	notify payload, which also defines supporting parameters such as		notify payload, which also defines supporting parameters such as
	the size of fragment in octets and the fragment identifier. The		the size of fragment in octets and the fragment identifier. The
	new payload that wraps each fragment of the messages in this		new payload that wraps each fragment of the messages in this
	exchange is assigned the same fragment identifier. Furthermore, it		exchange is assigned the same fragment identifier. Furthermore,
	also has other parameters such as a fragment index and total		it also has other parameters such as a fragment index and total
	number of fragments. We decided to discard this approach due to		number of fragments. We decided to discard this approach due to
	its blanket approach to fragmentation. In cases where only a few		its blanket approach to fragmentation. In cases where only a few
	payloads need to be fragmented, we felt that this approach is		payloads need to be fragmented, we felt that this approach is
	overly complicated.		overly complicated.
	Another idea that was discarded was fragmenting an individual		Another idea that was discarded was fragmenting an individual
	payload without introducing a new payload type. The idea was to		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		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		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		payload is fragmented. As an example, if a KE payload is to be
	skipping to change at page 31, line 15 ¶		skipping to change at page 15, line 50 ¶
	identifier to help assembly and disassembly of fragments. The		identifier to help assembly and disassembly of fragments. The
	Fragment Index and Total Fragments fields are self-explanatory.		Fragment Index and Total Fragments fields are self-explanatory.
	The Total KE Payload Data Length indicates the size of the		The Total KE Payload Data Length indicates the size of the
	assembled KE payload data in octets. Finally, the actual fragment		assembled KE payload data in octets. Finally, the actual fragment
	is carried in Fragment KE Payload field.		is carried in Fragment KE Payload field.
	We discarded this approach because we believe that the working		We discarded this approach because we believe that the working
	group may not be happy using the RESERVED field to change the		group may not be happy using the RESERVED field to change the
	format of a packet and that implementers may not like the		format of a packet and that implementers may not like the
	complexity added from checking the fragmentation flag in each		complexity added from checking the fragmentation flag in each
	received payload. Furthermore, we dismissed this idea in favour		received payload. More importantly, fragmenting the messages in
	of the idea present in Section 3.6 due to the handling of the		this way may leave the system to be more prone to denial of
	total IKEv2 payload size. There was not a clean method for the		service (DoS) attacks. By using IKE_AUX to transport the large
	receiver to determine the total size of all the IKEv2 fragmented		post-quantum key exchange payloads, there is no longer any issue
	payloads. The method defined in Section 3.6 allows for a clean		with fragmentation.
	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		o Group sub-identifier
	As discussed in Section 3.4, each group identifier is used to		As discussed in Section 3.3, each group identifier is used to
	distinguish a post-quantum algorithm. Further classification		distinguish a post-quantum algorithm. Further classification
	could be made on a particular post-quantum algorithm by assigning		could be made on a particular post-quantum algorithm by assigning
	additional value alongside the group identifier. This sub-		additional value alongside the group identifier. This sub-
	identifier value may be used to assign different security		identifier value may be used to assign different security
	parameter sets to a given post-quantum algorithm. However, this		parameter sets to a given post-quantum algorithm. However, this
	level of details does not fit the principles of the document where		level of details does not fit the principles of the document where
	it should deal with generic hybrid key exchange protocol, not a		it should deal with generic hybrid key exchange protocol, not a
	specific ciphersuite. Furthermore, there are enough Diffie-		specific ciphersuite. Furthermore, there are enough Diffie-
	Hellman group identifiers should this be required in the future.		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		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 provide		transforms SHALL be at least 256 bits long in order to provide
	sufficient resistance to quantum attacks. Accordingly the post-		sufficient resistance to quantum attacks. Accordingly the post-
	quantum security level achieved is at least 128 bits.		quantum security level achieved is at least 128 bits.
	SKEYSEED is calculated from shared, KEx, using an algorithm defined		SKEYSEED is calculated from shared, KEx, using an algorithm defined
	in Transform Type 2. While a quantum attacker may learn the value of		in Transform Type 2. While a quantum attacker may learn the value of
	KEx', if this value is obtained by means of a classical key exchange,		KEx', if this value is obtained by means of a classical key exchange,
	other KEx values generated by means of a quantum-resistant algorithm		other KEx values generated by means of a quantum-resistant algorithm
	ensure that SKEYSEED is not compromised. This assumes that the		ensure that the final SKEYSEED is not compromised. This assumes that
	algorithm defined in the Transform Type 2 is post-quantum.		the algorithm defined in the Transform Type 2 is post-quantum.
	The main focus of this document is to prevent a passive attacker		The main focus of this document is to prevent a passive attacker
	performing a "harvest and decrypt" attack. In other words, an		performing a "harvest and decrypt" attack. In other words, an
	attacker that records messages exchanges today and proceeds to		attacker that records messages exchanges today and proceeds to
	decrypt them once he owns a quantum computer. This attack is		decrypt them once he owns a quantum computer. This attack is
	prevented due to the hybrid nature of the key exchange. Other		prevented due to the hybrid nature of the key exchange. Other
	attacks involving an active attacker using a quantum-computer are not		attacks involving an active attacker using a quantum-computer are not
	completely solved by this document since the authentication step		completely solved by this document. This is for two reasons.
	remains classical. In particular, the authenticity of the SAs
	established under IKEv2 is protected using a pre-shared key, RSA,		The first reason is because the authentication step remains
	DSA, or ECDSA algorithms. Whilst the pre-shared key option, provided		classical. In particular, the authenticity of the SAs established
	the key is long enough, is post-quantum, the other algorithms are		under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA
	not. Moreover, in implementations where scalability is a		algorithms. Whilst the pre-shared key option, provided the key is
	requirement, the pre-shared key method may not be suitable. Quantum-		long enough, is post-quantum, the other algorithms are not.
	safe authenticity may be provided by using a quantum-safe digital
	signature and several quantum-safe digital signature methods are		Moreover, in implementations where scalability is a requirement, the
	being explored by IETF. For example the hash based method, XMSS has		pre-shared key method may not be suitable. Quantum-safe authenticity
	the status of an Internet Draft, see [XMSS]. Currently, quantum-safe		may be provided by using a quantum-safe digital signature and several
	authentication methods are not specified in this document, but are		quantum-safe digital signature methods are being explored by IETF.
	planned to be incorporated in due course.		For example, if the implementation is able to reliably track state,
			the hash based method, XMSS has the status of an RFC, see [RFC8391].
			Currently, quantum-safe authentication methods are not specified in
			this document, but are planned to be incorporated in due course.
	It should be noted that the purpose of post-quantum algorithms is to		It should be noted that the purpose of post-quantum algorithms is to
	provide resistance to attacks mounted in the future. The current		provide resistance to attacks mounted in the future. The current
	threat is that encrypted sessions are 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 key exchange mechanism in this document provides a method for		This draft does not attempt to address key exchanges with KE payloads
	malicious parties to send multiple KE payloads, where each of which		longer than 64k; the current IKE payload format does not allow that
	could be large, to a responder. As the standard behavior is for the		as a possibility. If such huge KE payloads are required, a work
	responder to consume computational resources to compute and send		around (such as making the KE payload a URL and a hash of the real
	multiple KE payloads back to the initiator, this allows for a simple		payload) would be needed. At the current time, it appears likely
	method for malicious parties to cause a VPN gateway to perform		that there will be plenty of key exchanges available that would not
	excessive processing. In order to mitigate against this threat,		require such a workaround.
	implementations MAY make use of the DoS prevention COOKIE
	notification as defined in [RFC7296], to mitigate spoofed traffic and
	a puzzle-solving notification [RFC8019] to minimize the impact from
	hosts who use their own IP address.
	Cookie notification is used to prevent downgrade attacks. The cookie
	SHALL NOT be of arbitrary length, otherwise it will be susceptible to
	SLOTH attack as described in [BL]. It is RECOMMENDED that the length
	of the cookie be no longer than 64 octets.
	6. References		6. References
	[ADPS] Alkim, E., Ducas, L., Poppelmann, T., and Schwabe, P.,
	"Post-quantum Key Exchange - a New Hope", 25th USENIX
	Security Symposium, pp. 327-343, 2016.
	[AH] Kent, S., "IP Authentication Header", RFC 4302, December		[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>.
	[BL] Bhargavan, K. and Leurent, G., "Transcript Collision		[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
	Attacks: Breaking Authentication in TLS, IKE, and SSH",		RFC 4303, December 2005,
	Network and Distributed System Security Symposium, 2016.		<http://www.rfc-editor.org/info/rfc4303>.
	[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
	4303, December 2005, <http://www.rfc-
	editor.org/info/rfc4303>.
	[FMKS] Fluhrer, S., McGrew, D., Kampanakis, P., and Smyslov, V.,
	"Postquantum Preshared Keys for IKEv2", Internet draft,
	https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-
	ikev2, 2017.
	[GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for		[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.
	[IKEV2IANA]		[I-D.ietf-ipsecme-qr-ikev2]
	IANA, "Internet Key Exchange Version 2 (IKEv2)		Fluhrer, S., McGrew, D., Kampanakis, P., and V. Smyslov,
	Parameters", <http://www.iana.org/assignments/ikev2-		"Postquantum Preshared Keys for IKEv2", draft-ietf-
	parameters/>.		ipsecme-qr-ikev2-03 (work in progress), June 2018.
	[LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,		[I-D.smyslov-ipsecme-ikev2-aux]
	Green, M., Halderman, J., Heninger, N., Springall, D.,		Smyslov, V., "Auxiliary Exchange in the IKEv2 Protocol",
	Thome, E., Valenta, L., VanderSloot, B., Wustrow, E.,		draft-smyslov-ipsecme-ikev2-aux-00 (work in progress),
	Beguelin, S., and Zimmermann, P., "Imperfect forward		January 2018.
	secrecy: How Diffie-Hellman fails in practice", Proc. 22rd
	ACM SIGSAC Conference on Computer and Communications
	Security, pp. 5-17, 2015.
	[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", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, T., "Internet Key Exchange Protocol Version 2		Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", RFC 7296, October 2014.		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
			2014, <https://www.rfc-editor.org/info/rfc7296>.
	[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,
			DOI 10.17487/RFC7383, November 2014,
	[RFC8019] Nir, Y., Smyslov, V., "Protecting Internet Key Exchange		<https://www.rfc-editor.org/info/rfc7383>.
	Protocol Version 2 (IKEv2) Implementations from
	Distributed Denial-of-Service Attacks", RFC 8019, November
	2016.
	[RFC8229] Pauly, T., Touati, S., and Mantha, R., "TCP Encapsulation		[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
	of IKE and IPsec Packets", RFC8229, August 2017.		of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
			August 2017, <https://www.rfc-editor.org/info/rfc8229>.
	[XMSS] Huelsing, A., Butin, D., Gazdag, S., and Mohaisen, A.,		[RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A.
	"XMSS: Extended Hash-Based Signatures", Crypto Forum		Mohaisen, "XMSS: eXtended Merkle Signature Scheme",
	Research Group Internet Draft, 2017		RFC 8391, DOI 10.17487/RFC8391, May 2018,
			<https://www.rfc-editor.org/info/rfc8391>.
	Acknowledgements		Acknowledgements
	The authors would like to thanks Frederic Detienne and Olivier		The authors would like to thanks Frederic Detienne and Olivier
	Pelerin for their comments and suggestions, including the idea to		Pelerin for their comments and suggestions, including the idea to
	negotiate the post-quantum algorithms using the existing KE payload.		negotiate the post-quantum algorithms using the existing KE payload.
	Authors' Addresses		Authors' Addresses
	C. Tjhai		C. Tjhai
	Post-Quantum		Post-Quantum
	email: cjt [at] post-quantum.com
			Email: cjt@post-quantum.com
	M. Tomlinson		M. Tomlinson
	Post-Quantum		Post-Quantum
	email: mt [at] post-quantum.com
			Email: mt@post-quantum.com
	G. Bartlett		G. Bartlett
	Cisco Systems		Cisco Systems
	email: grbartle [at] cisco.com
			Email: grbartle@cisco.com
	S. Fluhrer		S. Fluhrer
	Cisco Systems		Cisco Systems
	email: sfluhrer [at] cisco.com
			Email: sfluhrer@cisco.com
	D. Van Geest		D. Van Geest
	ISARA Corporation		ISARA Corporation
	email: daniel.vangeest [at] isara.com
			Email: daniel.vangeest@isara.com
	Z. Zhang		Z. Zhang
	Onboard Security		Onboard Security
	email: zzhang [at] onboardsecurity.com
			Email: zzhang@onboardsecurity.com
	O. Garcia-Morchon		O. Garcia-Morchon
	Philips		Philips
	email: oscar.garcia-morchon [at] philips.com
			Email: oscar.garcia-morchon@philips.com
End of changes. 116 change blocks.
	1115 lines changed or deleted		397 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/