--- 1/draft-ietf-ipsecme-qr-ikev2-07.txt 2019-03-28 06:13:28.882489188 -0700 +++ 2/draft-ietf-ipsecme-qr-ikev2-08.txt 2019-03-28 06:13:28.922490213 -0700 @@ -1,21 +1,21 @@ Internet Engineering Task Force S. Fluhrer Internet-Draft D. McGrew Intended status: Standards Track P. Kampanakis -Expires: July 26, 2019 Cisco Systems +Expires: September 29, 2019 Cisco Systems V. Smyslov ELVIS-PLUS - January 22, 2019 + March 28, 2019 Postquantum Preshared Keys for IKEv2 - draft-ietf-ipsecme-qr-ikev2-07 + draft-ietf-ipsecme-qr-ikev2-08 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 26, 2019. + This Internet-Draft will expire on September 29, 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 @@ -220,31 +220,31 @@ o We have the server specify the PPK Indicator Input, which allows the server to make a trade-off between the efficiency for the search of the clients PPK, and the anonymity of the client. o We now use the negotiated PRF (rather than a fixed HMAC-SHA256) to transform the nonces during the KDF. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. 2. Assumptions We assume that each IKE peer has a list of Postquantum Preshared Keys (PPK) along with their identifiers (PPK_ID), and any potential IKE initiator has a selection of which PPK to use with any specific responder. In addition, implementations have a configurable flag that determines whether this postquantum preshared key is mandatory. - This PPK is independent of the preshared key (if any) that the IKEv2 protocol uses to perform authentication. The PPK specific configuration that is assumed on each peer consists of the following tuple: Peer, PPK, PPK_ID, mandatory_or_not 3. Exchanges If the initiator is configured to use a postquantum preshared key @@ -267,30 +267,31 @@ If the responder does not support this specification or does not have any PPK configured, then she ignores the received notification and continues with the IKEv2 protocol as normal. Otherwise the responder checks if she has a PPK configured, and if she does, then the responder replies with the IKE_SA_INIT message including a USE_PPK notification in the response: Initiator Responder ------------------------------------------------------------------ - <--- HDR, SAr1, KEr, Nr, [CERTREQ], N(USE_PPK) + <--- HDR, SAr1, KEr, Nr, [CERTREQ,] N(USE_PPK) When the initiator receives this reply, he checks whether the responder included the USE_PPK notification. If the responder did not and the flag mandatory_or_not indicates that using PPKs is mandatory for communication with this responder, then the initiator MUST abort the exchange. This situation may happen in case of misconfiguration, when the initiator believes he has a mandatory to use PPK for the responder, while the responder either doesn't support PPKs at all or doesn't have any PPK configured for the initiator. + See Section 6 for discussion of the possible impacts of this situation. If the responder did not include the USE_PPK notification and using a PPK for this particular responder is optional, then the initiator continues with the IKEv2 protocol as normal, without using PPKs. If the responder did include the USE_PPK notification, then the initiator selects a PPK, along with its identifier PPK_ID. Then, she computes this modification of the standard IKEv2 key derivation: @@ -709,58 +710,53 @@ PPK_ID Type Value ----------- ----- Reserved 0 PPK_ID_OPAQUE 1 PPK_ID_FIXED 2 Unassigned 3-127 Reserved for private use 128-255 Changes and additions to this registry are by Expert Review - [RFC5226]. + [RFC8126]. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . 8.2. Informational References [I-D.hoffman-c2pq] Hoffman, P., "The Transition from Classical to Post- - Quantum Cryptography", draft-hoffman-c2pq-03 (work in - progress), February 2018. + Quantum Cryptography", draft-hoffman-c2pq-04 (work in + progress), August 2018. [IKEV2-IANA-PRFS] "Internet Key Exchange Version 2 (IKEv2) Parameters, Transform Type 2 - Pseudorandom Function Transform IDs", . [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, . - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", RFC 5226, - DOI 10.17487/RFC5226, May 2008, . - [RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)", RFC 6023, DOI 10.17487/RFC6023, October 2010, . [RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric Key Container (PSKC)", RFC 6030, DOI 10.17487/RFC6030, October 2010, . @@ -768,20 +764,25 @@ Method in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, . [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, . + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . + Appendix A. Discussion and Rationale The idea behind this document is that while a Quantum Computer can easily reconstruct the shared secret of an (EC)DH exchange, they cannot as easily recover a secret from a symmetric exchange. This makes the SK_d, and hence the IPsec KEYMAT and any child SA's SKEYSEED, depend on both the symmetric PPK, and also the Diffie- Hellman exchange. If we assume that the attacker knows everything except the PPK during the key exchange, and there are 2^n plausible PPKs, then a Quantum Computer (using Grover's algorithm) would take