< draft-ietf-ipsecme-qr-ikev2-04.txt   draft-ietf-ipsecme-qr-ikev2-05.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: January 3, 2019 Cisco Systems Expires: June 28, 2019 Cisco Systems
V. Smyslov V. Smyslov
ELVIS-PLUS ELVIS-PLUS
July 2, 2018 December 25, 2018
Postquantum Preshared Keys for IKEv2 Postquantum Preshared Keys for IKEv2
draft-ietf-ipsecme-qr-ikev2-04 draft-ietf-ipsecme-qr-ikev2-05
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 January 3, 2019. This Internet-Draft will expire on June 28, 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
(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 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-05
o Addressed comments received during WGLC.
draft-ietf-ipsecme-qr-ikev2-04 draft-ietf-ipsecme-qr-ikev2-04
o Using Group PPK is clarified based on comment from Quynh Dang. 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.
skipping to change at page 4, line 48 skipping to change at page 5, line 5
o Expanded Security Considerations section to describe some security o Expanded Security Considerations section to describe some security
concerns and how they should be addressed. concerns and how they should be addressed.
draft-fluhrer-qr-ikev2-03 draft-fluhrer-qr-ikev2-03
o Modified how we stir the PPK into the IKEv2 secret state. o Modified how we stir the PPK into the IKEv2 secret state.
o Modified how the use of PPKs is negotiated. o Modified how the use of PPKs is negotiated.
draft-fluhrer-qr-ikev2-02
o Simplified the protocol by stirring in the preshared key into the o Simplified the protocol by stirring in the preshared key into the
child SAs; this avoids the problem of having the responder decide child SAs; this avoids the problem of having the responder decide
which preshared key to use (as it knows the initiator identity at which preshared key to use (as it knows the initiator identity at
that point); it does mean that someone with a Quantum Computer can that point); it does mean that someone with a Quantum Computer can
recover the initial IKE negotiation. recover the initial IKE negotiation.
o Removed positive endorsements of various algorithms. Retained o Removed positive endorsements of various algorithms. Retained
warnings about algorithms known to be weak against a Quantum warnings about algorithms known to be weak against a Quantum
Computer. Computer.
skipping to change at page 9, line 7 skipping to change at page 9, line 10
negotiation. Otherwise (when PPK is optional and the initiator negotiation. Otherwise (when PPK is optional and the initiator
included NO_PPK_AUTH notification) the responder MAY continue regular included NO_PPK_AUTH notification) the responder MAY continue regular
IKEv2 protocol, except that she uses the data from the NO_PPK_AUTH IKEv2 protocol, except that she uses the data from the NO_PPK_AUTH
notification as the authentication data (which usually resides in the notification as the authentication data (which usually resides in the
AUTH payload), for the purpose of the initiator authentication. AUTH payload), for the purpose of the initiator authentication.
Note, that Authentication Method is still indicated in the AUTH Note, that Authentication Method is still indicated in the AUTH
payload. payload.
This table summarizes the above logic for the responder: This table summarizes the above logic for the responder:
Received Received Have PPK Received Received Configured PPK is
USE_PPK NO_PPK_AUTH PPK Mandatory Action USE_PPK NO_PPK_AUTH with PPK Mandatory Action
----------------------------------------------------------------- ---------------------------------------------------------------------
No * No * Standard IKEv2 protocol No * No * Standard IKEv2 protocol
No * Yes No Standard IKEv2 protocol No * Yes No Standard IKEv2 protocol
No * Yes Yes Abort negotiation No * Yes Yes Abort negotiation
Yes No No * Abort negotiation Yes No No * Abort negotiation
Yes Yes No Yes Abort negotiation Yes Yes No Yes Abort negotiation
Yes Yes No No Standard IKEv2 protocol Yes Yes No No Standard IKEv2 protocol
Yes * Yes * Use PPK Yes * Yes * Use PPK
If PPK is in use, then the responder extracts the corresponding PPK If PPK is in use, then the responder extracts the corresponding PPK
and computes the following values: and computes the following values:
SK_d = prf+ (PPK, SK_d') SK_d = prf+ (PPK, SK_d')
SK_pi = prf+ (PPK, SK_pi') SK_pi = prf+ (PPK, SK_pi')
SK_pr = prf+ (PPK, SK_pr') SK_pr = prf+ (PPK, SK_pr')
The responder then continues with the IKE_AUTH exchange (validating The responder then continues with the IKE_AUTH exchange (validating
the AUTH payload that the initiator included) as usual and sends back the AUTH payload that the initiator included) as usual and sends back
skipping to change at page 11, line 19 skipping to change at page 11, line 24
that we will not use a PPK). If the responder has not been upgraded, that we will not use a PPK). If the responder has not been upgraded,
she will not send the USE_PPK notify (and so the initiator will know she will not send the USE_PPK notify (and so the initiator will know
to not use a PPK). If both peers have been upgraded, but the to not use a PPK). If both peers have been upgraded, but the
responder isn't yet configured with the PPK for the initiator, then responder isn't yet configured with the PPK for the initiator, then
the responder could do standard IKEv2 protocol if the initiator sent the responder could do standard IKEv2 protocol if the initiator sent
NO_PPK_AUTH notification. If both the responder and initiator have NO_PPK_AUTH notification. If both the responder and initiator have
been upgraded and properly configured, they will both realize it, and been upgraded and properly configured, they will both realize it, and
in that case, the link will be quantum secure. in that case, the link will be quantum secure.
As an optional second step, after all nodes have been upgraded, then As an optional second step, after all nodes have been upgraded, then
the administrator may then go back through the nodes, and mark the the administrator should then go back through the nodes, and mark the
use of PPK as mandatory. This will not affect the strength against a use of PPK as mandatory. This will not affect the strength against a
passive attacker; it would mean that an attacker with a Quantum passive attacker; it would mean that an attacker with a Quantum
Computer (which is sufficiently fast to be able to break the (EC)DH Computer (which is sufficiently fast to be able to break the (EC)DH
in real time) would not be able to perform a downgrade attack. in real time) would not be able to perform a downgrade attack.
5. PPK 5. PPK
5.1. PPK_ID format 5.1. PPK_ID format
This standard requires that both the initiator and the responder have This standard requires that both the initiator and the responder have
 End of changes. 8 change blocks. 
17 lines changed or deleted 19 lines changed or added

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