draft-ietf-ipsecme-qr-ikev2-05.txt   draft-ietf-ipsecme-qr-ikev2-06.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: June 28, 2019 Cisco Systems Expires: July 22, 2019 Cisco Systems
V. Smyslov V. Smyslov
ELVIS-PLUS ELVIS-PLUS
December 25, 2018 January 18, 2019
Postquantum Preshared Keys for IKEv2 Postquantum Preshared Keys for IKEv2
draft-ietf-ipsecme-qr-ikev2-05 draft-ietf-ipsecme-qr-ikev2-06
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 June 28, 2019. This Internet-Draft will expire on July 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
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
skipping to change at page 13, line 45 skipping to change at page 13, line 45
effectively halves the size of a symmetric key. Because of this, the effectively halves the size of a symmetric key. Because of this, the
user SHOULD ensure that the postquantum preshared key used has at user SHOULD ensure that the postquantum preshared key used has at
least 256 bits of entropy, in order to provide 128-bit security least 256 bits of entropy, in order to provide 128-bit security
level. level.
With this protocol, the computed SK_d is a function of the PPK. With this protocol, the computed SK_d is a function of the PPK.
Assuming that the PPK has sufficient entropy (for example, at least Assuming that the PPK has sufficient entropy (for example, at least
2^256 possible values), then even if an attacker was able to recover 2^256 possible values), then even if an attacker was able to recover
the rest of the inputs to the PRF function, it would be infeasible to the rest of the inputs to the PRF function, it would be infeasible to
use Grover's algorithm with a Quantum Computer to recover the SK_d use Grover's algorithm with a Quantum Computer to recover the SK_d
value. Similarly, every child SA key is a function of SK_d, hence value. Similarly, all keys that are a function of SK_d, which
all the keys for all the child SAs are also quantum resistant include all Child SAs keys and all keys for subsequent IKE SAs
(assuming that the PPK was of high enough entropy, and that all the (created when the initial IKE SA is rekeyed), are also quantum
subkeys are sufficiently long). resistant (assuming that the PPK was of high enough entropy, and that
all the subkeys are sufficiently long).
Although this protocol preserves all the security properties of IKEv2
against adversaries with conventional computers, it allows an
adversary with a Quantum Computer to decrypt all traffic encrypted
with the initial IKE SA. In particular, it allows the adversary to
recover the identities of both sides. If there is IKE traffic other
than the identities that need to be protected against such an
adversary, implementations MAY rekey the initial IKE SA immediately
after negotiating it to generate a new SKEYSEED from the postquantum
SK_d. This would reduce the amount of data available to an attacker
with a Quantum Computer.
If sensitive information (like keys) is to be transferred over IKE An attacker with a Quantum Computer that can decrypt the initial IKE
SA, then implementations MUST rekey the initial IKE SA before sending SA has access to all the information exchanged over it, such as
this information to get protection against Quantum Computers. identities of the peers, configuration parameters and all negotiated
IPsec SAs information (including traffic selectors), with the
exception of the cryptographic keys used by the IPsec SAs which are
protected by the PPK.
Alternatively, an initial IKE SA (which is used to exchange Deployments that treat this information as sensitive or that send
identities) can take place, perhaps by using the protocol documented other sensitive data (like cryptographic keys) over IKE SA MUST rekey
in [RFC6023]. After the childless IKE SA is created, implementations the IKE SA before the sensitive information is sent to ensure this
would immediately create a new IKE SA (which is used to exchange information is protected by the PPK. Note that [RFC6023] allows to
everything else) by using a rekey mechanism for IKE SAs. Because the skip creating Child SA in the IKE_AUTH exchange, so that the
rekeyed IKE SA keys are a function of SK_d, which is a function of supporting peers can rekey the IKE SA before any Child SA is created.
the PPK (among other things), traffic protected by that IKE SA is Note also that some information (identities of the peers, feature
secure against Quantum capable adversaries. negotiation notifications, Vendor IDs etc.) is always exchanged in
initial exchanges and thus cannot be protected from the attack
described above by performing an IKE SA rekey.
In addition, the policy SHOULD be set to negotiate only quantum- In addition, the policy SHOULD be set to negotiate only quantum-
resistant symmetric algorithms; while this RFC doesn't claim to give resistant symmetric algorithms; while this RFC doesn't claim to give
advice as to what algorithms are secure (as that may change based on advice as to what algorithms are secure (as that may change based on
future cryptographical results), below is a list of defined IKEv2 and future cryptographical results), below is a list of defined IKEv2 and
IPsec algorithms that should NOT be used, as they are known not to be IPsec algorithms that should NOT be used, as they are known not to be
quantum resistant quantum resistant
o Any IKEv2 Encryption algorithm, PRF or Integrity algorithm with o Any IKEv2 Encryption algorithm, PRF or Integrity algorithm with
key size less than 256 bits. key size less than 256 bits.
 End of changes. 8 change blocks. 
31 lines changed or deleted 26 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/