< draft-ietf-ipsecme-qr-ikev2-05.txt		draft-ietf-ipsecme-qr-ikev2-06.txt >
	Internet Engineering Task Force S. Fluhrer		Internet Engineering Task Force S. Fluhrer
	Internet-Draft D. McGrew		Internet-Draft D. McGrew
	Intended status: Standards Track P. Kampanakis		Intended status: Standards Track P. Kampanakis
	Expires: June 28, 2019 Cisco Systems		Expires: July 22, 2019 Cisco Systems
	V. Smyslov		V. Smyslov
	ELVIS-PLUS		ELVIS-PLUS
	December 25, 2018		January 18, 2019
	Postquantum Preshared Keys for IKEv2		Postquantum Preshared Keys for IKEv2
	draft-ietf-ipsecme-qr-ikev2-05		draft-ietf-ipsecme-qr-ikev2-06
	Abstract		Abstract
	The possibility of Quantum Computers pose a serious challenge to		The possibility of Quantum Computers pose a serious challenge to
	cryptography algorithms deployed widely today. IKEv2 is one example		cryptography algorithms deployed widely today. IKEv2 is one example
	of a cryptosystem that could be broken; someone storing VPN		of a cryptosystem that could be broken; someone storing VPN
	communications today could decrypt them at a later time when a		communications today could decrypt them at a later time when a
	Quantum Computer is available. It is anticipated that IKEv2 will be		Quantum Computer is available. It is anticipated that IKEv2 will be
	extended to support quantum secure key exchange algorithms; however		extended to support quantum secure key exchange algorithms; however
	that is not likely to happen in the near term. To address this		that is not likely to happen in the near term. To address this
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 28, 2019.		This Internet-Draft will expire on July 22, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 13, line 45 ¶		skipping to change at page 13, line 45 ¶
	effectively halves the size of a symmetric key. Because of this, the		effectively halves the size of a symmetric key. Because of this, the
	user SHOULD ensure that the postquantum preshared key used has at		user SHOULD ensure that the postquantum preshared key used has at
	least 256 bits of entropy, in order to provide 128-bit security		least 256 bits of entropy, in order to provide 128-bit security
	level.		level.
	With this protocol, the computed SK_d is a function of the PPK.		With this protocol, the computed SK_d is a function of the PPK.
	Assuming that the PPK has sufficient entropy (for example, at least		Assuming that the PPK has sufficient entropy (for example, at least
	2^256 possible values), then even if an attacker was able to recover		2^256 possible values), then even if an attacker was able to recover
	the rest of the inputs to the PRF function, it would be infeasible to		the rest of the inputs to the PRF function, it would be infeasible to
	use Grover's algorithm with a Quantum Computer to recover the SK_d		use Grover's algorithm with a Quantum Computer to recover the SK_d
	value. Similarly, every child SA key is a function of SK_d, hence		value. Similarly, all keys that are a function of SK_d, which
	all the keys for all the child SAs are also quantum resistant		include all Child SAs keys and all keys for subsequent IKE SAs
	(assuming that the PPK was of high enough entropy, and that all the		(created when the initial IKE SA is rekeyed), are also quantum
	subkeys are sufficiently long).		resistant (assuming that the PPK was of high enough entropy, and that
			all the subkeys are sufficiently long).
	Although this protocol preserves all the security properties of IKEv2
	against adversaries with conventional computers, it allows an
	adversary with a Quantum Computer to decrypt all traffic encrypted
	with the initial IKE SA. In particular, it allows the adversary to
	recover the identities of both sides. If there is IKE traffic other
	than the identities that need to be protected against such an
	adversary, implementations MAY rekey the initial IKE SA immediately
	after negotiating it to generate a new SKEYSEED from the postquantum
	SK_d. This would reduce the amount of data available to an attacker
	with a Quantum Computer.
	If sensitive information (like keys) is to be transferred over IKE		An attacker with a Quantum Computer that can decrypt the initial IKE
	SA, then implementations MUST rekey the initial IKE SA before sending		SA has access to all the information exchanged over it, such as
	this information to get protection against Quantum Computers.		identities of the peers, configuration parameters and all negotiated
			IPsec SAs information (including traffic selectors), with the
			exception of the cryptographic keys used by the IPsec SAs which are
			protected by the PPK.
	Alternatively, an initial IKE SA (which is used to exchange		Deployments that treat this information as sensitive or that send
	identities) can take place, perhaps by using the protocol documented		other sensitive data (like cryptographic keys) over IKE SA MUST rekey
	in [RFC6023]. After the childless IKE SA is created, implementations		the IKE SA before the sensitive information is sent to ensure this
	would immediately create a new IKE SA (which is used to exchange		information is protected by the PPK. Note that [RFC6023] allows to
	everything else) by using a rekey mechanism for IKE SAs. Because the		skip creating Child SA in the IKE_AUTH exchange, so that the
	rekeyed IKE SA keys are a function of SK_d, which is a function of		supporting peers can rekey the IKE SA before any Child SA is created.
	the PPK (among other things), traffic protected by that IKE SA is		Note also that some information (identities of the peers, feature
	secure against Quantum capable adversaries.		negotiation notifications, Vendor IDs etc.) is always exchanged in
			initial exchanges and thus cannot be protected from the attack
			described above by performing an IKE SA rekey.
	In addition, the policy SHOULD be set to negotiate only quantum-		In addition, the policy SHOULD be set to negotiate only quantum-
	resistant symmetric algorithms; while this RFC doesn't claim to give		resistant symmetric algorithms; while this RFC doesn't claim to give
	advice as to what algorithms are secure (as that may change based on		advice as to what algorithms are secure (as that may change based on
	future cryptographical results), below is a list of defined IKEv2 and		future cryptographical results), below is a list of defined IKEv2 and
	IPsec algorithms that should NOT be used, as they are known not to be		IPsec algorithms that should NOT be used, as they are known not to be
	quantum resistant		quantum resistant
	o Any IKEv2 Encryption algorithm, PRF or Integrity algorithm with		o Any IKEv2 Encryption algorithm, PRF or Integrity algorithm with
	key size less than 256 bits.		key size less than 256 bits.
End of changes. 8 change blocks.
	31 lines changed or deleted		26 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/