< draft-tjhai-ikev2-beyond-64k-limit-00.txt		draft-tjhai-ikev2-beyond-64k-limit-01.txt >
	Network Working Group CJ. Tjhai		Network Working Group CJ. Tjhai
	Internet-Draft Post-Quantum		Internet-Draft Post-Quantum
	Intended status: Standards Track T. Heider		Intended status: Standards Track T. Heider
	Expires: May 5, 2021 genua GmbH		Expires: January 10, 2022 genua GmbH
	V. Smyslov		V. Smyslov
	ELVIS-PLUS		ELVIS-PLUS
	November 1, 2020		July 9, 2021
	Beyond 64KB Limit of IKEv2 Payload		Beyond 64KB Limit of IKEv2 Payloads
	draft-tjhai-ikev2-beyond-64k-limit-00		draft-tjhai-ikev2-beyond-64k-limit-01
	Abstract		Abstract
	The maximum Internet Key Exchange Version 2 (IKEv2) payload size is		The maximum Internet Key Exchange Version 2 (IKEv2) payload size is
	limited to 64KB. This makes IKEv2 not usable for conservative post-		limited to 64KB. This makes IKEv2 not usable for conservative post-
	quantum cryptosystem whose public-key is larger than 64KB. This		quantum cryptosystem whose public-key is larger than 64KB. This
	document describes the mechanisms and considerations to exchange such		document discusses the considerations and defines a mechanism to
	large key-establishment data in IKEv2.		exchange large post-quantum public keys and signatures in IKEv2.
	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 https://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 May 5, 2021.		This Internet-Draft will expire on January 10, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Fragmentation of Large Payload . . . . . . . . . . . . . . . 4		2. Proposed Solution Overview . . . . . . . . . . . . . . . . . 4
	2.1. Hash and URL . . . . . . . . . . . . . . . . . . . . . . 4		3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 6
	2.1.1. Key Exchange Payload . . . . . . . . . . . . . . . . 4		4. Operational Considerations . . . . . . . . . . . . . . . . . 8
	2.1.2. Certificate Payload . . . . . . . . . . . . . . . . . 5		5. Denial of Service Considerations . . . . . . . . . . . . . . 8
	2.2. Payload Fragmentation . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	2.2.1. Bulk Transfer and Confirmation . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	2.2.2. Incremental Transfer and Confirmation . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3. Operational Considerations . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . 10
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 11
	5.1. Normative References . . . . . . . . . . . . . . . . . . 10		A.1. Hash and URL . . . . . . . . . . . . . . . . . . . . . . 11
	5.2. Informative References . . . . . . . . . . . . . . . . . 10		A.1.1. Key Exchange Payload . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		A.1.2. Certificate Payload . . . . . . . . . . . . . . . . . 13
			A.2. Incremental Transfer and Confirmation . . . . . . . . . . 13
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Our digital communications are secured by public-key cryptography		Digital communications are secured by public-key cryptography
	algorithms that relies on computational hardness assumptions such as		algorithms that rely on computational hardness assumptions such as
	the difficulty in factoring large integers or that of finding the		the difficulty in factoring large integers or that of finding the
	discrete logarithm on an elliptic curve group or finite-field.		discrete logarithm on an elliptic curve group or finite-field.
	Recent advances in quantum computing, however, have caused some		Recent advances in quantum computing, however, have caused some
	concerns on the security of these assumptions. It is conjectured		concerns on the security of these assumptions. It is conjectured
	that these hard computational problems can be solved in polynomial		that these hard computational problems can be solved in polynomial
	time when sufficiently large quantum computers become available. The		time when sufficiently large quantum computers become available. The
	concerns have prompted the National Institute of Standards and		concerns have prompted the National Institute of Standards and
	Technology (NIST) to initiate a process to standardize one or more		Technology (NIST) to initiate a process to standardize one or more
	public-key algorithms that are quantum-resistant. This family of		public-key algorithms that are quantum-resistant. This family of
	algorithms is known as post-quantum or quantum-resistant		algorithms is known as post-quantum or quantum-resistant
	skipping to change at page 3, line 12 ¶		skipping to change at page 3, line 14 ¶
	addressed by sending the post-quantum exchange data in		addressed by sending the post-quantum exchange data in
	IKE_INTERMEDIATE [I-D.ietf-ipsecme-ikev2-intermediate], which is the		IKE_INTERMEDIATE [I-D.ietf-ipsecme-ikev2-intermediate], which is the
	intermediary state between IKE_SA_INIT and IKE_AUTH. This is the		intermediary state between IKE_SA_INIT and IKE_AUTH. This is the
	approach taken in [I-D.ietf-ipsecme-ikev2-multiple-ke] whereby a		approach taken in [I-D.ietf-ipsecme-ikev2-multiple-ke] whereby a
	classical and one or more post-quantum key exchanges are combined in		classical and one or more post-quantum key exchanges are combined in
	order to establish security associations that are quantum-resistant.		order to establish security associations that are quantum-resistant.
	Because all public-key cryptography algorithms rely on computational		Because all public-key cryptography algorithms rely on computational
	hardness assumptions, the confidence of a cryptographic algorithm is		hardness assumptions, the confidence of a cryptographic algorithm is
	an important consideration. An algorithm that has been well-studied		an important consideration. An algorithm that has been well-studied
	and field-tested is better trusted than newer ones. Unfortunately,		and field-tested is generally better trusted than newer ones.
	the confidence of post-quantum cryptographic algorithms is relatively		Unfortunately, the confidence of post-quantum cryptographic
	low. All of the algorithms submitted to NIST post-quantum		algorithms is relatively low. All of the algorithms submitted to
	standardization are based on new computational hardness assumptions		NIST post-quantum standardization are based on new computational
	and despite being conjectured to be resistant to quantum computer		hardness assumptions and despite being conjectured to be resistant to
	attacks, they have not been well cryptanalyzed compared to the		quantum computer attacks, they have not been well cryptanalyzed
	classical counterparts. An exception to this is the Goppa-code based		compared to the classical counterparts. An exception to this is the
	McEliece cryptosystem [McEliece] which has withstood years of		Goppa-code based McEliece cryptosystem [McEliece] which has withstood
	cryptanalysis since 1978 and still remains unbroken. It is not		years of cryptanalysis since 1978 and still remains unbroken. It is
	surprising that a more efficient and CCA secure version of McEliece		not surprising that a more efficient and CCA secure version of
	cryptosystem, Classic McEliece [CM], is selected as one of the		McEliece cryptosystem, Classic McEliece [CM], is selected as one of
	finalists in NIST post-quantum standardization. Furthermore, this		the finalists in NIST post-quantum cryptography standardization (at
			the time of writing this document) [NIST]. Furthermore, this
	cryptosystem has also been recommended for long-term confidentiality		cryptosystem has also been recommended for long-term confidentiality
	protection of data, see [BSI].		protection of data, see [BSI].
	While there is interest in using McEliece cryptosystem, in particular		While there is interest in using McEliece cryptosystem, in particular
	for information that needs to remain secure for a long time, there is		for information that needs to remain secure for a long time, there is
	a challenge in integrating it with IKEv2 [RFC7296]. One		a challenge in integrating it with IKEv2 [RFC7296]. One
	characteristic of McElieces cryptosystem is the very asymmetric size		characteristic of McElieces cryptosystem is the very asymmetric size
	of its ciphertext and public-key. While its ciphertext is the		of its ciphertext and public-key. While its ciphertext is the
	smallest compared to all other post-quantum key-establishment		smallest compared to all other post-quantum key-establishment
	algorithms submitted to NIST, the size of its public-key, however, is		algorithms submitted to NIST, the size of its public-key, however, is
	the largest. The smallest public-key size of Classic McEliece is		the largest. The smallest public-key size of Classic McEliece is
	255KB. This presents a problem if one were to use Classic McEliece		255KB. This presents a problem if one were to use Classic McEliece
	for key-establishment with IKEv2, as the maximum payload size		for key-establishment with IKEv2, as the maximum payload size
	supported by IKEv2 is limited to 64KB. This document describes a		supported by IKEv2 is limited to 64KB. This document describes a
	mechanism to support IKEv2 key-exchange with key size larger than		mechanism to support IKEv2 key-exchange with key size larger than
	64KB, building on the works in [I-D.ietf-ipsecme-ikev2-multiple-ke]		64KB, building on the works in [I-D.ietf-ipsecme-ikev2-multiple-ke]
	and [I-D.ietf-ipsecme-ikev2-intermediate].		and [I-D.ietf-ipsecme-ikev2-intermediate].
			In addition, some post-quantum digital signature algorithms that are
			finalists or alternate candidates of NIST post-quantum cryptography
			standardization (at the time of writing this document) [NIST], also
			have either public key size or signature size greater than 64 KB.
			This makes impossible to use them in IKEv2 as drop-in replacement for
			classic signature algorithms.
			This document is focused on providing a solution for using large
			post-quantum algorithms related data (public keys and signatures) in
			IKEv2. It is not a goal of this document to provide a generic
			solution to transport large data blocks of arbitrary type in IKEv2.
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in [RFC2119] and
			[RFC8174].
	This document assumes familiarity with IKEv2 concept described in		This document assumes familiarity with IKEv2 concept described in
	[RFC7296].		[RFC7296].
	2. Fragmentation of Large Payload		2. Proposed Solution Overview
	A method to extend IKEv2 that allows quantum-resistant shared secret		While the Length field in IKEv2 header has a size of 32 bits, so that
	to be derived from at least one post-quantum key-establishment		the maximum size of an IKEv2 message can theoretically reach 4 GB,
	algorithm is proposed in [I-D.ietf-ipsecme-ikev2-multiple-ke]. Each		the size of any individual payload inside a message is limited to 64
	post-quantum key-establishment data is transported using an		KB due to the fact that the Payload Length field in generic payload
	IKE_INTERMEDIATE message, which appears following an IKE_SA_INIT		header consumes 16 bits only. This makes impossible to transfer
	exchange. This is necessary because most post-quantum key-		blocks of data greater than 64 KB, such as public keys of some post-
	establishment data are larger than 1KB and therefore are likely to be		quantum key exchange methods or some post-quantum signatures. In
	dropped by firewalls and network middleboxes if they are sent in the		IKEv2 three types of payloads may contain large amounts of data
	IKE_SA_INIT message over a UDP channel. IKEv2 has a mechanism to		related to post-quantum algorithms:
	handle IP-level fragmentation [RFC7383], but it is only available to
	messages sent after the IKE_SA_INIT exchange. As such, it is
	necessary to send these post-quantum key-establishment payloads in
	IKE_INTERMEDIATE so that it can benefit from the IKEv2 message
	fragmentation mechanism.
	IKEv2 message fragmentation [RFC7383] allows a big payload to be		o Key Exchange (KE) payload in case of large public key of a post-
	broken up into a number of smaller UDP datagrams. However, this		quantum key exchange method
	mechanism can only be used to fragment payloads up to 64KB in size.
	For larger messages, different mechanisms are required and two of
	which are discussed below.
	2.1. Hash and URL		o Authentication (AUTH) payload in case of large signature of a
			post-quantum signature algorithm
			o Certificate (CERT) payloads in case of large public key of a post-
			quantum signature algorithm
			This specification proposes the following solution to the problem:
			when block of data of a particular type (public key, signature)
			exceeds 64 KB in size, it is split into a series of chunks smaller
			than 64 KB. Each chunk then is placed in its own payload, so that
			the large block of data is eventually transferred in a series of
			adjacent payloads of the same type. All these payloads MUST have the
			same values in their headers (except for Next Payload and Payload
			Length fields) and MUST be transferred adjacent to each other, so
			that no other payload should appear between them.
			This approach works well for KE and AUTH payloads, since only one
			such large block is transferred in a message and there is no
			ambiguity when it is split over multiple payloads. However, when
			multiple certificates containing large public keys are transferred
			and each of them is further splitted into several CERT payloads,
			there must be a way to find boundaries between these certificates on
			a receiving side. To solve this problem an empty CERT payload MUST
			be inserted between other non-empty CERT payloads to mark boundaries
			between individual certificates. Note that large certificates can
			also be transferred using "Hash and URL" format (see Section 3.6 of
			[RFC7296].
			The resulting message would exceed 64 KB in size, so that it would
			not fit into a single UDP datagram. Even if TCP transport
			[I-D.ietf-ipsecme-rfc8229bis] is used, the size of any individual IKE
			message in a TCP stream is still limited to 64 KB. For this reason,
			IKE Fragmentation [RFC7383] MUST be used regardless of the transport
			protocol if peers are going to transfer large blocks of data. In the
			case of TCP, the size of fragments is not related to path MTU and can
			reach 64 KB.
			Since IKE Fragmentation is mandatory with this extension and it only
			can be used on encrypted IKE messages, large blocks of data cannot be
			transferred in the IKE_SA_INIT exchange.
			In encrypted IKE messages, the Encrypted Payload contains other
			payloads in encrypted form. Since the Payload Length field in the
			generic IKE payload header has a size of 16 bits, it is impossible to
			set a proper value for it in the Encrypted Payload header when it
			contains inner payloads with total length greater than 64 KB.
			However, since using IKE Fragmentation is mandatory when transferring
			large blocks of data (even in case of TCP transport), this
			restriction has no effect. In the case of IKE Fragmentation, the
			Payload Length field in the Encrypted payload is never transmitted
			and is used for local processing only. Instead, the IKE message
			fragments that appear on the wire are limited to 64 KB, so there is
			no problem with setting a proper value in the Length field of
			Encrypted Fragment payloads. However, implementations must be
			prepared that when constructing messages before their fragmentation
			and after their re-assembly, the total length of the Encrypted
			payload content may exceed 64 KB.
			While mandatory IKE Fragmentation makes it possible to transfer large
			blocks of data using UDP transport, in practice it may be problematic
			for the following reason. When fragmenting large messages the number
			of fragments would be high and all of them are sent at once. If any
			of these fragment were lost, all the fragments should be re-sent. In
			congested network environments this would have a negative effect,
			worsening the congestion. Moreover, the number of IKE message
			fragments is limited to 2^16. With typical size of IKE message
			fragment equal to PMTU or less, this would limit the size of a single
			large block of data to ~30-100 MB. While this is enough for current
			applications of this specification, it may be a limitation in the
			future.
			TCP transport has built-in acknowledgement and congestion control
			mechanisms and does not suffer from these problems. In addition,
			since the size of IKE message fragments in case of TCP may be up to
			64 KB, the size of a single large block of data can in theory reach 4
			GB. However, [I-D.ietf-ipsecme-rfc8229bis] implies that if TCP is
			used as transport for IKE, it is also used for ESP. Encapsulation
			ESP in TCP has a lot of negative effects on performance and on ESP
			functionality (see Section 10 of [I-D.ietf-ipsecme-rfc8229bis].
			This specifications proposes a mixed transport mode as a solution to
			the problem. In this mode, IKE uses TCP as its transport, while ESP
			packets are still sent over IP or are encapsulated in UDP. The use
			of mixed transport mode is optional and is negotiated in the
			IKE_SA_INIT exchange.
			3. Protocol Details
			The initiator starts creating an IKEv2 SA by sending the IKE_SA_INIT
			request message. If the initiator is going to transfer large blocks
			of data (e.g. large public keys), then it should make some
			preparations:
			o IKEV2_FRAGMENTATION_SUPPORTED notification MUST be included to
			negotiate support for IKE Fragmentation
			o INTERMEDIATE_EXCHANGE_SUPPORTED notification MUST be included if
			the initiator proposes key exchange methods with public keys
			greater than 64 KB
			o If the initiator is going to use mixed transport mode then it
			starts the IKE_SA_INIT request using UDP port 4500 and includes a
			new status type notification IKE_OVER_TCP (<TBA by IANA>), which
			has protocol 0, SPI size 0 and contains no data; if the initiator
			starts the IKE_SA_INIT over TCP, then the mixed transport mode
			cannot be used and this notification SHOULD NOT be included, it
			MUST be ignored by the responder if it is still included in the
			message
			Note that UDP port 4500 (and not port 500) is used for the
			IKE_SA_INIT messages, which is allowed by [RFC7296]. Using port 4500
			allows return routability check for UDP messages to be carried out
			and ensures ESP packets can get through if they are UDP encapsulated.
			The responder supporting this specification MUST agree on using IKE
			Fragmentation by sending back IKEV2_FRAGMENTATION_SUPPORTED
			notification. If it selects proposal with key exchange method having
			public key greater than 64 KB, then it MUST agree on using the
			IKE_INTERMEDIATE exchange by sending back
			INTERMEDIATE_EXCHANGE_SUPPORTED notification.
			If the initiator proposed using mixed transport mode by initiating
			the IKE_SA_INIT exchange over UDP port 4500 and including
			IKE_OVER_TCP notification and the responder supports this mode and is
			willing to use it, then it sends this notification back in the
			IKE_SA_INIT response. In this case the initiator MUST switch to TCP
			using destination port 4500 in the next exchange (IKE_INTERMEDIATE or
			IKE_AUTH) and the responder MUST be prepared to receive the next
			exchange request message on TCP port 4500. Once switched all
			subsequent IKE exchanges MUST use TCP transport as described in
			[I-D.ietf-ipsecme-rfc8229bis], but ESP packets MUST NOT be sent using
			TCP, instead they are sent either over IP or using UDP encapsulation,
			depending on the presence of NAT, which is determined in the
			IKE_SA_INIT exchange.
			If the responder does not support mixed transport mode, then it
			ignores the IKE_OVER_TCP notification and all subsequent IKE
			exchanges will use UDP transport. Note, that in case the initiator
			started the IKE_SA_INIT over TCP then the IKE_OVER_TCP notification
			would not be included in the request message and there would be no
			option for mixed transport mode.
			Initiator Responder
			-------------------------------------------------------------------
			HDR, SAi1, KEi1, Ni,
			N(NAT_DETECTION_SOURCE_IP),
			N(NAT_DETECTION_DESTINATION_IP),
			N(IKEV2_FRAGMENTATION_SUPPORTED),
			[N(INTERMEDIATE_EXCHANGE_SUPPORTED),]
			[N(IKE_OVER_TCP)] --->
			HDR, SAr1, KEr1, Nr,
			N(NAT_DETECTION_SOURCE_IP),
			N(NAT_DETECTION_DESTINATION_IP),
			N(IKEV2_FRAGMENTATION_SUPPORTED),
			[N(INTERMEDIATE_EXCHANGE_SUPPORTED),]
			<--- [N(IKE_OVER_TCP)]
			Once the IKE_SA_INIT exchange is completed, the peers continue with
			the following exchanges: one or more IKE_INTERMEDITE exchanges in
			case multiple key exchanges are negotiated or the IKE_AUTH exchange,
			as shown below. Note that all messages containing large blocks of
			data are sent fragmented using IKE Fragmentation mechanism, but they
			are not shown here for the sake of simplicity.
			Initiator Responder
			-------------------------------------------------------------------
			HDR, SK{KEi2.1, KEi2.2, KEi2.3, ...} --->
			<--- HDR, SK{KEr2.1, KEr2.2, ...}
			HDR, SK{KEi3.1, KEi3.2, ...} --->
			<--- HDR, SK{KEr3.1, KEr3.2, ...}
			...
			HDR, SK{IDi, [IDr,] [CERTi1, CERTi2, ...]
			[CERTREQ,] [IDr,] AUTHi1, AUTHi2, ...
			SAi2, TSi, TSr} --->
			<--- HDR, SK{IDr, [CERTr1, CERTr2, ...]
			AUTHr1, AUTHr2, ...
			SAr2, TSi, TSr}
			4. Operational Considerations
			The IKE fragmentation does not require additional infrastructure,
			however, there is non-zero probability of lost packets when sending a
			large number of fragments over a UDP connection. Given a set of
			fragments, when transmitted, each one of them is not individually
			acknowledged and if any one of them is lost, the entire set will have
			to be retransmitted. As a consequence, given the size of the payload
			and also the potential of multiple retransmissions, there may be a
			noticeable delay in establishing an security association (SA), in
			particular in lossy network conditions. Therefore, implementations
			MAY use a longer timeout value for the purpose of dead-peer
			detection, but a balance needs to be struck as too large of a value
			will open up security vulnerabilities as discussed in the following
			section. In the unlikely event where there is a frequent
			retransmission due to loss of fragments, implementations MAY send the
			IKE messages over a TCP connection as specified in
			[I-D.ietf-ipsecme-rfc8229bis]. If TCP is used as IKE transport, then
			using mixed transport mode is RECOMMENDED to allow better ESP
			performance.
			5. Denial of Service Considerations
			Malicious peers may send a large number of fragments, but incomplete,
			to the legitimate peer causing memory exhaustion. It is RECOMMENDED
			that the strategies and recommendations described in [RFC8019] be
			implemented to counter possible DoS attacks.
			An alternative arrangement, if peers do not support [RFC8019], is to
			allow the transfer of large block of data only after peers are
			authenticated. In other words, key-establishment using large public-
			key should not be done to establish an IKE SA, but it should only be
			used to establish a Child SA or rekeying an IKE SA. In order to
			protect IKE messages from quantum threats, multiple key-exchanges
			using a combination of classical and post-quantum ciphers, as
			described in [I-D.ietf-ipsecme-ikev2-multiple-ke] can be used.
			Nonetheless, this approach has a limitation whereby if a digital
			signature scheme with large public-key or signature payload is used,
			it is still susceptible to DoS attacks.
			*** More to be populated in the next version ***
			6. Security Considerations
			If TCP encapsulation is used, refer to the security considerations in
			[I-D.ietf-ipsecme-rfc8229bis].
			Downloading or transferring large amounts of data is an expensive
			operation, bandwidth and memory wise. Consequently, implementations
			should consider using a longer rekeying interval or SHOULD consider
			relaxing forward secrecy requirements but using CCA-secure key-
			establishment algorithms only. With chosen-ciphertext attack (CCA)-
			secure schemes, there is no loss in security if the public-key is
			reused.
			7. IANA Considerations
			This document defines a new Notify Message Type in the "Notify
			Message Types - Status Types" registry:
			<TBA> IKE_OVER_TCP
			8. References
			8.1. Normative References
			[I-D.ietf-ipsecme-ikev2-intermediate]
			Smyslov, V., "Intermediate Exchange in the IKEv2
			Protocol", draft-ietf-ipsecme-ikev2-intermediate-06 (work
			in progress), March 2021.
			[I-D.ietf-ipsecme-ikev2-multiple-ke]
			Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S.,
			Geest, D. V., Garcia-Morchon, O., and V. Smyslov,
			"Multiple Key Exchanges in IKEv2", draft-ietf-ipsecme-
			ikev2-multiple-ke-02 (work in progress), January 2021.
			[I-D.ietf-ipsecme-rfc8229bis]
			Smyslov, V. and T. Pauly, "TCP Encapsulation of IKE and
			IPsec Packets", draft-ietf-ipsecme-rfc8229bis-00 (work in
			progress), April 2021.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
			[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
			Kivinen, "Internet Key Exchange Protocol Version 2
			(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
			2014, <https://www.rfc-editor.org/info/rfc7296>.
			[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
			(IKEv2) Message Fragmentation", RFC 7383,
			DOI 10.17487/RFC7383, November 2014,
			<https://www.rfc-editor.org/info/rfc7383>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			8.2. Informative References
			[BSI] Federal Office for Information Security, "Cryptographic
			Mechanisms: Recommendations and Key Lengths", 2020, <https
			://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publication
			s/TechGuidelines/TG02102/BSI-TR-02102-1.pdf>.
			[CM] Classic McEliece submission team, "Classic McEliece: NIST
			post-quantum cryptography standardization finalist", 2020,
			<https://classic.mceliece.org/>.
			[FIPS-202]
			National Institute of Standards and Technology, "SHA-3
			Standard: Permutation-Based Hash and Extendable-Output
			Functions", 2015, <https://doi.org/10.6028/NIST.FIPS.202>.
			[McEliece]
			McEliece, R., "A Public-key Cryptosystem based on
			Algebraic Coding Theory", DSN Progress Report 42-44,
			1978.
			[NIST] National Institute of Standards and Technology, "Post-
			Quantum Cryptography Standardization",
			<https://csrc.nist.gov/Projects/post-quantum-cryptography/
			post-quantum-cryptography-standardization>.
			[RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange
			Protocol Version 2 (IKEv2) Implementations from
			Distributed Denial-of-Service Attacks", RFC 8019,
			DOI 10.17487/RFC8019, November 2016,
			<https://www.rfc-editor.org/info/rfc8019>.
			Appendix A. Alternative Approaches
			A.1. Hash and URL
	[RFC7296] defines a mechanism whereby an authentication payload such		[RFC7296] defines a mechanism whereby an authentication payload such
	as a certificate can be encoded using a hash value and a URL. A peer		as a certificate can be encoded using a hash value and a URL. A peer
	utilizes HTTP_CERT_LOOKUP_SUPPORTED Notify payload to indicate that		utilizes HTTP_CERT_LOOKUP_SUPPORTED Notify payload to indicate that
	X.509 certificates are not transported in-band, instead the other		X.509 certificates are not transported in-band, instead the other
	peer shall fetch the certificates from the given URL and verify its		peer shall fetch the certificates from the given URL and verify its
	integrity from the hash value. In this way, the peer needs to send		integrity from the hash value. In this way, the peer needs to send
	20 octets plus a variable length URL only over the wire, instead of a		20 octets plus a variable length URL only over the wire, instead of a
	few kilobytes of payload, which is useful in the event IKEv2 message		few kilobytes of payload, which is useful in the event IKEv2 message
	fragmentation is not available.		fragmentation is not available.
	Large public keys can be transported by reusing the same technique		Large public keys can be transported by reusing the same technique
	and this can be done in two ways, as described below.		and this can be done in two ways, as described below.
	2.1.1. Key Exchange Payload		A.1.1. Key Exchange Payload
	The Key Exchange Data field of IKEv2 Key Exchange Payload contains a		The Key Exchange Data field of IKEv2 Key Exchange Payload contains a
	single format, which is a blob that is only meaningful to the		single format, which is a blob that is only meaningful to the
	specified key exchange method. In order to support hash and URL		specified key exchange method. In order to support hash and URL
	data, an encoding format needs to be specified on the header.		data, an encoding format needs to be specified on the header.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C|F| RESERVED | Payload Length |		| Next Payload |C|F| RESERVED | Payload Length |
	skipping to change at page 5, line 31 ¶		skipping to change at page 12, line 19 ¶
	[FIPS-202] of the replaced value truncated to 20 octets and the URL		[FIPS-202] of the replaced value truncated to 20 octets and the URL
	value is a variable length URL (in either http or https schema) that		value is a variable length URL (in either http or https schema) that
	resolves to the DER-encoded of the replaced value itself.		resolves to the DER-encoded of the replaced value itself.
	Because the hash and URL value is transported in a Key Exchange		Because the hash and URL value is transported in a Key Exchange
	Payload, it is possible to support the use-case of a single post-		Payload, it is possible to support the use-case of a single post-
	quantum key-establishment with large public-key. This payload will		quantum key-establishment with large public-key. This payload will
	be sent as part of IKE_SA_INIT exchange and it will not require		be sent as part of IKE_SA_INIT exchange and it will not require
	IKE_INTERMEDIATE exchanges.		IKE_INTERMEDIATE exchanges.
	2.1.2. Certificate Payload		While using hash and URL method to transport large key-establishment
			data requires minimal modification to IKEv2 protocol, there are
			disadvantages from deployment point of view that may make this method
			impractical. Firstly, an IKE peer that originates a hash and URL
			value will also need to implement additional infrastructure so that
			it can serve HTTP requests in order to allow the actual key-
			establishment data to be fetched. While this may not be an issue for
			Internet facing peers, in the context of road-warrior or remote-
			access cases, the hash and URL value is initiated by an IKE peer that
			is usually a device sitting behind a network address translation
			(NAT) device and as such, it may not be able to run a publicly
			reachable HTTP server infrastructure on the same device. An possible
			solution for these cases is to publish the key-establishment data to
			a separate server, which is not practical as one cannot expect an IKE
			initiator to always have deployed an HTTP server. Lastly, IKE peers
			are predominantly deployed at the network edge where strict firewall
			rules are generally enforced. The need to open up another port to
			serve HTTP requests may cause either technical or policy complication
			that render this approach unacceptable.
			The hash and URL approach is vulnerable to (distributed) denial of
			service attacks as an unauthenticated rogue peer may trick a
			legitimate peer to fetch a large amount of random meaningless data
			from a remote server. Implementations SHOULD NOT blindly download
			all of the data in the given URL. Because a legitimate key-
			establishment payload should be DER-encoded, they SHOULD download the
			first few octets to determine the length of the ASN.1 structure
			representing these octets, then only continue to download the
			remaining decoded number of octets if the length is expected for the
			chosen key-establishment algorithm. It should be noted that the
			content of the data to be downloaded may be under attacker's control
			and therefore even if the length is as expected, the content may be
			meaningless bit that is of no use for key-establishment.
			A.1.2. Certificate Payload
	An alternative is to re-purpose Certificate Payload to carry the hash		An alternative is to re-purpose Certificate Payload to carry the hash
	and URL value of the post-quantum key-establishment data. At the		and URL value of the post-quantum key-establishment data. At the
	time of writing, the IANA registry defines two hash and URL encoding		time of writing, the IANA registry defines two hash and URL encoding
	values, namely X.509 certificate and X.509 certificate bundle. In		values, namely X.509 certificate and X.509 certificate bundle. In
	order to use this payload, a new encoding value for key establishment		order to use this payload, a new encoding value for key establishment
	data will be required.		data will be required.
	Because a Certificate Payload is part of IKE_AUTH message, unlike the		Because a Certificate Payload is part of IKE_AUTH message, unlike the
	previous approach, the hash and URL value of the key-establishment		previous approach, the hash and URL value of the key-establishment
	data shall be transported via IKE_INTERMEDIATE message. As such, it		data shall be transported via IKE_INTERMEDIATE message. As such, it
	will not be able to support a single post-quantum key-establishment		will not be able to support a single post-quantum key-establishment
	with a large public-key case. Furthermore, it is semantically		with a large public-key case. Furthermore, it is semantically
	incorrect to repurpose Certificate Payload, which is intended to		incorrect to re-purpose Certificate Payload, which is intended to
	carry authentication data, to transport key-establishment data.		carry authentication data, to transport key-establishment data.
	2.2. Payload Fragmentation		A.2. Incremental Transfer and Confirmation
	As mentioned earlier, IKEv2 support for fragmentation as specified in
	[RFC7383] allows IKE messages up to 64KB to be broken down into
	smaller fragments. While the size of IKE payloads is constrained to
	a 16-bit field, an IKE message itself has a 32-bit length field and
	therefore, in order to support payloads larger than 64KB limit, a
	fragmentation needs to be carried out at an upper level. In this
	case, the large key-establishment data is first fragmented into a
	number of payload fragments that are no bigger than 64KB and each of
	which is subjected to further fragmentation using IKEv2 standard
	message fragmentation when transported in IKE_INTERMEDIATE messages.
	There are two possible ways to perform large payload fragmentation,
	as discussed below.
	2.2.1. Bulk Transfer and Confirmation
	The large key-establishment payload is first split into a sequence of
	Key Exchange payload chunks where each share the same value of Key
	Exchange Method value and has no more than 64KB in size. This
	sequence of payload chunks is encrypted and is treated as an
	Encrypted and Authenticated payload as per Section 3.14 of [RFC7296],
	which is then sent over an IKE_INTERMEDIATE message.
	Initiator Responder
	-------------------------------------------------------------------
	HDR, SAi1, KEi1, Ni,
	N(IKEV2_FRAGMENTATION_SUPPORTED)*,
	N(INTERMEDIATE_EXCHANGE_SUPPORTED) --->
	HDR, SAr1, KEr1, Nr,
	N(IKEV2_FRAGMENTATION_SUPPORTED)*,
	<--- N(INTERMEDIATE_EXCHANGE_SUPPORTED)
	HDR, SK{KEi2.1, KEi2.2, KEi2.3, ...} --->
	<--- HDR, SK{KEr2, ...}
	*: optional
	While the IKE header (HDR) has a 32-bit field to denote the length of
	its message, that for Encrypted payload header (SK) is capped at
	16-bit, which is not long enough. As a consequence, the payload
	length field of the Encrypted Payload SHALL be set to 0. Because the
	Encrypted payload is always the last payload in an IKE message, it is
	possible to compute the encrypted IKE payload length instead of
	relying on the information in its payload length field.
	When IKEv2 standard message fragmentation is used, each of the Key
	Exchange payload chunk is subjected to further fragmentation as per
	[RFC7383].
	2.2.2. Incremental Transfer and Confirmation
	As stated in Section 4 of [RFC7383], if any single fragment is lost,		As stated in Section 4 of [RFC7383], if any single fragment is lost,
	the receiving peer will not be able to reassemble the original large		the receiving peer will not be able to reassemble the original large
	key-establishment payload. The above bulk transfer is susceptible to		key-establishment payload. The above bulk transfer is susceptible to
	this issue. There is another way to transfer these payload chunks		this issue. There is another way to transfer these payload chunks
	that is less susceptible to this, but at the cost of higher latency.		that is less susceptible to this, but at the cost of higher latency.
	Instead of transferring in a bulk, each Key Exchange payload chunk		Instead of transferring in a bulk, each Key Exchange payload chunk
	must be acknowledged prior to sending the subsequent chunk. As		must be acknowledged prior to sending the subsequent chunk. As
	before, the large key-establishment payload is split over several Key		before, the large key-establishment payload is split over several Key
	Exchange payload chunks where each of them share the same Key		Exchange payload chunks where each of them share the same Key
	Exchange Method value. Each chunk is then sent to the peer using the		Exchange Method value. Each chunk is then sent to the peer using the
	IKE_INTERMEDIATE message, and each one must be acknowledged by the		IKE_INTERMEDIATE message, and each one must be acknowledged by the
	receiving peer before the subsequent chunk can be sent.		receiving peer before the subsequent chunk can be sent.
	Initiator Responder		Initiator Responder
	-------------------------------------------------------------------		-------------------------------------------------------------------
	HDR, SAi1, KEi1, Ni,		HDR, SAi1, KEi1, Ni,
	N(IKEV2_FRAGMENTATION_SUPPORTED)*,		N(IKEV2_FRAGMENTATION_SUPPORTED)*,
	N(INTERMEDIATE_EXCHANGE_SUPPORTED) --->		N(INTERMEDIATE_EXCHANGE_SUPPORTED) --->
	HDR, SAr1, KEr1, Nr,		HDR, SAr1, KEr1, Nr,
	N(IKEV2_FRAGMENTATION_SUPPORTED)*,		N(IKEV2_FRAGMENTATION_SUPPORTED)*,
	<--- N(INTERMEDIATE_EXCHANGE_SUPPORTED)		<--- N(INTERMEDIATE_EXCHANGE_SUPPORTED)
	HDR, SK{KEi2.1, ...} --->		HDR, SK{KEi2.1, ...} --->
	<--- HDR, SK{}		<--- HDR, SK{}
	HDR, SK{KEi2.2, ...} --->		HDR, SK{KEi2.2, ...} --->
	<--- HDR, SK{}		<--- HDR, SK{}
	HDR, SK{KEi2.3, ...} --->		HDR, SK{KEi2.3, ...} --->
	<--- HDR, SK{KEr2, ...}		<--- HDR, SK{KEr2, ...}
	HDR, SK{} --->		HDR, SK{} --->
	*: optional		*: optional
	In order to support key-encapsulation mechanism, the receiving peer		In order to support key-encapsulation mechanism, the receiving peer
	has to wait until the entire chunks are received before it can		has to wait until the entire chunks are received before it can
	respond with its own Key Exchange payload, which may not be large.		respond with its own Key Exchange payload, which may not be large.
	While the description above focuses on the transfer of Key Exchange
	payload larger than 64KB, the same approach can be used to transfer
	large public-key, certificate or signature if there is a need to
	support hybrid authentication or even multiple certificates with
	large constituent component.
	3. Operational Considerations
	While using hash and URL method to transport large key-establishment
	data requires minimal modification to IKEv2 protocol, there are
	disadvantages from deployment point of view that may make this method
	impractical. Firstly, an IKE peer that originates a hash and URL
	value will also need to implement additional infrastructure so that
	it can serve HTTP requests in order to allow the actual key-
	establishment data to be fetched. While this may not be an issue for
	Internet facing peers, in the context of road-warrior or remote-
	access cases, the hash and URL value is initiated by an IKE peer that
	is usually a device sitting behind a network address translation
	(NAT) device and as such, it may not be able to run a publicly
	reachable HTTP server infrastructure on the same device. An possible
	solution for these cases is to publish the key-establishment data to
	a separate server, which is not practical as one cannot expect an IKE
	initiator to always have deployed an HTTP server. Lastly, IKE peers
	are predominantly deployed at the network edge where strict firewall
	rules are generally enforced. The need to open up another port to
	serve HTTP requests may cause either technical or policy complication
	that render this approach unacceptable.
	Unlike the aforementioned hash and URL method, the payload
	fragmentation method does not require additional infrastructure,
	however, there is non-zero probability of lost packets when sending a
	large number of fragments over a UDP connection. Given a set of
	fragments, when transmitted, each one of them is not individually
	acknowledged and if any one of them is lost, the entire set will have
	to be retransmitted. As a consequence, given the size of the payload
	and also the potential of multiple retransmissions, there may be a
	noticeable delay in establishing an security association (SA), in
	particular in lossy network conditions. Therefore, implementations
	MAY use a longer timeout value for the purpose of dead-peer
	detection, but a balance needs to be struck as too large of a value
	will open up security vulnerabilities as discussed in the following
	section. In the unlikely event where there is a frequent
	retransmission due to loss of fragments, implementations MAY send the
	IKE messages over a TCP connection as specified in [RFC8229]. In
	this instance, the peers SHOULD NOT advertise support for IKE
	fragmentation as this is already handled inherently by the TCP
	stream.
	4. Security Considerations
	The hash and URL approach is vulnerable to (distributed) denial of
	service attacks as an unauthenticated rogue peer may trick a
	legitimate peer to fetch a large amount of random meaningless data
	from a remote server. Implementations SHOULD NOT blindly download
	all of the data in the given URL. Because a legitimate key-
	establishment payload should be DER-encoded, they SHOULD download the
	first few octets to determine the length of the ASN.1 structure
	representing these octets, then only continue to download the
	remaining decoded number of octets if the length is expected for the
	chosen key-establishment algorithm. It should be noted that the
	content of the data to be downloaded may be under attacker's control
	and therefore even if the length is as expected, the content may be
	meaningless bit that is of no use for key-establishment.
	There is no exception to the payload fragmentation method, it is also
	vulnerable to the same attack vectors. Malicious peers may send a
	large number of fragments, but incomplete, to the legitimate peer
	causing memory exhaustion.
	In order to counter these attacks, downloading or accepting the
	transfer of a large number of octets SHOULD only be carried out when
	the peer has been authenticated. In other words, key-establishment
	using large data should not be done to establish an IKE SA, but it
	should only be used to establish Child SA or rekeying of IKE SA from
	Child SA. If, for whatever reason, an IKE SA has to be established
	using the large key-establishment data, then it is RECOMMENDED that
	the strategies and recommendations described in [RFC8019] be
	implemented.
	If TCP encapsulation is used, refer to the security considerations in
	[RFC8229].
	Lastly, downloading or transferring large amounts of data is an
	expensive operation, bandwidth and memory wise. Consequently,
	implementations should consider using a longer rekeying interval or
	SHOULD consider relaxing forward secrecy requirements but using CCA-
	secure key-establishment algorithm only. With chosen-ciphertext
	attack (CCA)-secure schemes, there is no loss in security if the
	public-key is reused.
	5. References
	5.1. Normative References
	[I-D.ietf-ipsecme-ikev2-intermediate]
	Smyslov, V., "Intermediate Exchange in the IKEv2
	Protocol", draft-ietf-ipsecme-ikev2-intermediate-05 (work
	in progress), September 2020.
	[I-D.ietf-ipsecme-ikev2-multiple-ke]
	Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S.,
	Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
	Key Exchanges in IKEv2", draft-ietf-ipsecme-ikev2-
	multiple-ke-01 (work in progress), July 2020.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
	2014, <https://www.rfc-editor.org/info/rfc7296>.
	[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
	(IKEv2) Message Fragmentation", RFC 7383,
	DOI 10.17487/RFC7383, November 2014,
	<https://www.rfc-editor.org/info/rfc7383>.
	5.2. Informative References
	[BSI] Federal Office for Information Security, "Cryptographic
	Mechanisms: Recommendations and Key Lengths", 2020, <https
	://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publication
	s/TechGuidelines/TG02102/BSI-TR-02102-1.pdf>.
	[CM] Classic McEliece submission team, "Classic McEliece: NIST
	post-quantum cryptography standardization finalist", 2020,
	<https://classic.mceliece.org/>.
	[FIPS-202]
	National Institute of Standards and Technology, "SHA-3
	Standard: Permutation-Based Hash and Extendable-Output
	Functions", 2015, <https://doi.org/10.6028/NIST.FIPS.202>.
	[McEliece]
	McEliece, R., "A Public-key Cryptosystem based on
	Algebraic Coding Theory", DSN Progress Report 42-44,
	1978.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange
	Protocol Version 2 (IKEv2) Implementations from
	Distributed Denial-of-Service Attacks", RFC 8019,
	DOI 10.17487/RFC8019, November 2016,
	<https://www.rfc-editor.org/info/rfc8019>.
	[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
	of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
	August 2017, <https://www.rfc-editor.org/info/rfc8229>.
	Authors' Addresses		Authors' Addresses
	CJ Tjhai		CJ Tjhai
	Post-Quantum		Post-Quantum
	UK		UK
	Email: cjt@post-quantum.com		Email: cjt@post-quantum.com
	Tobias Heider		Tobias Heider
	genua GmbH		genua GmbH
End of changes. 25 change blocks.
	272 lines changed or deleted		428 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/