--- 1/draft-ietf-ipsecme-ikev2-multiple-ke-01.txt 2021-01-10 01:13:18.855987139 -0800 +++ 2/draft-ietf-ipsecme-ikev2-multiple-ke-02.txt 2021-01-10 01:13:18.943989369 -0800 @@ -1,28 +1,28 @@ Internet Engineering Task Force (IETF) C. Tjhai Internet-Draft M. Tomlinson Updates: 7296 (if approved) Post-Quantum Intended status: Standards Track G. Bartlett -Expires: January 8, 2021 Quantum Secret +Expires: July 14, 2021 Quantum Secret S. Fluhrer Cisco Systems D. Van Geest ISARA Corporation O. Garcia-Morchon Philips V. Smyslov ELVIS-PLUS - July 7, 2020 + January 10, 2021 Multiple Key Exchanges in IKEv2 - draft-ietf-ipsecme-ikev2-multiple-ke-01 + draft-ietf-ipsecme-ikev2-multiple-ke-02 Abstract This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. The primary application of this feature in IKEv2 is the ability to perform one or more post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman key exchange, so that the resulting shared key is resistant against @@ -47,60 +47,60 @@ 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/. 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 8, 2021. + This Internet-Draft will expire on July 14, 2021. Copyright Notice - Copyright (c) 2020 IETF Trust and the persons identified as the + Copyright (c) 2021 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3 1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . 3 1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.4. Document Organization . . . . . . . . . . . . . . . . . . 5 + 1.4. Document Organization . . . . . . . . . . . . . . . . . . 6 2. Design Criteria . . . . . . . . . . . . . . . . . . . . . . . 6 3. Multiple Key Exchanges . . . . . . . . . . . . . . . . . . . 8 3.1. Overall Design . . . . . . . . . . . . . . . . . . . . . 8 - 3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . 9 + 3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . 10 3.2.1. IKE_SA_INIT Round: Negotiation . . . . . . . . . . . 10 3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges . . 11 3.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 12 3.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Alternative Design . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction 1.1. Problem Description Internet Key Exchange Protocol (IKEv2) as specified in [RFC7296] uses the Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) algorithm to establish a shared secret between an initiator and a responder. The security of the DH and ECDH algorithms relies on the difficulty to solve a discrete logarithm problem in multiplicative @@ -163,42 +163,54 @@ to make IKEv2 key exchange quantum secure is to use post-quantum pre- shared keys as discussed in [RFC8784]. Note also, that the proposed approach of performing multiple successive key exchanges in such a way that resulting session keys depend on all of them is not limited to achieving quantum resistance only. It can also be used when all the performed key exchanges are classical (EC)DH ones, where for some reasons (e.g. policy requirements) it is essential to perform multiple of them. + This draft does not attempt to address key exchanges with KE payloads + longer than 64k; the current IKE payload format does not allow that + as a possibility. At the current time, it appears likely that there + are a number of key exchanges available that would not require such a + requirement. However, if such a requirement is needed, + [I-D.tjhai-ikev2-beyond-64k-limit] discusses approaches that should + be taken to exchange huge payloads. + 1.3. Changes RFC EDITOR PLEASE DELETE THIS SECTION. Changes in this draft in each version iterations. + draft-ietf-ipsecme-ikev2-multiple-ke-02 + + o Added a reference on the handling of KE payloads larger than 64KB. + draft-ietf-ipsecme-ikev2-multiple-ke-01 o References are updated. - draft-ietf-ipsecme-ikev2-multiple-ke-00 - o Draft name changed as result of WG adoption and generalization of the approach. o New exchange IKE_FOLLOWUP_KE is defined for additional key exchanges performed after CREATE_CHILD_SA. o Nonces are removed from all additional key exchanges. o Clarification that IKE_INTERMEDIATE must be negotiated is added. + draft-tjhai-ipsecme-hybrid-qske-ikev2-04 + o Clarification about key derivation in case of multiple key exchanges in CREATE_CHILD_SA is added. o Resolving rekey collisions in case of multiple key exchanges is clarified. draft-tjhai-ipsecme-hybrid-qske-ikev2-03 o Using multiple key exchanges CREATE_CHILD_SA is defined. @@ -774,44 +787,36 @@ provide resistance to attacks mounted in the future. The current threat is that encrypted sessions are subject to eavesdropping and archived with decryption by quantum computers taking place at some point in the future. Until quantum computers become available there is no point in attacking the authenticity of a connection because there are no possibilities for exploitation. These only occur at the time of the connection, for example by mounting a man-in-the-middle (MitM) attack. Consequently there is not such a pressing need for quantum-safe authenticity. - This draft does not attempt to address key exchanges with KE payloads - longer than 64k; the current IKE payload format does not allow that - as a possibility. If such huge KE payloads are required, a work - around (such as making the KE payload a URL and a hash of the real - payload) would be needed. At the current time, it appears likely - that there will be plenty of key exchanges available that would not - require such a workaround. - 6. Acknowledgements The authors would like to thanks Frederic Detienne and Olivier Pelerin for their comments and suggestions, including the idea to negotiate the post-quantum algorithms using the existing KE payload. The authors are also grateful to Tobias Heider and Tobias Guggemos for valuable comments. 7. References 7.1. Normative References [I-D.ietf-ipsecme-ikev2-intermediate] Smyslov, V., "Intermediate Exchange in the IKEv2 - Protocol", draft-ietf-ipsecme-ikev2-intermediate-04 (work - in progress), June 2020. + Protocol", draft-ietf-ipsecme-ikev2-intermediate-05 (work + in progress), September 2020. [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, . @@ -819,20 +824,25 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for Database Search", Proc. of the Twenty-Eighth Annual ACM Symposium on the Theory of Computing (STOC 1996), 1996. + [I-D.tjhai-ikev2-beyond-64k-limit] + Tjhai, C., Heider, T., and V. Smyslov, "Beyond 64KB Limit + of IKEv2 Payload", draft-tjhai-ikev2-beyond-64k-limit-00 + (work in progress), October 2020. + [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383,