--- 1/draft-ietf-ipsecme-qr-ikev2-04.txt 2018-12-25 08:13:16.007225435 -0800 +++ 2/draft-ietf-ipsecme-qr-ikev2-05.txt 2018-12-25 08:13:16.051226495 -0800 @@ -1,21 +1,21 @@ Internet Engineering Task Force S. Fluhrer Internet-Draft D. McGrew Intended status: Standards Track P. Kampanakis -Expires: January 3, 2019 Cisco Systems +Expires: June 28, 2019 Cisco Systems V. Smyslov ELVIS-PLUS - July 2, 2018 + December 25, 2018 Postquantum Preshared Keys for IKEv2 - draft-ietf-ipsecme-qr-ikev2-04 + draft-ietf-ipsecme-qr-ikev2-05 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 January 3, 2019. + This Internet-Draft will expire on June 28, 2019. Copyright Notice Copyright (c) 2018 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 @@ -116,20 +116,24 @@ authentication if configured). This document does not replace the authentication checks that the protocol does; instead, it is done as a parallel check. 1.1. Changes RFC EDITOR PLEASE DELETE THIS SECTION. Changes in this draft in each version iterations. + draft-ietf-ipsecme-qr-ikev2-05 + + o Addressed comments received during WGLC. + draft-ietf-ipsecme-qr-ikev2-04 o Using Group PPK is clarified based on comment from Quynh Dang. draft-ietf-ipsecme-qr-ikev2-03 o Editorial changes and minor text nit fixes. o Integrated Tommy P. text suggestions. @@ -179,22 +184,20 @@ o Expanded Security Considerations section to describe some security concerns and how they should be addressed. draft-fluhrer-qr-ikev2-03 o Modified how we stir the PPK into the IKEv2 secret state. o Modified how the use of PPKs is negotiated. - draft-fluhrer-qr-ikev2-02 - o Simplified the protocol by stirring in the preshared key into the child SAs; this avoids the problem of having the responder decide which preshared key to use (as it knows the initiator identity at that point); it does mean that someone with a Quantum Computer can recover the initial IKE negotiation. o Removed positive endorsements of various algorithms. Retained warnings about algorithms known to be weak against a Quantum Computer. @@ -378,23 +382,23 @@ negotiation. Otherwise (when PPK is optional and the initiator included NO_PPK_AUTH notification) the responder MAY continue regular IKEv2 protocol, except that she uses the data from the NO_PPK_AUTH notification as the authentication data (which usually resides in the AUTH payload), for the purpose of the initiator authentication. Note, that Authentication Method is still indicated in the AUTH payload. This table summarizes the above logic for the responder: - Received Received Have PPK - USE_PPK NO_PPK_AUTH PPK Mandatory Action - ----------------------------------------------------------------- + Received Received Configured PPK is + USE_PPK NO_PPK_AUTH with PPK Mandatory Action + --------------------------------------------------------------------- No * No * Standard IKEv2 protocol No * Yes No Standard IKEv2 protocol No * Yes Yes Abort negotiation Yes No No * Abort negotiation Yes Yes No Yes Abort negotiation Yes Yes No No Standard IKEv2 protocol Yes * Yes * Use PPK If PPK is in use, then the responder extracts the corresponding PPK and computes the following values: @@ -486,21 +490,21 @@ that we will not use a PPK). If the responder has not been upgraded, she will not send the USE_PPK notify (and so the initiator will know to not use a PPK). If both peers have been upgraded, but the responder isn't yet configured with the PPK for the initiator, then the responder could do standard IKEv2 protocol if the initiator sent NO_PPK_AUTH notification. If both the responder and initiator have been upgraded and properly configured, they will both realize it, and in that case, the link will be quantum secure. As an optional second step, after all nodes have been upgraded, then - the administrator may then go back through the nodes, and mark the + the administrator should then go back through the nodes, and mark the use of PPK as mandatory. This will not affect the strength against a passive attacker; it would mean that an attacker with a Quantum Computer (which is sufficiently fast to be able to break the (EC)DH in real time) would not be able to perform a downgrade attack. 5. PPK 5.1. PPK_ID format This standard requires that both the initiator and the responder have