--- 1/draft-ietf-ipsecme-qr-ikev2-03.txt 2018-07-02 07:17:46.616672159 -0700 +++ 2/draft-ietf-ipsecme-qr-ikev2-04.txt 2018-07-02 07:17:46.844677620 -0700 @@ -1,21 +1,21 @@ Internet Engineering Task Force S. Fluhrer Internet-Draft D. McGrew Intended status: Standards Track P. Kampanakis -Expires: December 20, 2018 Cisco Systems +Expires: January 3, 2019 Cisco Systems V. Smyslov ELVIS-PLUS - June 18, 2018 + July 2, 2018 Postquantum Preshared Keys for IKEv2 - draft-ietf-ipsecme-qr-ikev2-03 + draft-ietf-ipsecme-qr-ikev2-04 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 @@ -24,37 +24,37 @@ keys. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 https://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 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 December 20, 2018. + This Internet-Draft will expire on January 3, 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 - (https://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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 @@ -64,25 +64,25 @@ 3. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Upgrade procedure . . . . . . . . . . . . . . . . . . . . . . 10 5. PPK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. PPK_ID format . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Operational Considerations . . . . . . . . . . . . . . . 12 5.2.1. PPK Distribution . . . . . . . . . . . . . . . . . . 12 5.2.2. Group PPK . . . . . . . . . . . . . . . . . . . . . . 12 5.2.3. PPK-only Authentication . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.2. Informational References . . . . . . . . . . . . . . . . 16 Appendix A. Discussion and Rationale . . . . . . . . . . . . . . 17 - Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 + Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction It is an open question whether or not it is feasible to build a Quantum Computer (and if so, when one might be implemented), but if it is, many of the cryptographic algorithms and protocols currently in use would be insecure. A Quantum Computer would be able to solve DH and ECDH problems in polynomial time [I-D.hoffman-c2pq], and this would imply that the security of existing IKEv2 [RFC7296] systems @@ -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-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. draft-ietf-ipsecme-qr-ikev2-02 o Added note that the PPK is stirred in the initial IKE SA setup only. @@ -131,24 +135,26 @@ draft-ietf-ipsecme-qr-ikev2-02 o Added note that the PPK is stirred in the initial IKE SA setup only. o Added note about the initiator ignoring any content in the PPK_IDENTITY notification from the responder. o fixed Tero's suggestions from 2/6/1028 - o Added IANA assigned message types where necessary. o fixed minor text nits + + draft-ietf-ipsecme-qr-ikev2-01 + o Nits and minor fixes. o prf is replaced with prf+ for the SK_d and SK_pi/r calculations. o Clarified using PPK in case of EAP authentication. o PPK_SUPPORT notification is changed to USE_PPK to better reflect its purpose. draft-ietf-ipsecme-qr-ikev2-00 @@ -550,32 +556,34 @@ ("Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin") as the PIN. 5.2.2. Group PPK This document doesn't explicitly require that PPK is unique for each pair of peers. If it is the case, then this solution provides full peer authentication, but it also means that each host must have as many independent PPKs as the peers it is going to communicate with. As the number of peers grows the PPKs will not scale. - Even though it is NOT RECOMMENDED, it is possible to use a single PPK - for a group of users. Since each peer uses classical public key - cryptography in addition to PPK for key exchange and authentication, - members of the group can neither impersonate each other nor read - other's traffic, unless they use Quantum Computers to break public - key operations. + It is possible to use a single PPK for a group of users. Since each + peer uses classical public key cryptography in addition to PPK for + key exchange and authentication, members of the group can neither + impersonate each other nor read other's traffic, unless they use + Quantum Computers to break public key operations. However group + members can record other members' traffic and decrypt it later, when + they get access to a Quantum Computer. - Although it's probably safe to use group PPK, the fact that the PPK - is known to a (potentially large) group of users makes it more - susceptible to theft. If an attacker equipped with a Quantum - Computer got access to a group PPK, then all communications inside - the group are revealed. + In addition, the fact that the PPK is known to a (potentially large) + group of users makes it more susceptible to theft. When an attacker + equipped with a Quantum Computer got access to a group PPK, all + communications inside the group are revealed. + + For these reasons using group PPK is NOT RECOMMENDED. 5.2.3. PPK-only Authentication If Quantum Computers become a reality, classical public key cryptography will provide little security, so administrators may find it attractive not to use it at all for authentication. This will reduce the number of credentials they need to maintain to PPKs only. Combining group PPK and PPK-only authentication is NOT RECOMMENDED, since in this case any member of the group can impersonate any other member even without help of Quantum Computers. @@ -704,26 +712,27 @@ 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]. 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, - . + 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- @@ -735,43 +744,43 @@ 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, - . + 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, - . + 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, . [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 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, - . + DOI 10.17487/RFC8019, November 2016, . 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 @@ -797,22 +806,22 @@ shared key, or quantum resistant IKEv2 is rolled out incrementally. This is why we specifically try to allow the PPK to be dependent on the peer, and why we allow the PPK to be configured as optional. A fourth goal was to avoid violating any of the security goals of IKEv2. Appendix B. Acknowledgements We would like to thank Tero Kivinen, Paul Wouters, Graham Bartlett, - Tommy Pauly and the rest of the IPSecME Working Group for their - feedback and suggestions for the scheme. + Tommy Pauly, Quynh Dang and the rest of the IPSecME Working Group for + their feedback and suggestions for the scheme. Authors' Addresses Scott Fluhrer Cisco Systems Email: sfluhrer@cisco.com David McGrew Cisco Systems