draft-ietf-ipsecme-qr-ikev2-01.txt   draft-ietf-ipsecme-qr-ikev2-02.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 23, 2018 Cisco Systems Expires: August 31, 2018 Cisco Systems
V. Smyslov V. Smyslov
ELVIS-PLUS ELVIS-PLUS
December 20, 2017 February 27, 2018
Postquantum Preshared Keys for IKEv2 Postquantum Preshared Keys for IKEv2
draft-ietf-ipsecme-qr-ikev2-01 draft-ietf-ipsecme-qr-ikev2-02
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 June 23, 2018. This Internet-Draft will expire on August 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 (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
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 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informational References . . . . . . . . . . . . . . . . 16 8.2. Informational References . . . . . . . . . . . . . . . . 16
Appendix A. Discussion and Rationale . . . . . . . . . . . . . . 16 Appendix A. Discussion and Rationale . . . . . . . . . . . . . . 17
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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
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 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-02
o Added note that the PPK is stirred in the initial IKE SA setup
only.
o Added note about the initiator ignoring any content in the
PPK_IDENTITY notification from the responder.
o fixed Tero's suggestions from 2/6/1028
o Added IANA assigned message types where necessary.
o fixed minor text nits
draft-ietf-ipsecme-qr-ikev2-01 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_SUUPORT 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
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.
skipping to change at page 5, line 43 skipping to change at page 6, line 9
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 he will include a notification USE_PPK in the IKE_SA_INIT then he will include a notification USE_PPK in the IKE_SA_INIT
request message as follows: request message as follows:
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
HDR, SAi1, KEi, Ni, N(USE_PPK) ---> HDR, SAi1, KEi, Ni, N(USE_PPK) --->
N(USE_PPK) is a status notification payload with the type [TBA]; it N(USE_PPK) is a status notification payload with the type 16435; 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 USE_PPK 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 she ignores the received notification and any PPK configured, then she ignores the received notification and
skipping to change at page 7, line 9 skipping to change at page 7, line 27
as the initial ones, even if the underlying prf has output 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 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 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 output size equal to the (preferred) key size. For such prfs only
the first iteration of prf+ is needed: the first iteration of prf+ is needed:
SK_d = prf (PPK, SK_d' | 0x01) SK_d = prf (PPK, SK_d' | 0x01)
SK_pi = prf (PPK, SK_pi' | 0x01) SK_pi = prf (PPK, SK_pi' | 0x01)
SK_pr = prf (PPK, SK_pr' | 0x01) SK_pr = prf (PPK, SK_pr' | 0x01)
Note that the PPK is used in SK_d, SK_pi and SK_pr calculation only
during the initial IKE SA setup. It MUST NOT be used when these
subkeys are calculated as result of IKE SA rekey, resumption or other
similar operation.
The initiator then sends the IKE_AUTH request message, including the 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 16436; 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, she cannot the responder cannot continue with PPK (in particular, she cannot
authenticate the initiator), but she 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 16437; 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).
skipping to change at page 9, line 14 skipping to change at page 9, line 37
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 he checks for the When the initiator receives the response, then he checks for the
presence of the PPK_IDENTITY notification. If he receives one, he 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 he does not receive one, he MUST either SK_pr (as shown above); the content of the received PPK_IDENTITY (if
fail the IKE SA negotiation sending the AUTHENTICATION_FAILED any) MUST be ignored. If the initiator does not receive the
notification in the Informational exchange (if the PPK was configured PPK_IDENTITY, he MUST either fail the IKE SA negotiation sending the
as mandatory), or continue without using the PPK (if the PPK was not AUTHENTICATION_FAILED notification in the Informational exchange (if
configured as mandatory and the initiator included the NO_PPK_AUTH the PPK was configured as mandatory), or continue without using the
notification in the request). PPK (if the PPK was not configured as mandatory and the initiator
included the NO_PPK_AUTH notification in the request).
If EAP is used in the IKE_AUTH exchange, then the initiator doesn't If EAP is used in the IKE_AUTH exchange, then the initiator doesn't
include AUTH payload in the first request message, however the include AUTH payload in the first request message, however the
responder sends back AUTH payload in the first reply. The peers then responder sends back AUTH payload in the first reply. The peers then
exchange AUTH payloads after EAP is successfully completed. As a exchange AUTH payloads after EAP is successfully completed. As a
result, the responder sends AUTH payload twice - in the first result, the responder sends AUTH payload twice - in the first
IKE_AUTH reply message and in the last one, while the initiator sends 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 AUTH payload only in the last IKE_AUTH request. See more details
about EAP authentication in IKEv2 in Section 2.16 of [RFC7296]. about EAP authentication in IKEv2 in Section 2.16 of [RFC7296].
skipping to change at page 10, line 15 skipping to change at page 10, line 25
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {IDi, [CERTREQ,] HDR, SK {IDi, [CERTREQ,]
[IDr,] SAi2, [IDr,] SAi2,
TSi, TSr} --> TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH, <-- HDR, SK {IDr, [CERT,] AUTH,
EAP} EAP}
HDR, SK {EAP} --> HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)} <-- HDR, SK {EAP (success)}
HDR, SK {AUTH, HDR, SK {AUTH,
N(PPK_IDENTITY)(PPK_ID) N(PPK_IDENTITY, PPK_ID)
[, N(NO_PPK_AUTH)]} --> [, N(NO_PPK_AUTH)]} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr <-- HDR, SK {AUTH, SAr2, TSi, TSr
[, N(PPK_IDENTITY)]} [, N(PPK_IDENTITY)]}
Note, that the IKE_SA_INIT exchange in case of PPK is as described Note, that the IKE_SA_INIT exchange in case of PPK is as described
above (including exchange of the USE_PPK notifications), regardless above (including exchange of the USE_PPK notifications), regardless
whether EAP is employed in the IKE_AUTH or not. whether EAP is employed in the IKE_AUTH or not.
4. Upgrade procedure 4. Upgrade procedure
skipping to change at page 10, line 49 skipping to change at page 11, line 10
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 USE_PPK notify that have not yet been upgraded. This is due to the USE_PPK notify
and the NO_PPK_AUTH notify; if the initiator has not been upgraded, and the NO_PPK_AUTH notify; if the initiator has not been upgraded,
he will not send the USE_PPK notify (and so the responder will know he will not send the USE_PPK notify (and so the responder will know
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 the responder has not been upgraded and NO_PPK_AUTH notification. If both the responder and initiator have
properly configured, they will both realize it, and in that case, the been upgraded and properly configured, they will both realize it, and
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 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 13, line 37 skipping to change at page 13, line 50
(assuming that the PPK was high entropy and secret, and that all the (assuming that the PPK was high entropy and secret, and that all the
subkeys are sufficiently long). subkeys are sufficiently long).
Although this protocol preserves all the security properties of IKEv2 Although this protocol preserves all the security properties of IKEv2
against adversaries with conventional computers, it allows an against adversaries with conventional computers, it allows an
adversary with a Quantum Computer to decrypt all traffic encrypted adversary with a Quantum Computer to decrypt all traffic encrypted
with the initial IKE SA. In particular, it allows the adversary to with the initial IKE SA. In particular, it allows the adversary to
recover the identities of both sides. If there is IKE traffic other recover the identities of both sides. If there is IKE traffic other
than the identities that need to be protected against such an than the identities that need to be protected against such an
adversary, implementations MAY rekey the initial IKE SA immediately adversary, implementations MAY rekey the initial IKE SA immediately
after negotiating it to generate a new SKEYSEED with from the after negotiating it to generate a new SKEYSEED from the postquantum
postquantum SK_d. This would reduce the amount of data available to SK_d. This would reduce the amount of data available to an attacker
an attacker with a Quantum Computer. with a Quantum Computer.
Alternatively, an initial IKE SA (which is used to exchange Alternatively, an initial IKE SA (which is used to exchange
identities) can take place, perhaps by using the protocol documented identities) can take place, perhaps by using the protocol documented
in [RFC6023]. After the childless IKE SA is created, implementations in [RFC6023]. After the childless IKE SA is created, implementations
would immediately create a new IKE SA (which is used to exchange would immediately create a new IKE SA (which is used to exchange
everything else) by using a rekey mechanism for IKE SAs. Because the everything else) by using a rekey mechanism for IKE SAs. Because the
rekeyed IKE SA keys are a function of SK_d, which is a function of rekeyed IKE SA keys are a function of SK_d, which is a function of
the PPK (among other things), traffic protected by that IKE SA is the PPK (among other things), traffic protected by that IKE SA is
secure against Quantum capable adversaries. secure against Quantum capable adversaries.
skipping to change at page 15, line 20 skipping to change at page 15, line 29
doesn't contain the USE_PPK notification, then the initiator doesn't doesn't contain the USE_PPK notification, then the initiator doesn't
abort exchange immediately, but instead waits some time for more abort exchange immediately, but instead waits some time for more
responses (possibly retransmitting the request). If all the received responses (possibly retransmitting the request). If all the received
responses contain no USE_PPK, then the exchange is aborted. responses contain no USE_PPK, then the exchange 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> USE_PPK 16435 USE_PPK
<TBA> PPK_IDENTITY 16436 PPK_IDENTITY
<TBA> NO_PPK_AUTH 16437 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
PPK_ID_FIXED 2 PPK_ID_FIXED 2
Unassigned 3-127 Unassigned 3-127
skipping to change at page 17, line 20 skipping to change at page 17, line 32
trivially solved, the attacker still can't recover any key material trivially solved, the attacker still can't recover any key material
(except for the SK_ei, SK_er, SK_ai, SK_ar values for the initial IKE (except for the SK_ei, SK_er, SK_ai, SK_ar values for the initial IKE
exchange) unless they can find the PPK, which is too difficult if the exchange) unless they can find the PPK, which is too difficult if the
PPK has enough entropy (for example, 256 bits). Note that we do PPK has enough entropy (for example, 256 bits). Note that we do
allow an attacker with a Quantum Computer to rederive the keying allow an attacker with a Quantum Computer to rederive the keying
material for the initial IKE SA; this was a compromise to allow the material for the initial IKE SA; this was a compromise to allow the
responder to select the correct PPK quickly. responder to select the correct PPK quickly.
Another goal of this protocol is to minimize the number of changes Another goal of this protocol is to minimize the number of changes
within the IKEv2 protocol, and in particular, within the cryptography within the IKEv2 protocol, and in particular, within the cryptography
of IKEv2. By limiting our changes to notifications, and translating of IKEv2. By limiting our changes to notifications, and adjusting
the nonces, it is hoped that this would be implementable, even on the SK_d, SK_pi, SK_pr, it is hoped that this would be implementable,
systems that perform much of the IKEv2 processing is in hardware. even on systems that perform much of the IKEv2 processing is in
hardware.
A third goal was to be friendly to incremental deployment in A third goal was to be friendly to incremental deployment in
operational networks, for which we might not want to have a global operational networks, for which we might not want to have a global
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.
 End of changes. 23 change blocks. 
34 lines changed or deleted 55 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/