--- 1/draft-ietf-ipsecme-qr-ikev2-06.txt 2019-01-21 23:13:10.850147335 -0800 +++ 2/draft-ietf-ipsecme-qr-ikev2-07.txt 2019-01-21 23:13:10.890148304 -0800 @@ -1,21 +1,21 @@ Internet Engineering Task Force S. Fluhrer Internet-Draft D. McGrew Intended status: Standards Track P. Kampanakis -Expires: July 22, 2019 Cisco Systems +Expires: July 26, 2019 Cisco Systems V. Smyslov ELVIS-PLUS - January 18, 2019 + January 22, 2019 Postquantum Preshared Keys for IKEv2 - draft-ietf-ipsecme-qr-ikev2-06 + draft-ietf-ipsecme-qr-ikev2-07 Abstract The possibility of Quantum Computers pose a serious challenge to cryptography algorithms deployed widely today. IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a Quantum Computer is available. It is anticipated that IKEv2 will be extended to support quantum secure key exchange algorithms; however that is not likely to happen in the near term. To address this @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 22, 2019. + This Internet-Draft will expire on July 26, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -624,27 +624,28 @@ An attacker with a Quantum Computer that can decrypt the initial IKE SA has access to all the information exchanged over it, such as 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. Deployments that treat this information as sensitive or that send other sensitive data (like cryptographic keys) over IKE SA MUST rekey the IKE SA before the sensitive information is sent to ensure this - information is protected by the PPK. Note that [RFC6023] allows to - skip creating Child SA in the IKE_AUTH exchange, so that the - supporting peers can rekey the IKE SA before any Child SA is created. - Note also that some information (identities of the peers, feature - 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. + information is protected by the PPK. It is possible to create a + childless IKE SA as specified in [RFC6023]. This prevents Child SA + configuration information from being transmited in the original IKE + SA that is not protected by a PPK. Some information related to IKE + SA, that is sent in the IKE_AUTH exchange, such as peer identities, + feature notifications, Vendor ID's etc. cannot be hidden from the + attack described above, even if the additional IKE SA rekey is + performed. In addition, the policy SHOULD be set to negotiate only quantum- resistant symmetric algorithms; while this RFC doesn't claim to give advice as to what algorithms are secure (as that may change based on 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 quantum resistant o Any IKEv2 Encryption algorithm, PRF or Integrity algorithm with key size less than 256 bits.