draft-ietf-ipsecme-qr-ikev2-00.txt   draft-ietf-ipsecme-qr-ikev2-01.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: April 18, 2018 Cisco Systems Expires: June 23, 2018 Cisco Systems
V. Smyslov V. Smyslov
ELVIS-PLUS ELVIS-PLUS
October 15, 2017 December 20, 2017
Postquantum Preshared Keys for IKEv2 Postquantum Preshared Keys for IKEv2
draft-ietf-ipsecme-qr-ikev2-00 draft-ietf-ipsecme-qr-ikev2-01
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 18, 2018. This Internet-Draft will expire on June 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (https://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 2, line 22 skipping to change at page 2, line 22
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
1.1. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Upgrade procedure . . . . . . . . . . . . . . . . . . . . . . 9 4. Upgrade procedure . . . . . . . . . . . . . . . . . . . . . . 10
5. PPK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. PPK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. PPK_ID format . . . . . . . . . . . . . . . . . . . . . . 9 5.1. PPK_ID format . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Operational Considerations . . . . . . . . . . . . . . . 10 5.2. Operational Considerations . . . . . . . . . . . . . . . 11
5.2.1. PPK Distribution . . . . . . . . . . . . . . . . . . 10 5.2.1. PPK Distribution . . . . . . . . . . . . . . . . . . 12
5.2.2. Group PPK . . . . . . . . . . . . . . . . . . . . . . 11 5.2.2. Group PPK . . . . . . . . . . . . . . . . . . . . . . 12
5.2.3. PPK-only Authentication . . . . . . . . . . . . . . . 11 5.2.3. PPK-only Authentication . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informational References . . . . . . . . . . . . . . . . 14 8.2. Informational References . . . . . . . . . . . . . . . . 16
Appendix A. Discussion and Rationale . . . . . . . . . . . . . . 15 Appendix A. Discussion and Rationale . . . . . . . . . . . . . . 16
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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
would be compromised. IKEv1 [RFC2409], when used with strong would be compromised. IKEv1 [RFC2409], when used with strong
skipping to change at page 3, line 30 skipping to change at page 3, line 30
It was considered important to minimize the changes to IKEv2. The It was considered important to minimize the changes to IKEv2. The
existing mechanisms to do authentication and key exchange remain in existing mechanisms to do authentication and key exchange remain in
place (that is, we continue to do (EC)DH, and potentially a PKI place (that is, we continue to do (EC)DH, and potentially a PKI
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.
Changes in this draft in each version iterations. Changes in this draft in each version iterations.
draft-ietf-ipsecme-qr-ikev2-01
o Nits and minor fixes.
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 PPK_SUUPORT notification is changed to USE_PPK to better reflect
its purpose.
draft-ietf-ipsecme-qr-ikev2-00 draft-ietf-ipsecme-qr-ikev2-00
o Migrated from draft-fluhrer-qr-ikev2-05 to draft-ietf-ipsecme-qr- o Migrated from draft-fluhrer-qr-ikev2-05 to draft-ietf-ipsecme-qr-
ikev2-00 that is a WG item. ikev2-00 that is a WG item.
draft-fluhrer-qr-ikev2-05 draft-fluhrer-qr-ikev2-05
o Nits and editorial fixes. o Nits and editorial fixes.
o Made PPK_ID format and PPK Distributions subsection of the PPK o Made PPK_ID format and PPK Distributions subsection of the PPK
skipping to change at page 5, line 29 skipping to change at page 5, line 36
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
with the responder (whether or not the use of the PPK is mandatory), with the responder (whether or not the use of the PPK is mandatory),
then it will include a notification PPK_SUPPORT in the initial then he will include a notification USE_PPK in the IKE_SA_INIT
exchange as follows: request message as follows:
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
HDR, SAi1, KEi, Ni, N(PPK_SUPPORT) ---> HDR, SAi1, KEi, Ni, N(USE_PPK) --->
N(PPK_SUPPORT) is a status notification payload with the type [TBA]; N(USE_PPK) is a status notification payload with the type [TBA]; it
it has a protocol ID of 0, no SPI and no notification data associated has a protocol ID of 0, no SPI and no notification data associated
with it. with it.
If the initiator needs to resend this initial message with a cookie If the initiator needs to resend this initial message with a cookie
(because the responder response included a COOKIE notification), then (because the responder response included a COOKIE notification), then
the resend would include the PPK_SUPPORT notification if the original the resend would include the USE_PPK notification if the original
message did. message did.
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 it 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 it has a PPK configured, and if it does, then the responder checks if she has a PPK configured, and if she does, then the
replies with the IKEv2 initial exchange including a PPK_SUPPORT 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(PPK_SUPPORT) <--- HDR, SAr1, KEr, Nr, [CERTREQ], N(USE_PPK)
When the initiator receives this reply, it checks whether the When the initiator receives this reply, he checks whether the
responder included the PPK_SUPPORT notification. If the responder responder included the USE_PPK notification. If the responder did
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 it 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 PPK_SUPPORT notification and If the responder did not include the USE_PPK notification and using
using PPKs for this responder is optional, then the initiator PPKs for this responder is optional, then the initiator continues
continues with the IKEv2 protocol as normal, without using PPKs. with the IKEv2 protocol as normal, without using PPKs.
If the responder did include the PPK_SUPPORT 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, it 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:
SKEYSEED = prf(Ni | Nr, g^ir) SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr' ) {SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr' )
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr } = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr }
SK_d = prf(PPK, SK_d')
SK_pi = prf(PPK, SK_pi') SK_d = prf+ (PPK, SK_d')
SK_pr = prf(PPK, SK_pr') SK_pi = prf+ (PPK, SK_pi')
SK_pr = prf+ (PPK, SK_pr')
That is, we use the standard IKEv2 key derivation process except that That is, we use the standard IKEv2 key derivation process except that
the three subkeys SK_d, SK_pi, SK_pr are run through the prf again, the three subkeys SK_d, SK_pi, SK_pr are run through the prf+ again,
this time using the PPK as the key. this time using the PPK as the key. Using prf+ construction ensures
that it is always possible to get the resulting keys of the same size
as the initial ones, even if the underlying prf has output size
different from its key size. Note, that at the time this document
was written, all prfs defined for use in IKEv2 [IKEV2-IANA-PRFS] had
output size equal to the (preferred) key size. For such prfs only
the first iteration of prf+ is needed:
The initiator then sends the initial encrypted message, including the SK_d = prf (PPK, SK_d' | 0x01)
SK_pi = prf (PPK, SK_pi' | 0x01)
SK_pr = prf (PPK, SK_pr' | 0x01)
The initiator then sends the IKE_AUTH request message, including the
PPK_ID value as follows: PPK_ID value as follows:
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,] HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, [IDr,] AUTH, SAi2,
TSi, TSr, N(PPK_IDENTITY)(PPK_ID), [N(NO_PPK_AUTH)]} ---> TSi, TSr, N(PPK_IDENTITY)(PPK_ID), [N(NO_PPK_AUTH)]} --->
PPK_IDENTITY is a status notification with the type [TBA]; it has a PPK_IDENTITY is a status notification with the type [TBA]; it has a
protocol ID of 0, no SPI and a notification data that consists of the protocol ID of 0, no SPI and a notification data that consists of the
identifier PPK_ID. identifier PPK_ID.
A situation may happen when the responder has some PPKs, but doesn't A situation may happen when the responder has some PPKs, but doesn't
have a PPK with the PPK_ID received from the initiator. In this case have a PPK with the PPK_ID received from the initiator. In this case
the responder cannot continue with PPK (in particular, it cannot the responder cannot continue with PPK (in particular, she cannot
authenticate the initiator), but it could be able to continue with authenticate the initiator), but she could be able to continue with
normal IKEv2 protocol if the initiator provided its authentication normal IKEv2 protocol if the initiator provided its authentication
data computed as in normal IKEv2, without using PPKs. For this data computed as in normal IKEv2, without using PPKs. For this
purpose, if using PPKs for communication with this responder is purpose, if using PPKs for communication with this responder is
optional for the initiator, then the initiator MAY include a optional for the initiator, then the initiator MAY include a
notification NO_PPK_AUTH in the above message. notification NO_PPK_AUTH in the above message.
NO_PPK_AUTH is a status notification with the type [TBA]; it has a NO_PPK_AUTH is a status notification with the type [TBA]; it has a
protocol ID of 0 and no SPI. A notification data consists of the protocol ID of 0 and no SPI. A notification data consists of the
initiator's authentication data computed using SK_pi' (i.e. the data initiator's authentication data computed using SK_pi' (i.e. the data
that computed without using PPKs and would normally be placed in the that computed without using PPKs and would normally be placed in the
AUTH payload). Authentication Method for computing the AUTH payload). Authentication Method for computing the
authentication data MUST be the same as indicated in the AUTH payload authentication data MUST be the same as indicated in the AUTH payload
and is not included in the notification. Note that if the initiator and is not included in the notification. Note that if the initiator
decides to include NO_PPK_AUTH notification, then it means that the decides to include NO_PPK_AUTH notification, then it means that the
initiator needs to perform authentication data computation twice that initiator needs to perform authentication data computation twice that
may consume substantial computation power (e.g. if digital signatures may consume substantial computation power (e.g. if digital signatures
are involved). are involved).
When the responder receives this encrypted exchange, it first When the responder receives this encrypted exchange, she first
computes the values: computes the values:
SKEYSEED = prf(Ni | Nr, g^ir) SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr' } {SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr' }
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
It then uses the SK_ei/SK_ai values to decrypt/check the message and She then uses the SK_ei/SK_ai values to decrypt/check the message and
then scans through the payloads for the PPK_ID attached to the then scans through the payloads for the PPK_ID attached to the
PPK_IDENTITY notification. If no PPK_IDENTITY notification is found PPK_IDENTITY notification. If no PPK_IDENTITY notification is found
and the peers successfully exchanged PPK_SUPPORT notifications in the and the peers successfully exchanged USE_PPK notifications in the
initial exchange, then the responder MUST send back IKE_SA_INIT exchange, then the responder MUST send back
AUTHENTICATION_FAILED notification and then fail the negotiation. AUTHENTICATION_FAILED notification and then fail the negotiation.
If the PPK_IDENTITY notification contains PPK_ID that is not known to If the PPK_IDENTITY notification contains PPK_ID that is not known to
the responder or is not configured for use for the identity from IDi the responder or is not configured for use for the identity from IDi
payload, then the responder checks whether using PPKs for this payload, then the responder checks whether using PPKs for this
initiator is mandatory and whether the initiator included NO_PPK_AUTH initiator is mandatory and whether the initiator included NO_PPK_AUTH
notification in the message. If using PPKs is mandatory or no notification in the message. If using PPKs is mandatory or no
NO_PPK_AUTH notification found, then then the responder MUST send NO_PPK_AUTH notification found, then then the responder MUST send
back AUTHENTICATION_FAILED notification and then fail the back AUTHENTICATION_FAILED notification and then fail the
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 it 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 by the responder: This table summarizes the above logic by the responder:
Received Received Have PPK Received Received Have PPK
PPK_SUPPORT NO_PPK_AUTH PPK Mandatory Action USE_PPK NO_PPK_AUTH 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 corresponding PPK and If PPK is in use, then the responder extracts corresponding PPK and
computes the following values: 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 exchange (validating the AUTH The responder then continues with the IKE_AUTH exchange (validating
payload that the initiator included) as usual and sends back a the AUTH payload that the initiator included) as usual and sends back
response, which includes the PPK_IDENTITY notification with no data a response, which includes the PPK_IDENTITY notification with no data
to indicate that the PPK is used in the exchange: to indicate that the PPK is used in the exchange:
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
<-- HDR, SK {IDr, [CERT,] <-- HDR, SK {IDr, [CERT,]
AUTH, SAr2, AUTH, SAr2,
TSi, TSr, N(PPK_IDENTITY)} TSi, TSr, N(PPK_IDENTITY)}
When the initiator receives the response, then it checks for the When the initiator receives the response, then he checks for the
presence of the PPK_IDENTITY notification. If it receives one, it presence of the PPK_IDENTITY notification. If he receives one, he
marks the SA as using the configured PPK to generate SK_d, SK_pi, marks the SA as using the configured PPK to generate SK_d, SK_pi,
SK_pr (as shown above); if it does not receive one, it MUST either SK_pr (as shown above); if he does not receive one, he MUST either
fail the IKE SA negotiation sending the AUTHENTICATION_FAILED fail the IKE SA negotiation sending the AUTHENTICATION_FAILED
notification in the Informational exchange (if the PPK was configured notification in the Informational exchange (if the PPK was configured
as mandatory), or continue without using the PPK (if the PPK was not as mandatory), or continue without using the PPK (if the PPK was not
configured as mandatory and the initiator included the NO_PPK_AUTH configured as mandatory and the initiator included the NO_PPK_AUTH
notification in the request). notification in the request).
If EAP is used in the IKE_AUTH exchange, then the initiator doesn't
include AUTH payload in the first request message, however the
responder sends back AUTH payload in the first reply. The peers then
exchange AUTH payloads after EAP is successfully completed. As a
result, the responder sends AUTH payload twice - in the first
IKE_AUTH reply message and in the last one, while the initiator sends
AUTH payload only in the last IKE_AUTH request. See more details
about EAP authentication in IKEv2 in Section 2.16 of [RFC7296].
The general rule for using PPK in the IKE_AUTH exchange, which covers
EAP authentication case too, is that the initiator includes
PPK_IDENTITY (and optionally NO_PPK_AUTH) notification in the request
message containing AUTH payload. Therefore, in case of EAP the
responder always computes the AUTH payload in the first IKE_AUTH
reply message without using PPK (by means of SK_pr'), since PPK_ID is
not yet known to the responder. Once the IKE_AUTH request message
containing PPK_IDENTITY notification is received, the responder
follows rules described above for non-EAP authentication case.
Initiator Responder
-------------------------------------------------------------------
HDR, SK {IDi, [CERTREQ,]
[IDr,] SAi2,
TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
EAP}
HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)}
HDR, SK {AUTH,
N(PPK_IDENTITY)(PPK_ID)
[, N(NO_PPK_AUTH)]} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr
[, N(PPK_IDENTITY)]}
Note, that the IKE_SA_INIT exchange in case of PPK is as described
above (including exchange of the USE_PPK notifications), regardless
whether EAP is employed in the IKE_AUTH or not.
4. Upgrade procedure 4. Upgrade procedure
This algorithm was designed so that someone can introduce PPKs into This algorithm was designed so that someone can introduce PPKs into
an existing IKE network without causing network disruption. an existing IKE network without causing network disruption.
In the initial phase of the network upgrade, the network In the initial phase of the network upgrade, the network
administrator would visit each IKE node, and configure: administrator would visit each IKE node, and configure:
o The set of PPKs (and corresponding PPK_IDs) that this node would o The set of PPKs (and corresponding PPK_IDs) that this node would
need to know. need to know.
o For each peer that this node would initiate to, which PPK will be o For each peer that this node would initiate to, which PPK will be
used. used.
o That the use of PPK is currently not mandatory. o That the use of PPK is currently not mandatory.
With this configuration, the node will continue to operate with nodes With this configuration, the node will continue to operate with nodes
that have not yet been upgraded. This is due to the PPK_SUPPORT that have not yet been upgraded. This is due to the USE_PPK notify
notify and the NO_PPK_AUTH notify; if the initiator has not been and the NO_PPK_AUTH notify; if the initiator has not been upgraded,
upgraded, it will not send the PPK_SUPPORT notify (and so the he will not send the USE_PPK notify (and so the responder will know
responder will know that we will not use a PPK). If the responder that we will not use a PPK). If the responder has not been upgraded,
has not been upgraded, it will not send the PPK_SUPPORT notify (and she will not send the USE_PPK notify (and so the initiator will know
so the initiator will know to not use a PPK). If both peers have to not use a PPK). If both peers have been upgraded, but the
been upgraded, but the responder isn't yet configured with the PPK responder isn't yet configured with the PPK for the initiator, then
for the initiator, then the responder could do standard IKEv2 the responder could do standard IKEv2 protocol if the initiator sent
protocol if the initiator sent NO_PPK_AUTH notification. If the NO_PPK_AUTH notification. If the responder has not been upgraded and
responder has not been upgraded and properly configured, they will properly configured, they will both realize it, and in that case, the
both realize it, and in that case, the link will be quantum secure. 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 may 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
skipping to change at page 11, line 41 skipping to change at page 13, line 7
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.
PPK-only authentication can be achieved in IKEv2 if NULL PPK-only authentication can be achieved in IKEv2 if NULL
Authentication method [RFC7619] is employed. Without PPK the NULL Authentication method [RFC7619] is employed. Without PPK the NULL
Authentication method provides no authentication of the peers, Authentication method provides no authentication of the peers,
however since a PPK is stirred into the SK_pi and the SK_pr, the however since a PPK is stirred into the SK_pi and the SK_pr, the
peers become authenticated if a PPK is in use. Using PPKs MUST be peers become authenticated if a PPK is in use. Using PPKs MUST be
mandatory for the peers if they advertise support for PPK in initial mandatory for the peers if they advertise support for PPK in
exchange and use NULL Authentication. Addtionally, since the peers IKE_SA_INIT and use NULL Authentication. Addtionally, since the
are authenticated via PPK, the ID Type in the IDi/IDr payloads SHOULD peers are authenticated via PPK, the ID Type in the IDi/IDr payloads
NOT be ID_NULL, despite using NULL Authentication method. SHOULD NOT be ID_NULL, despite using NULL Authentication method.
6. Security Considerations 6. Security Considerations
Quantum computers are able to perform Grover's algorithm; that Quantum computers are able to perform Grover's algorithm; that
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 a 128-bit security least 256 bits of entropy, in order to provide a 128-bit security
level. level.
With this protocol, the computed SK_d is a function of the PPK, and With this protocol, the computed SK_d is a function of the PPK, and
skipping to change at page 13, line 11 skipping to change at page 14, line 27
key size less than 256 bits. key size less than 256 bits.
o Any ESP Transform with key size less than 256 bits. o Any ESP Transform with key size less than 256 bits.
o PRF_AES128_XCBC and PRF_AES128_CBC; even though they are defined o PRF_AES128_XCBC and PRF_AES128_CBC; even though they are defined
to be able to use an arbitrary key size, they convert it into a to be able to use an arbitrary key size, they convert it into a
128-bit key internally. 128-bit key internally.
Section 3 requires the initiator to abort the initial exchange if Section 3 requires the initiator to abort the initial exchange if
using PPKs is mandatory for it, but the responder didn't include the using PPKs is mandatory for it, but the responder didn't include the
PPK_SUPPORT notification in the response. In this situation when the USE_PPK notification in the response. In this situation when the
initiator aborts negotiation it leaves half-open IKE SA on the initiator aborts negotiation he leaves half-open IKE SA on the
responder (because the initial exchange completes successfully from responder (because IKE_SA_INIT completes successfully from
responder's point of view). This half-open SA will eventually expire responder's point of view). This half-open SA will eventually expire
and be deleted, but if the initiator continues its attempts to create and be deleted, but if the initiator continues its attempts to create
IKE SA with a high enough rate, then the responder may consider it as IKE SA with a high enough rate, then the responder may consider it as
a Denial-of-Service attack and take some measures (see [RFC8019] for a Denial-of-Service attack and take some measures (see [RFC8019] for
more detail). It is RECOMMENDED that implementations in this more detail). It is RECOMMENDED that implementations in this
situation cache the negative result of negotiation for some time and situation cache the negative result of negotiation for some time and
don't make attempts to create it again for some time, because this is don't make attempts to create it again for some time, because this is
a result of misconfiguration and probably some re-configuration of a result of misconfiguration and probably some re-configuration of
the peers is needed. the peers is needed.
If using PPKs is optional for both peers and they authenticate If using PPKs is optional for both peers and they authenticate
themselves using digital signatures, then an attacker in between, themselves using digital signatures, then an attacker in between,
equipped with a Quantum Computer capable of breaking public key equipped with a Quantum Computer capable of breaking public key
operations in real time, is able to mount downgrade attack by operations in real time, is able to mount downgrade attack by
removing PPK_SUPPORT notification from the initial exchange and removing USE_PPK notification from the IKE_SA_INIT and forging
forging digital signatures in the subsequent exchange. If using PPKs digital signatures in the subsequent exchange. If using PPKs is
is mandatory for at least one of the peers or PSK is used for mandatory for at least one of the peers or PSK is used for
authentication, then the attack will be detected and the SA won't be authentication, then the attack will be detected and the SA won't be
created. created.
If using PPKs is mandatory for the initiator, then an attacker If using PPKs is mandatory for the initiator, then an attacker
capable to eavesdrop and to inject packets into the network can capable to eavesdrop and to inject packets into the network can
prevent creating IKE SA by mounting the following attack. The prevent creating IKE SA by mounting the following attack. The
attacker intercepts the the initial request containing the attacker intercepts the the initial request containing the USE_PPK
PPK_SUPPORT notification and injects the forget response containing notification and injects the forget response containing no USE_PPK.
no PPK_SUPPORT. If the attacker manages to inject this packet before If the attacker manages to inject this packet before the responder
the responder sends a genuine response, then the initiator would sends a genuine response, then the initiator would abort the
abort the exchange. To thwart this kind of attack it is RECOMMENDED, exchange. To thwart this kind of attack it is RECOMMENDED, that if
that if using PPKs is mandatory for the initiator and the received using PPKs is mandatory for the initiator and the received response
response doesn't contain the PPK_SUPPORT notification, then the doesn't contain the USE_PPK notification, then the initiator doesn't
initiator doesn't abort exchange immediately, but instead waits some abort exchange immediately, but instead waits some time for more
time for more responses (possibly retransmitting the request). If responses (possibly retransmitting the request). If all the received
all the received responses contain no PPK_SUPPORT, then the exchange responses contain no USE_PPK, then the exchange is aborted.
is aborted.
7. IANA Considerations 7. IANA Considerations
This document defines three new Notify Message Types in the "Notify This document defines three new Notify Message Types in the "Notify
Message Types - Status Types" registry: Message Types - Status Types" registry:
<TBA> PPK_SUPPORT <TBA> USE_PPK
<TBA> PPK_IDENTITY <TBA> PPK_IDENTITY
<TBA> NO_PPK_AUTH <TBA> NO_PPK_AUTH
This document also creates a new IANA registry for the PPK_ID types. This document also creates a new IANA registry for the PPK_ID types.
The initial values of this registry are: The initial values of this registry are:
PPK_ID Type Value PPK_ID Type Value
----------- ----- ----------- -----
Reserved 0 Reserved 0
PPK_ID_OPAQUE 1 PPK_ID_OPAQUE 1
skipping to change at page 14, line 46 skipping to change at page 16, line 9
[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-01 (work in Quantum Cryptography", draft-hoffman-c2pq-02 (work in
progress), July 2017. progress), August 2017.
[IKEV2-IANA-PRFS]
"Internet Key Exchange Version 2 (IKEv2) Parameters,
Transform Type 2 - Pseudorandom Function Transform IDs",
<https://www.iana.org/assignments/ikev2-parameters/
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-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
skipping to change at page 16, line 19 skipping to change at page 17, line 36
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
and the rest of the ipsecme Working Group for their feedback and and the rest of the IPSecME Working Group for their feedback and
suggestions for the scheme. 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
 End of changes. 41 change blocks. 
98 lines changed or deleted 164 lines changed or added

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