draft-ietf-ipsecme-qr-ikev2-07.txt   draft-ietf-ipsecme-qr-ikev2-08.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: July 26, 2019 Cisco Systems Expires: September 29, 2019 Cisco Systems
V. Smyslov V. Smyslov
ELVIS-PLUS ELVIS-PLUS
January 22, 2019 March 28, 2019
Postquantum Preshared Keys for IKEv2 Postquantum Preshared Keys for IKEv2
draft-ietf-ipsecme-qr-ikev2-07 draft-ietf-ipsecme-qr-ikev2-08
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 42 skipping to change at page 1, line 42
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 http://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 July 26, 2019. This Internet-Draft will expire on September 29, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(http://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
skipping to change at page 5, line 41 skipping to change at page 5, line 41
o We have the server specify the PPK Indicator Input, which allows o We have the server specify the PPK Indicator Input, which allows
the server to make a trade-off between the efficiency for the the server to make a trade-off between the efficiency for the
search of the clients PPK, and the anonymity of the client. 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 o We now use the negotiated PRF (rather than a fixed HMAC-SHA256) to
transform the nonces during the KDF. transform the nonces during the KDF.
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
2. Assumptions 2. Assumptions
We assume that each IKE peer has a list of Postquantum Preshared Keys We assume that each IKE peer has a list of Postquantum Preshared Keys
(PPK) along with their identifiers (PPK_ID), and any potential IKE (PPK) along with their identifiers (PPK_ID), and any potential IKE
initiator has a selection of which PPK to use with any specific initiator has a selection of which PPK to use with any specific
responder. In addition, implementations have a configurable flag responder. In addition, implementations have a configurable flag
that determines whether this postquantum preshared key is mandatory. that determines whether this postquantum preshared key is mandatory.
This PPK is independent of the preshared key (if any) that the IKEv2 This PPK is independent of the preshared key (if any) that the IKEv2
protocol uses to perform authentication. The PPK specific protocol uses to perform authentication. The PPK specific
configuration that is assumed on each peer consists of the following configuration that is assumed on each peer consists of the following
tuple: tuple:
Peer, PPK, PPK_ID, mandatory_or_not Peer, PPK, PPK_ID, mandatory_or_not
3. Exchanges 3. Exchanges
If the initiator is configured to use a postquantum preshared key If the initiator is configured to use a postquantum preshared key
skipping to change at page 6, line 41 skipping to change at page 6, line 41
If the responder does not support this specification or does not have If the responder does not support this specification or does not have
any PPK configured, then she ignores the received notification and any PPK configured, then she ignores the received notification and
continues with the IKEv2 protocol as normal. Otherwise the responder continues with the IKEv2 protocol as normal. Otherwise the responder
checks if she has a PPK configured, and if she does, then the 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 responder replies with the IKE_SA_INIT message including a USE_PPK
notification in the response: notification in the response:
Initiator Responder 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 When the initiator receives this reply, he checks whether the
responder included the USE_PPK notification. If the responder did responder included the USE_PPK notification. If the responder did
not and the flag mandatory_or_not indicates that using PPKs is not and the flag mandatory_or_not indicates that using PPKs is
mandatory for communication with this responder, then the initiator mandatory for communication with this responder, then the initiator
MUST abort the exchange. This situation may happen in case of MUST abort the exchange. This situation may happen in case of
misconfiguration, when the initiator believes he has a mandatory to misconfiguration, when the initiator believes he has a mandatory to
use PPK for the responder, while the responder either doesn't support 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. PPKs at all or doesn't have any PPK configured for the initiator.
See Section 6 for discussion of the possible impacts of this See Section 6 for discussion of the possible impacts of this
situation. situation.
If the responder did not include the USE_PPK notification and using a If the responder did not include the USE_PPK notification and using a
PPK for this particular responder is optional, then the initiator PPK for this particular responder is optional, then the initiator
continues with the IKEv2 protocol as normal, without using PPKs. continues with the IKEv2 protocol as normal, without using PPKs.
If the responder did include the USE_PPK notification, then the If the responder did include the USE_PPK notification, then the
initiator selects a PPK, along with its identifier PPK_ID. Then, she initiator selects a PPK, along with its identifier PPK_ID. Then, she
computes this modification of the standard IKEv2 key derivation: computes this modification of the standard IKEv2 key derivation:
skipping to change at page 15, line 50 skipping to change at page 16, line 6
PPK_ID Type Value PPK_ID Type Value
----------- ----- ----------- -----
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]. [RFC8126].
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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <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-
Quantum Cryptography", draft-hoffman-c2pq-03 (work in Quantum Cryptography", draft-hoffman-c2pq-04 (work in
progress), February 2018. progress), August 2018.
[IKEV2-IANA-PRFS] [IKEV2-IANA-PRFS]
"Internet Key Exchange Version 2 (IKEv2) Parameters, "Internet Key Exchange Version 2 (IKEv2) Parameters,
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
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
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, <https://www.rfc- DOI 10.17487/RFC6023, October 2010, <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>.
skipping to change at page 17, line 16 skipping to change at page 17, line 11
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, <https://www.rfc- DOI 10.17487/RFC8019, November 2016, <https://www.rfc-
editor.org/info/rfc8019>. editor.org/info/rfc8019>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
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
PPKs, then a Quantum Computer (using Grover's algorithm) would take PPKs, then a Quantum Computer (using Grover's algorithm) would take
 End of changes. 12 change blocks. 
16 lines changed or deleted 17 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/