draft-ietf-ipsecme-qr-ikev2-03.txt   draft-ietf-ipsecme-qr-ikev2-04.txt 
Internet Engineering Task Force S. Fluhrer Internet Engineering Task Force S. Fluhrer
Internet-Draft D. McGrew Internet-Draft D. McGrew
Intended status: Standards Track P. Kampanakis Intended status: Standards Track P. Kampanakis
Expires: December 20, 2018 Cisco Systems Expires: January 3, 2019 Cisco Systems
V. Smyslov V. Smyslov
ELVIS-PLUS ELVIS-PLUS
June 18, 2018 July 2, 2018
Postquantum Preshared Keys for IKEv2 Postquantum Preshared Keys for IKEv2
draft-ietf-ipsecme-qr-ikev2-03 draft-ietf-ipsecme-qr-ikev2-04
Abstract Abstract
The possibility of Quantum Computers pose a serious challenge to The possibility of Quantum Computers pose a serious challenge to
cryptography algorithms deployed widely today. IKEv2 is one example cryptography algorithms deployed widely today. IKEv2 is one example
of a cryptosystem that could be broken; someone storing VPN of a cryptosystem that could be broken; someone storing VPN
communications today could decrypt them at a later time when a communications today could decrypt them at a later time when a
Quantum Computer is available. It is anticipated that IKEv2 will be Quantum Computer is available. It is anticipated that IKEv2 will be
extended to support quantum secure key exchange algorithms; however extended to support quantum secure key exchange algorithms; however
that is not likely to happen in the near term. To address this that is not likely to happen in the near term. To address this
skipping to change at page 1, line 35 skipping to change at page 1, line 35
keys. keys.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- 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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents 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 publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 2, line 31 skipping to change at page 2, line 31
3. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Upgrade procedure . . . . . . . . . . . . . . . . . . . . . . 10 4. Upgrade procedure . . . . . . . . . . . . . . . . . . . . . . 10
5. PPK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. PPK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. PPK_ID format . . . . . . . . . . . . . . . . . . . . . . 11 5.1. PPK_ID format . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Operational Considerations . . . . . . . . . . . . . . . 12 5.2. Operational Considerations . . . . . . . . . . . . . . . 12
5.2.1. PPK Distribution . . . . . . . . . . . . . . . . . . 12 5.2.1. PPK Distribution . . . . . . . . . . . . . . . . . . 12
5.2.2. Group PPK . . . . . . . . . . . . . . . . . . . . . . 12 5.2.2. Group PPK . . . . . . . . . . . . . . . . . . . . . . 12
5.2.3. PPK-only Authentication . . . . . . . . . . . . . . . 13 5.2.3. PPK-only Authentication . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informational References . . . . . . . . . . . . . . . . 16 8.2. Informational References . . . . . . . . . . . . . . . . 16
Appendix A. Discussion and Rationale . . . . . . . . . . . . . . 17 Appendix A. Discussion and Rationale . . . . . . . . . . . . . . 17
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
It is an open question whether or not it is feasible to build a 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 Quantum Computer (and if so, when one might be implemented), but if
it is, many of the cryptographic algorithms and protocols currently it is, many of the cryptographic algorithms and protocols currently
in use would be insecure. A Quantum Computer would be able to solve 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 DH and ECDH problems in polynomial time [I-D.hoffman-c2pq], and this
would imply that the security of existing IKEv2 [RFC7296] systems would imply that the security of existing IKEv2 [RFC7296] systems
skipping to change at page 3, line 34 skipping to change at page 3, line 34
authentication if configured). This document does not replace the authentication if configured). This document does not replace the
authentication checks that the protocol does; instead, it is done as authentication checks that the protocol does; instead, it is done as
a parallel check. a parallel check.
1.1. Changes 1.1. Changes
RFC EDITOR PLEASE DELETE THIS SECTION. RFC EDITOR PLEASE DELETE THIS SECTION.
Changes in this draft in each version iterations. 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 draft-ietf-ipsecme-qr-ikev2-03
o Editorial changes and minor text nit fixes. o Editorial changes and minor text nit fixes.
o Integrated Tommy P. text suggestions. o Integrated Tommy P. text suggestions.
draft-ietf-ipsecme-qr-ikev2-02 draft-ietf-ipsecme-qr-ikev2-02
o Added note that the PPK is stirred in the initial IKE SA setup o Added note that the PPK is stirred in the initial IKE SA setup
only. only.
skipping to change at page 3, line 49 skipping to change at page 4, line 4
draft-ietf-ipsecme-qr-ikev2-02 draft-ietf-ipsecme-qr-ikev2-02
o Added note that the PPK is stirred in the initial IKE SA setup o Added note that the PPK is stirred in the initial IKE SA setup
only. only.
o Added note about the initiator ignoring any content in the o Added note about the initiator ignoring any content in the
PPK_IDENTITY notification from the responder. PPK_IDENTITY notification from the responder.
o fixed Tero's suggestions from 2/6/1028 o fixed Tero's suggestions from 2/6/1028
o Added IANA assigned message types where necessary. o Added IANA assigned message types where necessary.
o fixed minor text nits o fixed minor text nits
draft-ietf-ipsecme-qr-ikev2-01
o Nits and minor fixes. o Nits and minor fixes.
o prf is replaced with prf+ for the SK_d and SK_pi/r calculations. 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 Clarified using PPK in case of EAP authentication.
o PPK_SUPPORT notification is changed to USE_PPK to better reflect o PPK_SUPPORT notification is changed to USE_PPK to better reflect
its purpose. its purpose.
draft-ietf-ipsecme-qr-ikev2-00 draft-ietf-ipsecme-qr-ikev2-00
skipping to change at page 12, line 40 skipping to change at page 12, line 40
("Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin") as the PIN. ("Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin") as the PIN.
5.2.2. Group PPK 5.2.2. Group PPK
This document doesn't explicitly require that PPK is unique for each 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 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 peer authentication, but it also means that each host must have as
many independent PPKs as the peers it is going to communicate with. many independent PPKs as the peers it is going to communicate with.
As the number of peers grows the PPKs will not scale. 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 It is possible to use a single PPK for a group of users. Since each
for a group of users. Since each peer uses classical public key peer uses classical public key cryptography in addition to PPK for
cryptography in addition to PPK for key exchange and authentication, key exchange and authentication, members of the group can neither
members of the group can neither impersonate each other nor read impersonate each other nor read other's traffic, unless they use
other's traffic, unless they use Quantum Computers to break public Quantum Computers to break public key operations. However group
key operations. 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 In addition, the fact that the PPK is known to a (potentially large)
is known to a (potentially large) group of users makes it more group of users makes it more susceptible to theft. When an attacker
susceptible to theft. If an attacker equipped with a Quantum equipped with a Quantum Computer got access to a group PPK, all
Computer got access to a group PPK, then all communications inside communications inside the group are revealed.
the group are revealed.
For these reasons using group PPK is NOT RECOMMENDED.
5.2.3. PPK-only Authentication 5.2.3. PPK-only Authentication
If Quantum Computers become a reality, classical public key If Quantum Computers become a reality, classical public key
cryptography will provide little security, so administrators may find cryptography will provide little security, so administrators may find
it attractive not to use it at all for authentication. This will it attractive not to use it at all for authentication. This will
reduce the number of credentials they need to maintain to PPKs only. reduce the number of credentials they need to maintain to PPKs only.
Combining group PPK and PPK-only authentication is NOT RECOMMENDED, Combining group PPK and PPK-only authentication is NOT RECOMMENDED,
since in this case any member of the group can impersonate any other since in this case any member of the group can impersonate any other
member even without help of Quantum Computers. member even without help of Quantum Computers.
skipping to change at page 16, line 4 skipping to change at page 16, line 6
Reserved 0 Reserved 0
PPK_ID_OPAQUE 1 PPK_ID_OPAQUE 1
PPK_ID_FIXED 2 PPK_ID_FIXED 2
Unassigned 3-127 Unassigned 3-127
Reserved for private use 128-255 Reserved for private use 128-255
Changes and additions to this registry are by Expert Review Changes and additions to this registry are by Expert Review
[RFC5226]. [RFC5226].
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
8.2. Informational References 8.2. Informational References
[I-D.hoffman-c2pq] [I-D.hoffman-c2pq]
Hoffman, P., "The Transition from Classical to Post- Hoffman, P., "The Transition from Classical to Post-
skipping to change at page 16, line 35 skipping to change at page 16, line 38
Transform Type 2 - Pseudorandom Function Transform IDs", Transform Type 2 - Pseudorandom Function Transform IDs",
<https://www.iana.org/assignments/ikev2-parameters/ <https://www.iana.org/assignments/ikev2-parameters/
ikev2-parameters.xhtml#ikev2-parameters-6>. ikev2-parameters.xhtml#ikev2-parameters-6>.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998,
<https://www.rfc-editor.org/info/rfc2409>. <https://www.rfc-editor.org/info/rfc2409>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5226>. editor.org/info/rfc5226>.
[RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A [RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A
Childless Initiation of the Internet Key Exchange Version Childless Initiation of the Internet Key Exchange Version
2 (IKEv2) Security Association (SA)", RFC 6023, 2 (IKEv2) Security Association (SA)", RFC 6023,
DOI 10.17487/RFC6023, October 2010, DOI 10.17487/RFC6023, October 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6023>. editor.org/info/rfc6023>.
[RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric [RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
Key Container (PSKC)", RFC 6030, DOI 10.17487/RFC6030, Key Container (PSKC)", RFC 6030, DOI 10.17487/RFC6030,
October 2010, <https://www.rfc-editor.org/info/rfc6030>. October 2010, <https://www.rfc-editor.org/info/rfc6030>.
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
Method in the Internet Key Exchange Protocol Version 2 Method in the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
<https://www.rfc-editor.org/info/rfc7619>. <https://www.rfc-editor.org/info/rfc7619>.
[RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange
Protocol Version 2 (IKEv2) Implementations from Protocol Version 2 (IKEv2) Implementations from
Distributed Denial-of-Service Attacks", RFC 8019, Distributed Denial-of-Service Attacks", RFC 8019,
DOI 10.17487/RFC8019, November 2016, DOI 10.17487/RFC8019, November 2016, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc8019>. editor.org/info/rfc8019>.
Appendix A. Discussion and Rationale Appendix A. Discussion and Rationale
The idea behind this document is that while a Quantum Computer can The idea behind this document is that while a Quantum Computer can
easily reconstruct the shared secret of an (EC)DH exchange, they easily reconstruct the shared secret of an (EC)DH exchange, they
cannot as easily recover a secret from a symmetric exchange. This 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 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- SKEYSEED, depend on both the symmetric PPK, and also the Diffie-
Hellman exchange. If we assume that the attacker knows everything Hellman exchange. If we assume that the attacker knows everything
except the PPK during the key exchange, and there are 2^n plausible except the PPK during the key exchange, and there are 2^n plausible
skipping to change at page 17, line 49 skipping to change at page 18, line 8
shared key, or quantum resistant IKEv2 is rolled out incrementally. shared key, or quantum resistant IKEv2 is rolled out incrementally.
This is why we specifically try to allow the PPK to be dependent on 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. 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 A fourth goal was to avoid violating any of the security goals of
IKEv2. IKEv2.
Appendix B. Acknowledgements Appendix B. Acknowledgements
We would like to thank Tero Kivinen, Paul Wouters, Graham Bartlett, We would like to thank Tero Kivinen, Paul Wouters, Graham Bartlett,
Tommy Pauly and the rest of the IPSecME Working Group for their Tommy Pauly, Quynh Dang and the rest of the IPSecME Working Group for
feedback and suggestions for the scheme. their feedback and suggestions for the scheme.
Authors' Addresses Authors' Addresses
Scott Fluhrer Scott Fluhrer
Cisco Systems Cisco Systems
Email: sfluhrer@cisco.com Email: sfluhrer@cisco.com
David McGrew David McGrew
Cisco Systems Cisco Systems
 End of changes. 19 change blocks. 
30 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/