< draft-ietf-ipsecme-ikev2-multiple-ke-00.txt   draft-ietf-ipsecme-ikev2-multiple-ke-01.txt >
Internet Engineering Task Force (IETF) C. Tjhai Internet Engineering Task Force (IETF) C. Tjhai
Internet-Draft M. Tomlinson Internet-Draft M. Tomlinson
Updates: 7296 (if approved) Post-Quantum Updates: 7296 (if approved) Post-Quantum
Intended status: Standards Track G. Bartlett Intended status: Standards Track G. Bartlett
Expires: July 11, 2020 S. Fluhrer Expires: January 8, 2021 Quantum Secret
S. Fluhrer
Cisco Systems Cisco Systems
D. Van Geest D. Van Geest
ISARA Corporation ISARA Corporation
O. Garcia-Morchon O. Garcia-Morchon
Philips Philips
V. Smyslov V. Smyslov
ELVIS-PLUS ELVIS-PLUS
January 8, 2020 July 7, 2020
Multiple Key Exchanges in IKEv2 Multiple Key Exchanges in IKEv2
draft-ietf-ipsecme-ikev2-multiple-ke-00 draft-ietf-ipsecme-ikev2-multiple-ke-01
Abstract Abstract
This document describes how to extend the Internet Key Exchange This document describes how to extend the Internet Key Exchange
Protocol Version 2 (IKEv2) to allow multiple key exchanges to take Protocol Version 2 (IKEv2) to allow multiple key exchanges to take
place while computing of a shared secret during a Security place while computing a shared secret during a Security Association
Association (SA) setup. The primary application of this feature in (SA) setup. The primary application of this feature in IKEv2 is the
IKEv2 is the ability to perform one or more post-quantum key ability to perform one or more post-quantum key exchanges in
exchanges in conjunction with the classical (Elliptic Curve) Diffie- conjunction with the classical (Elliptic Curve) Diffie-Hellman key
Hellman key exchange, so that the resulting shared key is resistant exchange, so that the resulting shared key is resistant against
against quantum computer attacks. Another possible application is quantum computer attacks. Another possible application is the
the ability to combine several key exchanges in situations when no ability to combine several key exchanges in situations when no single
single key exchange algorithm is trusted by both initiator and key exchange algorithm is trusted by both initiator and responder.
responder.
This document updates RFC7296 by renaming a tranform type 4 from This document updates RFC7296 by renaming a transform type 4 from
"Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and
renaming a field in the Key Exchange Payload from "Diffie-Hellman renaming a field in the Key Exchange Payload from "Diffie-Hellman
Group Num" to "Key Exchange Method". It also renames an IANA Group Num" to "Key Exchange Method". It also renames an IANA
registry for this transform type from "Transform Type 4 - Diffie- registry for this transform type from "Transform Type 4 - Diffie-
Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange
Method Transform IDs". These changes generalize key exchange Method Transform IDs". These changes generalize key exchange
algorithms that can be used in IKEv2. algorithms that can be used in IKEv2.
Status of This Memo Status of This Memo
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 July 11, 2020. This Internet-Draft will expire on January 8, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 38 skipping to change at page 2, line 38
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3
1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . 3 1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . 3
1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Document Organization . . . . . . . . . . . . . . . . . . 5 1.4. Document Organization . . . . . . . . . . . . . . . . . . 5
2. Design Criteria . . . . . . . . . . . . . . . . . . . . . . . 6 2. Design Criteria . . . . . . . . . . . . . . . . . . . . . . . 6
3. Multiple Key Exchanges . . . . . . . . . . . . . . . . . . . 8 3. Multiple Key Exchanges . . . . . . . . . . . . . . . . . . . 8
3.1. Overall design . . . . . . . . . . . . . . . . . . . . . 8 3.1. Overall Design . . . . . . . . . . . . . . . . . . . . . 8
3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . 9 3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . 9
3.2.1. IKE_SA_INIT Round: Negotiation . . . . . . . . . . . 10 3.2.1. IKE_SA_INIT Round: Negotiation . . . . . . . . . . . 10
3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges . . 11 3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges . . 11
3.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 12 3.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 12
3.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 3.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Alternative Design . . . . . . . . . . . . . . . . . 18 Appendix A. Alternative Design . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
1.1. Problem Description 1.1. Problem Description
Internet Key Exchange Protocol (IKEv2) as specified in [RFC7296] uses Internet Key Exchange Protocol (IKEv2) as specified in [RFC7296] uses
the Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) the Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH)
algorithm to establish a shared secret between an initiator and a algorithm to establish a shared secret between an initiator and a
responder. The security of the DH and ECDH algorithms relies on the responder. The security of the DH and ECDH algorithms relies on the
difficulty to solve a discrete logarithm problem in multiplicative difficulty to solve a discrete logarithm problem in multiplicative
and elliptic curve groups respectively when the order of the group and elliptic curve groups respectively when the order of the group
parameter is large enough. While solving such a problem remains parameter is large enough. While solving such a problem remains
difficult with current computing power, it is believed that general difficult with current computing power, it is believed that general
purpose quantum computers will be able to solve this problem, purpose quantum computers will be able to solve this problem,
implying that the security of IKEv2 is compromised. There are, implying that the security of IKEv2 is compromised. There are,
however, a number of cryptosystems that are conjectured to be however, a number of cryptosystems that are conjectured to be
resistant against quantum computer attack. This family of resistant against quantum computer attack. This family of
cryptosystems are known as post-quantum cryptography (PQC). It is cryptosystems is known as post-quantum cryptography (PQC). It is
sometimes also referred to as quantum-safe cryptography (QSC) or sometimes also referred to as quantum-safe cryptography (QSC) or
quantum-resistant cryptography (QRC). quantum-resistant cryptography (QRC).
1.2. Proposed Extension 1.2. Proposed Extension
This document describes a method to perform multiple successive key This document describes a method to perform multiple successive key
exchanges in IKEv2. It allows integration of QSC in IKEv2, while exchanges in IKEv2. It allows integration of QSC in IKEv2, while
maintaining backwards compatibility, to derive a set of IKE keys that maintaining backwards compatibility, to derive a set of IKE keys that
is resistant to quantum computer attacks. This extension allows the is resistant to quantum computer attacks. This extension allows the
negotiation of one or more QSC algorithm to exchange data, in negotiation of one or more QSC algorithm to exchange data, in
addition to the existing DH or ECDH key exchange data. We believe addition to the existing DH or ECDH key exchange data. We believe
that the feature of using more than one post-quantum algorithm is that the feature of using more than one post-quantum algorithms is
important as many of these algorithms are relatively new and there important as many of these algorithms are relatively new and there
may be a need to hedge the security risk with multiple key exchange may be a need to hedge the security risk with multiple key exchange
data from several distinct QSC algorithms. data from several distinct QSC algorithms.
The secrets established from each key exchange are combined in a way The secrets established from each key exchange are combined in a way
such that should the post-quantum secrets not be present, the derived such that should the post-quantum secrets not be present, the derived
shared secret is equivalent to that of the standard IKEv2; on the shared secret is equivalent to that of the standard IKEv2; on the
other hand, a post-quantum shared secret is obtained if both other hand, a post-quantum shared secret is obtained if both
classical and post-quantum key exchange data are present. This classical and post-quantum key exchange data are present. This
extension also applies to key exchanges in IKE Security Associations extension also applies to key exchanges in IKE Security Associations
(SAs) for Encapsulating Security Payload (ESP) [RFC4303] or (SAs) for Encapsulating Security Payload (ESP) [RFC4303] or
Authentication Header (AH) [RFC4302], i.e. Child SAs, in order to Authentication Header (AH) [RFC4302], i.e. Child SAs, in order to
provide a stronger guarantee of forward security. provide a stronger guarantee of forward security.
Some post-quantum key exchange payloads may have size larger than the Some post-quantum key exchange payloads may have sizes larger than
standard maximum transmission unit (MTU) size, and therefore there the standard maximum transmission unit (MTU) size, and therefore
could be issues with fragmentation at IP layer. IKE does allow there could be issues with fragmentation at the IP layer. IKE does
transmission over TCP where fragmentation is not an issue [RFC8229]; allow transmission over TCP where fragmentation is not an issue
however, we believe that a UDP-based solution will be required too. [RFC8229]; however, we believe that a UDP-based solution will be
required too. IKE does have a mechanism to handle fragmentation
IKE does have a mechanism to handle fragmentation within UDP within UDP [RFC7383], however that is only applicable to messages
[RFC7383], however that is only applicable to messages exchanged exchanged after the IKE_SA_INIT. To use this mechanism, this
after the IKE_SA_INIT. To use this mechanism, this specification specification relies on the IKE_INTERMEDIATE exchange as outlined in
relies on the IKE_INTERMEDIATE exchange as outlined in
[I-D.ietf-ipsecme-ikev2-intermediate]. With this mechanism, we do an [I-D.ietf-ipsecme-ikev2-intermediate]. With this mechanism, we do an
initial key exchange, using a smaller, possibly non-quantum resistant initial key exchange, using a smaller, possibly non-quantum resistant
primitive, such as ECDH. Then, before we do the IKE_AUTH exchange, primitive, such as ECDH. Then, before we do the IKE_AUTH exchange,
we perform one or more IKE_INTERMEDIATE exchanges, each of which we perform one or more IKE_INTERMEDIATE exchanges, each of which
contains an additional key exchange. As the IKE_INTERMEDIATE contains an additional key exchange. As the IKE_INTERMEDIATE
exchange is encrypted, the IKE fragmentation protocol [RFC7383] can exchange is encrypted, the IKE fragmentation protocol [RFC7383] can
be used. The IKE SK_* values are updated after each exchange, and so be used. The IKE SK_* values are updated after each exchange, and so
the final IKE SA keys depend on all the key exchanges, hence they are the final IKE SA keys depend on all the key exchanges, hence they are
secure if any of the key exchanges are secure. secure if any of the key exchanges are secure.
Note that readers should consider the approach defined in this Note that readers should consider the approach defined in this
document as providing a long term solution in upgrading the IKEv2 document as providing a long term solution in upgrading the IKEv2
protocol to support post-quantum algorithms. A short term solution protocol to support post-quantum algorithms. A short term solution
to make IKEv2 key exchange quantum secure is to use post-quantum pre- to make IKEv2 key exchange quantum secure is to use post-quantum pre-
shared keys as discussed in [I-D.ietf-ipsecme-qr-ikev2]. shared keys as discussed in [RFC8784].
Note also, that the proposed approach of performing multiple Note also, that the proposed approach of performing multiple
successive key exchanges in such a way that resulting session keys successive key exchanges in such a way that resulting session keys
depend on all of them is not limited to achieving quantum resistance depend on all of them is not limited to achieving quantum resistance
only. It can also be used when all the performed key exchanges are only. It can also be used when all the performed key exchanges are
classical (EC)DH ones, but for some reasons (e.g. policy classical (EC)DH ones, where for some reasons (e.g. policy
requirements) it is essential to perform multiple of them. requirements) it is essential to perform multiple of them.
1.3. Changes 1.3. 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-ikev2-multiple-ke-01
o References are updated.
draft-ietf-ipsecme-ikev2-multiple-ke-00 draft-ietf-ipsecme-ikev2-multiple-ke-00
o Draft name changed as result of WG adoption and generalization of o Draft name changed as result of WG adoption and generalization of
the approach. the approach.
o New exchange IKE_FOLLOWUP_KE is defined for additional key o New exchange IKE_FOLLOWUP_KE is defined for additional key
exchanges performed after CREATE_CHILD_SA. exchanges performed after CREATE_CHILD_SA.
o Nonces are removed from all additional key exchanges. o Nonces are removed from all additional key exchanges.
o Clarification that IKE_INTERMEDIATE must be negotiated is added. o Clarification that IKE_INTERMEDIATE must be negotiated is added.
draft-tjhai-ipsecme-hybrid-qske-ikev2-04
o Clarification about key derivation in case of multiple key o Clarification about key derivation in case of multiple key
exchanges in CREATE_CHILD_SA is added. exchanges in CREATE_CHILD_SA is added.
o Resolving rekey collisions in case of multiple key exchanges is o Resolving rekey collisions in case of multiple key exchanges is
clarified. clarified.
draft-tjhai-ipsecme-hybrid-qske-ikev2-03 draft-tjhai-ipsecme-hybrid-qske-ikev2-03
o Using multiple key exchanges CREATE_CHILD_SA is defined. o Using multiple key exchanges CREATE_CHILD_SA is defined.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
is available (e.g., year Q) if key negotiation only relies on is available (e.g., year Q) if key negotiation only relies on
non post-quantum primitives. This is a high threat for any non post-quantum primitives. This is a high threat for any
information that must remain confidential for a long period of information that must remain confidential for a long period of
time T > Q-D. The need is obvious if we assume that Q is 2040, time T > Q-D. The need is obvious if we assume that Q is 2040,
D is 2020, and T is 30 years. Such a value of T is typical in D is 2020, and T is 30 years. Such a value of T is typical in
classified or healthcare data. classified or healthcare data.
2) Hybrid. Currently, there does not exist a post-quantum key 2) Hybrid. Currently, there does not exist a post-quantum key
exchange that is trusted at the level that ECDH is trusted exchange that is trusted at the level that ECDH is trusted
against conventional (non-quantum) adversaries. A hybrid post- against conventional (non-quantum) adversaries. A hybrid post-
quantum algorithms to be introduced next to well-established quantum algorithm to be introduced next to well-established
primitives, since the overall security is at least as strong as primitives, since the overall security is at least as strong as
each individual primitive. each individual primitive.
3) Focus on quantum-resistant confidentiality. A passive attacker 3) Focus on quantum-resistant confidentiality. A passive attacker
can eavesdrop on IPsec communication today and decrypt it once a can eavesdrop on IPsec communication today and decrypt it once a
quantum computer is available in the future. This is a very quantum computer is available in the future. This is a very
serious attack for which we do not have a solution. An attacker serious attack for which we do not have a solution. An attacker
can only perform active attacks such as impersonation of the can only perform active attacks such as impersonation of the
communicating peers once a quantum computer is available, communicating peers once a quantum computer is available,
sometime in the future. Thus, our design focuses on quantum- sometime in the future. Thus, our design focuses on quantum-
skipping to change at page 7, line 6 skipping to change at page 7, line 6
4) Limit amount of exchanged data. The protocol design should be 4) Limit amount of exchanged data. The protocol design should be
such that the amount of exchanged data, such as public-keys, is such that the amount of exchanged data, such as public-keys, is
kept as small as possible even if initiator and responder need kept as small as possible even if initiator and responder need
to agree on a hybrid group or multiple public-keys need to be to agree on a hybrid group or multiple public-keys need to be
exchanged. exchanged.
5) Future proof. Any cryptographic algorithm could be potentially 5) Future proof. Any cryptographic algorithm could be potentially
broken in the future by currently unknown or impractical broken in the future by currently unknown or impractical
attacks: quantum computers are merely the most concrete example attacks: quantum computers are merely the most concrete example
of this. The design does not categorize algorithms as "post- of this. The design does not categorize algorithms as "post-
quantum" or "non post-quantum" and does not create assumptions quantum" or "non post-quantum" nor does it create assumptions
about the properties of the algorithms, meaning that if about the properties of the algorithms, meaning that if
algorithms with different properties become necessary in the algorithms with different properties become necessary in the
future, this extension can be used unchanged to facilitate future, this extension can be used unchanged to facilitate
migration to those algorithms. migration to those algorithms.
6) Limited amount of changes. A key goal is to limit the number of 6) Limited amount of changes. A key goal is to limit the number of
changes required when enabling a post-quantum handshake. This changes required when enabling a post-quantum handshake. This
ensures easier and quicker adoption in existing implementations. ensures easier and quicker adoption in existing implementations.
7) Localized changes. Another key requirement is that changes to 7) Localized changes. Another key requirement is that changes to
skipping to change at page 7, line 33 skipping to change at page 7, line 33
based on algorithms that both client and server wish to support. based on algorithms that both client and server wish to support.
9) Fragmentation support. Some PQC algorithms could be relatively 9) Fragmentation support. Some PQC algorithms could be relatively
bulky and they might require fragmentation. Thus, a design goal bulky and they might require fragmentation. Thus, a design goal
is the adaptation and adoption of an existing fragmentation is the adaptation and adoption of an existing fragmentation
method or the design of a new method that allows for the method or the design of a new method that allows for the
fragmentation of the key shares. fragmentation of the key shares.
10) Backwards compatibility and interoperability. This is a 10) Backwards compatibility and interoperability. This is a
fundamental requirement to ensure that hybrid post-quantum IKEv2 fundamental requirement to ensure that hybrid post-quantum IKEv2
and a non-post-quantum IKEv2 implementations are interoperable. and non-post-quantum IKEv2 implementations are interoperable.
11) Federal Information Processing Standards (FIPS) compliance. 11) Federal Information Processing Standards (FIPS) compliance.
IPsec is widely used in Federal Information Systems and FIPS IPsec is widely used in Federal Information Systems and FIPS
certification is an important requirement. However, algorithms certification is an important requirement. However, algorithms
that are believed to be post-quantum are not FIPS compliant yet. that are believed to be post-quantum are not FIPS compliant yet.
Still, the goal is that the overall hybrid post-quantum IKEv2 Still, the goal is that the overall hybrid post-quantum IKEv2
design can be FIPS compliant. design can be FIPS compliant.
12) Ability to use this method with multiple classical (EC)DH key 12) Ability to use this method with multiple classical (EC)DH key
exchanges. In some situations peers have no single mutually exchanges. In some situations peers have no single mutually
trusted key exchange algorithm (e.g., due to local policy trusted key exchange algorithm (e.g., due to local policy
restrictions). The ability to combine two (or more) key restrictions). The ability to combine two (or more) key
exchange methods in such a way that the resulting shared key exchange methods in such a way that the resulting shared key
depends on all of them allows peers to communicate in this depends on all of them allows peers to communicate in this
situation. situation.
3. Multiple Key Exchanges 3. Multiple Key Exchanges
3.1. Overall design 3.1. Overall Design
This design assigns new Transform Type 4 identifiers to the various This design assigns new Transform Type 4 identifiers to the various
post-quantum key exchanges (which will be defined later). We post-quantum key exchanges (which will be defined later). We
specifically do not make a distinction between classical (DH and specifically do not make a distinction between classical (DH and
ECDH) and post-quantum key exchanges, nor post-quantum algorithms ECDH) and post-quantum key exchanges, nor post-quantum algorithms
which are true key exchanges versus post-quantum algorithms that act which are true key exchanges versus post-quantum algorithms that act
as key transport mechanisms; all are treated equivalently by the as key transport mechanisms; all are treated equivalently by the
protocol. To be more specific, this document renames Transform Type protocol. To be more specific, this document renames Transform Type
4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and
renames a field in the Key Exchange Payload from "Diffie-Hellman renames a field in the Key Exchange Payload from "Diffie-Hellman
skipping to change at page 8, line 33 skipping to change at page 8, line 33
that may have long public keys, the proposed framework utilizes the that may have long public keys, the proposed framework utilizes the
IKE_INTERMEDIATE exchange defined in IKE_INTERMEDIATE exchange defined in
[I-D.ietf-ipsecme-ikev2-intermediate]. [I-D.ietf-ipsecme-ikev2-intermediate].
In order to minimize communication overhead, only the key shares that In order to minimize communication overhead, only the key shares that
are agreed to be used are actually exchanged. In order to achieve are agreed to be used are actually exchanged. In order to achieve
this several new Transform Types are defined, each sharing possible this several new Transform Types are defined, each sharing possible
Transform IDs with Transform Type 4. The IKE_SA_INIT message Transform IDs with Transform Type 4. The IKE_SA_INIT message
includes one or more newly defined SA transforms that lists the extra includes one or more newly defined SA transforms that lists the extra
key exchange policy required by the initiator; the responder selects key exchange policy required by the initiator; the responder selects
single transform of each type, and returns them back in the response a single transform of each type, and returns them in the response
IKE_SA_INIT message. Then, provided that additional key exchanges IKE_SA_INIT message. Then, provided that additional key exchanges
are negotiated the initiator and the responder perform one or more are negotiated, the initiator and the responder perform one or more
IKE_INTERMEDIATE exchanges; each such exchange includes a KE payload IKE_INTERMEDIATE exchanges; each such exchange includes a KE payload
for one of the negotiated key exchanges. for one of the negotiated key exchanges.
Here is an overview of the initial exchanges: Here is an overview of the initial exchanges:
Initiator Responder Initiator Responder
--------------------------------------------------------------------- ---------------------------------------------------------------------
<-- IKE_SA_INIT (additional key exchanges negotiation) --> <-- IKE_SA_INIT (additional key exchanges negotiation) -->
<-- {IKE_INTERMEDIATE (additional key exchange)} --> <-- {IKE_INTERMEDIATE (additional key exchange)} -->
skipping to change at page 9, line 14 skipping to change at page 9, line 14
The additional key exchanges may use algorithms that are currently The additional key exchanges may use algorithms that are currently
considered to be resistant to quantum computer attacks. These considered to be resistant to quantum computer attacks. These
algorithms are collectively referred to as post-quantum algorithms in algorithms are collectively referred to as post-quantum algorithms in
this document. However, it is also possible to use classical (EC)DH this document. However, it is also possible to use classical (EC)DH
primitives for non post-quantum requirements. primitives for non post-quantum requirements.
Most post-quantum key agreement algorithms are relatively new, and Most post-quantum key agreement algorithms are relatively new, and
thus are not fully trusted. There are also many proposed algorithms, thus are not fully trusted. There are also many proposed algorithms,
with different trade-offs and relying on different hard problems. with different trade-offs and relying on different hard problems.
The concern is that some of these hard problems may turn out to be The concern is that some of these hard problems may turn out to be
easier to solve than anticipated (and thus the key agreement easier to solve than anticipated and thus the key agreement algorithm
algorithm not be as secure as expected). A hybrid solution allows us may not be as secure as expected. A hybrid solution allows us to
to deal with this uncertainty by combining a classical key exchange deal with this uncertainty by combining a classical key exchange with
with a post-quantum one, as well as leaving open the possibility of a post-quantum one, as well as leaving open the possibility of
multiple post-quantum key exchanges. multiple post-quantum key exchanges.
The method that we use to perform additional key exchanges also The method that we use to perform additional key exchanges also
addresses the fragmentation issue. The initial IKE_INIT messages do addresses the fragmentation issue. The initial IKE_INIT messages do
not have any inherent fragmentation support within IKE; however that not have any inherent fragmentation support within IKE; however that
can include a relatively short KE payload (e.g. one for group 14, 19 can include a relatively short KE payload (e.g. one for group 14, 19
or 31). The rest of the KE payloads are encrypted within or 31). The rest of the KE payloads are encrypted within
IKE_INTERMEDIATE messages; because they are encrypted, the standard IKE_INTERMEDIATE messages; because they are encrypted, the standard
IKE fragmentation solution [RFC7383] is available. IKE fragmentation solution [RFC7383] is available.
skipping to change at page 10, line 22 skipping to change at page 10, line 22
mechanism, via SA payload. For this purpose several new transform mechanism, via SA payload. For this purpose several new transform
types, namely Additional Key Exchange 1, Additional Key Exchange 2, types, namely Additional Key Exchange 1, Additional Key Exchange 2,
Additional Key Exchange 3, etc., are defined. They are collectively Additional Key Exchange 3, etc., are defined. They are collectively
called Additional Key Exchanges and have slightly different semantics called Additional Key Exchanges and have slightly different semantics
than existing IKEv2 transform types. They are interpreted as than existing IKEv2 transform types. They are interpreted as
additional key exchanges that peers agreed to perform in a series of additional key exchanges that peers agreed to perform in a series of
IKE_INTERMEDIATE exchanges. The possible transform IDs for these IKE_INTERMEDIATE exchanges. The possible transform IDs for these
transform types are the same as IDs for the Transform Type 4, so they transform types are the same as IDs for the Transform Type 4, so they
all share a single IANA registry for transform IDs. all share a single IANA registry for transform IDs.
Key exchange method negotiated via Transform Type 4 MUST always take Key exchange methods negotiated via Transform Type 4 MUST always take
place in the IKE_SA_INIT exchange. Additional key exchanges place in the IKE_SA_INIT exchange. Additional key exchanges
negotiated via newly defined transforms MUST take place in a series negotiated via newly defined transforms MUST take place in a series
of IKE_INTERMEDIATE exchanges, in an order of the values of their of IKE_INTERMEDIATE exchanges, in an order of the values of their
transform types, so that key exchange negotiated using Transform Type transform types, so that key exchange negotiated using Transform Type
n always precedes that of Transform Type n + 1. Each n always precedes that of Transform Type n + 1. Each
IKE_INTERMEDIATE exchange MUST bear exactly one key exchange method. IKE_INTERMEDIATE exchange MUST bear exactly one key exchange method.
Note that with this semantics, Additional Key Exchanges transforms Note that with this semantics, Additional Key Exchanges transforms
are not associated with any particular type of key exchange and don't are not associated with any particular type of key exchange and do
have any specific per transform type transform IDs IANA registry. not have any specific per transform type transform IDs IANA registry.
Instead they all share a single registry for transform IDs - "Key Instead they all share a single registry for transform IDs - "Key
Exchange Method Transform IDs", as well as Transform Type 4. All new Exchange Method Transform IDs", as well as Transform Type 4. All new
key exchange algorithms (both classical or post-quantum) should be key exchange algorithms (both classical or post-quantum) should be
added to this registry. This approach gives peers flexibility in added to this registry. This approach gives peers flexibility in
defining the ways they want to combine different key exchange defining the ways they want to combine different key exchange
methods. methods.
When forming a proposal the initiator adds transforms for the When forming a proposal the initiator adds transforms for the
IKE_SA_INIT exchange using Transform Type 4. In most cases they will IKE_SA_INIT exchange using Transform Type 4. In most cases they will
contain classical key exchange methods (DH or ECDH), however it is contain classical key exchange methods (DH or ECDH), however it is
skipping to change at page 11, line 10 skipping to change at page 11, line 10
n is among Additional Key Exchanges) in the proposal, the responder n is among Additional Key Exchanges) in the proposal, the responder
MUST select one of the algorithms proposed using this type. A MUST select one of the algorithms proposed using this type. A
transform ID NONE may be added to those transform types which contain transform ID NONE may be added to those transform types which contain
key exchange methods that the initiator believes are optional. key exchange methods that the initiator believes are optional.
If the initiator includes any Additional Key Exchanges transform If the initiator includes any Additional Key Exchanges transform
types into SA payload, it MUST also negotiate using IKE_INTERMEDIATE types into SA payload, it MUST also negotiate using IKE_INTERMEDIATE
exchange as described in [I-D.ietf-ipsecme-ikev2-intermediate], by exchange as described in [I-D.ietf-ipsecme-ikev2-intermediate], by
including INTERMEDIATE_EXCHANGE_SUPPORTED notification in the including INTERMEDIATE_EXCHANGE_SUPPORTED notification in the
IKE_SA_INIT request message. If the responder agrees to use IKE_SA_INIT request message. If the responder agrees to use
additional key exchanges, it MUST also return back this notification, additional key exchanges, it MUST also return this notification, thus
thus confirming that IKE_INTERMEDIATE exchange is supported and will confirming that IKE_INTERMEDIATE exchange is supported and will be
be used for transferring additional key exchange data. Presence of used for transferring additional key exchange data. The presence of
Additional Key Exchanges transform types in SA payload without Additional Key Exchanges transform types in SA payload without
negotiation of using IKE_INTERMEDIATE exchange MUST be treated as negotiation of using IKE_INTERMEDIATE exchange MUST be treated as
protocol error by both initiator and responder. protocol error by both initiator and responder.
The responder performs negotiation using standard IKEv2 procedure The responder performs negotiation using standard IKEv2 procedure
described in Section 3.3 of [RFC7296]. However, for the Additional described in Section 3.3 of [RFC7296]. However, for the Additional
Key Exchange types the responder's choice MUST NOT contain equal Key Exchange types the responder's choice MUST NOT contain equal
transform IDs (apart from NONE), and the ID selected for Transform transform IDs (apart from NONE), and the ID selected for Transform
Type 4 MUST NOT appear in any of Additional Key Exchange transforms. Type 4 MUST NOT appear in any of Additional Key Exchange transforms.
In other words, all selected key exchange methods must be different. In other words, all selected key exchange methods must be different.
skipping to change at page 12, line 10 skipping to change at page 12, line 10
not modified. not modified.
Once this exchange is done, then both sides compute an updated keying Once this exchange is done, then both sides compute an updated keying
material: material:
SKEYSEED(n) = prf(SK_d(n-1), KE(n) | Ni | Nr) SKEYSEED(n) = prf(SK_d(n-1), KE(n) | Ni | Nr)
where KE(n) is the resulting shared secret of this key exchange, Ni where KE(n) is the resulting shared secret of this key exchange, Ni
and Nr are nonces from the IKE_SA_INIT exchange and SK_d(n-1) is the and Nr are nonces from the IKE_SA_INIT exchange and SK_d(n-1) is the
last generated SK_d, (derived from the previous IKE_INTERMEDIATE last generated SK_d, (derived from the previous IKE_INTERMEDIATE
exchange, or the IKE_SA_INIT if there haven't already been any exchange, or the IKE_SA_INIT if there have not already been any
IKE_INTERMEDIATE exchanges). Then, SK_d, SK_ai, SK_ar, SK_ei, SK_er, IKE_INTERMEDIATE exchanges). Then, SK_d, SK_ai, SK_ar, SK_ei, SK_er,
SK_pi, SK_pr are updated as: SK_pi, SK_pr are updated as:
{SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) | {SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) |
SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr) SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr)
Both the initiator and the responder use this updated key values in Both the initiator and the responder use these updated key values in
the next exchange. the next exchange.
3.2.3. IKE_AUTH Exchange 3.2.3. IKE_AUTH Exchange
After all IKE_INTERMEDIATE exchanges have completed, the initiator After all IKE_INTERMEDIATE exchanges have completed, the initiator
and the responder perform an IKE_AUTH exchange. This exchange is the and the responder perform an IKE_AUTH exchange. This exchange is the
standard IKE exchange, except that the initiator and responder signed standard IKE exchange, except that the initiator and responder signed
octets are modified as described in octets are modified as described in
[I-D.ietf-ipsecme-ikev2-intermediate]. [I-D.ietf-ipsecme-ikev2-intermediate].
3.2.4. CREATE_CHILD_SA Exchange 3.2.4. CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA exchange is used in IKEv2 for the purpose of The CREATE_CHILD_SA exchange is used in IKEv2 for the purpose of
creating additional Child SAs, rekeying them and rekeying IKE SA creating additional Child SAs, rekeying them and rekeying IKE SA
itself. When creating or rekeying Child SAs, the peers may itself. When creating or rekeying Child SAs, the peers may
optionally perform a Diffie-Hellmann key exchange to add a fresh optionally perform a Diffie-Hellman key exchange to add a fresh
entropy into the session keys. In case of IKE SA rekey, the key entropy into the session keys. In case of IKE SA rekey, the key
exchange is mandatory. exchange is mandatory.
If the IKE SA was created using multiple key exchange methods, the If the IKE SA was created using multiple key exchange methods, the
peers may want to continue using multiple key exchanges in the peers may want to continue using multiple key exchanges in the
CREATE_CHILD_SA exchange too. If the initiator includes any CREATE_CHILD_SA exchange too. If the initiator includes any
Additional Key Exchanges transform in the SA payload (along with Additional Key Exchanges transform in the SA payload (along with
Transform Type 4) and the responder agrees to perform additional key Transform Type 4) and the responder agrees to perform additional key
exchanges, then the additional key exchanges are performed in a exchanges, then the additional key exchanges are performed in a
series of new IKE_FOLLOWUP_KE exchanges that follows the series of new IKE_FOLLOWUP_KE exchanges that follows the
skipping to change at page 13, line 19 skipping to change at page 13, line 19
to link the IKE_FOLLOWUP_KE exchanges together and with the to link the IKE_FOLLOWUP_KE exchanges together and with the
corresponding CREATE_CHILD_SA exchange. A new status type corresponding CREATE_CHILD_SA exchange. A new status type
notification ADDITIONAL_KEY_EXCHANGE is used for this purpose. Its notification ADDITIONAL_KEY_EXCHANGE is used for this purpose. Its
Notify Message Type is <TBA by IANA>, Protocol ID and SPI Size are Notify Message Type is <TBA by IANA>, Protocol ID and SPI Size are
both set to 0. The data associated with this notification is a blob both set to 0. The data associated with this notification is a blob
meaningful only to the responder, so that the responder can correctly meaningful only to the responder, so that the responder can correctly
link successive exchanges. For the initiator the content of this link successive exchanges. For the initiator the content of this
notification is an opaque blob. notification is an opaque blob.
The responder MUST include this notification in a CREATE_CHILD_SA or The responder MUST include this notification in a CREATE_CHILD_SA or
IKE_FOLLOWUP_KE response message in case next exchange is expected, IKE_FOLLOWUP_KE response message in case the next exchange is
filling it with some data that would allow linking this exchange to expected, filling it with some data that would allow linking this
the next one. The initiator MUST copy the received notification with exchange to the next one. The initiator MUST copy the received
its content intact into the request message of the next exchange. notification with its content intact into the request message of the
next exchange.
Below is an example of three additional key exchanges. Below is an example of three additional key exchanges.
Initiator Responder Initiator Responder
--------------------------------------------------------------------- ---------------------------------------------------------------------
HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->
<-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr,
N(ADDITIONAL_KEY_EXCHANGE)(link1)} N(ADDITIONAL_KEY_EXCHANGE)(link1)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(1), HDR(IKE_FOLLOWUP_KE), SK {KEi(1),
N(ADDITIONAL_KEY_EXCHANGE)(link1)} --> N(ADDITIONAL_KEY_EXCHANGE)(link1)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(1), <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(1),
N(ADDITIONAL_KEY_EXCHANGE)(link2)} N(ADDITIONAL_KEY_EXCHANGE)(link2)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(2), HDR(IKE_FOLLOWUP_KE), SK {KEi(2),
N(ADDITIONAL_KEY_EXCHANGE)(link2)} --> N(ADDITIONAL_KEY_EXCHANGE)(link2)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(2), <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(2),
N(ADDITIONAL_KEY_EXCHANGE)(link3)} N(ADDITIONAL_KEY_EXCHANGE)(link3)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(3), HDR(IKE_FOLLOWUP_KE), SK {KEi(3),
N(ADDITIONAL_KEY_EXCHANGE)(link3)} --> N(ADDITIONAL_KEY_EXCHANGE)(link3)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(3)} <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(3)}
The former "Diffie-Hellman Group Num" (now called "Key Exchange The former "Diffie-Hellman Group Num" (now called "Key Exchange
Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th
negotiated additional key exchange. negotiated additional key exchange.
It is possible that due to some unexpected events (e.g. reboot) the It is possible that due to some unexpected events (e.g. reboot) the
initiator could forget that it is in the process of performing initiator could forget that it is in the process of performing
additional key exchanges and never starts next IKE_FOLLOWUP_KE additional key exchanges and never starts next IKE_FOLLOWUP_KE
exchanges. The responder MUST handle this situation gracefully and exchanges. The responder MUST handle this situation gracefully and
delete the associated state if it doesn't receive the next expected delete the associated state if it does not receive the next expected
IKE_FOLLOWUP_KE request after some reasonable period of time. IKE_FOLLOWUP_KE request after some reasonable period of time.
If responder receives IKE_FOLLOWUP_KE request containing If responder receives IKE_FOLLOWUP_KE request containing
ADDITIONAL_KEY_EXCHANGE notification and the content of this notify ADDITIONAL_KEY_EXCHANGE notification and the content of this notify
doesn't correspond to any active key exchange state the responder does not correspond to any active key exchange state the responder
has, it MUST send back a new error type notification STATE_NOT_FOUND. has, it MUST send back a new error type notification STATE_NOT_FOUND.
This is a non-fatal error notification, its Notify Message Type is This is a non-fatal error notification, its Notify Message Type is
<TBA by IANA>, Protocol ID and SPI Size are both set to 0 and the <TBA by IANA>, Protocol ID and SPI Size are both set to 0 and the
data is empty. If the initiator receives this notification in data is empty. If the initiator receives this notification in
response to IKE_FOLLOWUP_KE exchange performing additional key response to IKE_FOLLOWUP_KE exchange performing additional key
exchange, it MUST cancel this exchange and MUST treat the whole exchange, it MUST cancel this exchange and MUST treat the whole
series of exchanges started from the CREATE_CHILD_SA exchange as series of exchanges started from the CREATE_CHILD_SA exchange as
failed. In most cases, the receipt of this notification is caused by failed. In most cases, the receipt of this notification is caused by
premature deletion of the corresponding state on the responder (the premature deletion of the corresponding state on the responder (the
time period between IKE_FOLLOWUP_KE exchanges appeared too long from time period between IKE_FOLLOWUP_KE exchanges appeared too long from
responder's point of view, e.g. due to a temporary network failure). responder's point of view, e.g. due to a temporary network failure).
After receiving this notification the initiator MAY start a new After receiving this notification the initiator MAY start a new
CREATE_CHILD_SA exchange (eventually followed by the IKE_FOLLOWUP_KE CREATE_CHILD_SA exchange (eventually followed by the IKE_FOLLOWUP_KE
exchanges) to retry the failed attempt. If the initiator continues exchanges) to retry the failed attempt. If the initiator continues
to receive STATE_NOT_FOUND notifications after several retries, it to receive STATE_NOT_FOUND notifications after several retries, it
MUST treat this situation as fatal error and delete IKE SA by sending MUST treat this situation as a fatal error and delete IKE SA by
a DELETE payload. sending a DELETE payload.
When rekeying IKE SA or Child SA, it is possible that the peers start When rekeying IKE SA or Child SA, it is possible that the peers start
doing this at the same time, which is called simultaneous rekeying. doing this at the same time, which is called simultaneous rekeying.
Sections 2.8.1 and 2.8.2 of [RFC7296] describes how IKEv2 handles Sections 2.8.1 and 2.8.2 of [RFC7296] describes how IKEv2 handles
this situation. In a nutshell IKEv2 follows the rule that if in case this situation. In a nutshell IKEv2 follows the rule that if in case
of simultaneous rekeying two identical new IKE SAs (or two pairs of of simultaneous rekeying two identical new IKE SAs (or two pairs of
Child SAs) are created, then one of them should be deleted. Which Child SAs) are created, then one of them should be deleted. Which
one is to be deleted is determined by comparing the values of four one is to be deleted is determined by comparing the values of four
nonces, that were used in the colliding CREATE_CHILD_SA exchanges - nonces, that were used in the colliding CREATE_CHILD_SA exchanges -
the IKE SA (or pair of Child SAs) that was created by the exchange in the IKE SA (or pair of Child SAs) that was created by the exchange in
skipping to change at page 15, line 9 skipping to change at page 15, line 12
side just stops the rekeying process - this side MUST not initiate side just stops the rekeying process - this side MUST not initiate
IKE_FOLLOWUP_KE exchange with next key exchange. IKE_FOLLOWUP_KE exchange with next key exchange.
In most cases, rekey collisions are resolved in the CREATE_CHILD_SA In most cases, rekey collisions are resolved in the CREATE_CHILD_SA
exchange. However, a situation may occur when due to packet loss, exchange. However, a situation may occur when due to packet loss,
one of the peers receives CREATE_CHILD_SA message requesting rekeying one of the peers receives CREATE_CHILD_SA message requesting rekeying
SA that is already being rekeyed by this peer (i.e. the SA that is already being rekeyed by this peer (i.e. the
CREATE_CHILD_SA exchange initiated by this peer has been already CREATE_CHILD_SA exchange initiated by this peer has been already
completed and the series of IKE_FOLLOWUP_KE exchanges is in completed and the series of IKE_FOLLOWUP_KE exchanges is in
progress). In this case, a TEMPORARY_FAILURE notification MUST be progress). In this case, a TEMPORARY_FAILURE notification MUST be
sent in response to such request. sent in response to such a request.
If multiple key exchanges were negotiated in the CREATE_CHILD_SA If multiple key exchanges were negotiated in the CREATE_CHILD_SA
exchange, then the resulting keys are computed as follows. In case exchange, then the resulting keys are computed as follows. In case
of IKE SA rekey: of IKE SA rekey:
SKEYSEED = prf(SK_d, KE | Ni | Nr | KE(1) | ... KE(n)) SKEYSEED = prf(SK_d, KE | Ni | Nr | KE(1) | ... KE(n))
In case of Child SA creation or rekey: In case of Child SA creation or rekey:
KEYMAT = prf+ (SK_d, KE | Ni | Nr | KE(1) | ... KE(n)) KEYMAT = prf+ (SK_d, KE | Ni | Nr | KE(1) | ... KE(n))
skipping to change at page 15, line 38 skipping to change at page 15, line 41
registry: registry:
<TBA> IKE_FOLLOWUP_KE <TBA> IKE_FOLLOWUP_KE
This document renames Transform Type 4 defined in "Transform Type This document renames Transform Type 4 defined in "Transform Type
Values" registry from "Diffie-Hellman Group (D-H)" to "Key Exchange Values" registry from "Diffie-Hellman Group (D-H)" to "Key Exchange
Method (KE)". Method (KE)".
This document renames IKEv2 registry "Transform Type 4 - Diffie- This document renames IKEv2 registry "Transform Type 4 - Diffie-
Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange
Method Transform IDs" Method Transform IDs".
This document adds the following Transform Types to the "Transform This document adds the following Transform Types to the "Transform
Type Values" registry: Type Values" registry:
Type Description Used In Type Description Used In
----------------------------------------------------------------- -----------------------------------------------------------------
<TBA> Additional Key Exchange 1 (optional in IKE, AH, ESP) <TBA> Additional Key Exchange 1 (optional in IKE, AH, ESP)
<TBA> Additional Key Exchange 2 (optional in IKE, AH, ESP) <TBA> Additional Key Exchange 2 (optional in IKE, AH, ESP)
<TBA> Additional Key Exchange 3 (optional in IKE, AH, ESP) <TBA> Additional Key Exchange 3 (optional in IKE, AH, ESP)
<TBA> Additional Key Exchange 4 (optional in IKE, AH, ESP) <TBA> Additional Key Exchange 4 (optional in IKE, AH, ESP)
skipping to change at page 17, line 41 skipping to change at page 18, line 7
negotiate the post-quantum algorithms using the existing KE payload. negotiate the post-quantum algorithms using the existing KE payload.
The authors are also grateful to Tobias Heider and Tobias Guggemos The authors are also grateful to Tobias Heider and Tobias Guggemos
for valuable comments. for valuable comments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-ipsecme-ikev2-intermediate] [I-D.ietf-ipsecme-ikev2-intermediate]
Smyslov, V., "Intermediate Exchange in the IKEv2 Smyslov, V., "Intermediate Exchange in the IKEv2
Protocol", draft-ietf-ipsecme-ikev2-intermediate-03 (work Protocol", draft-ietf-ipsecme-ikev2-intermediate-04 (work
in progress), December 2019. in progress), June 2020.
[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, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-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>.
skipping to change at page 18, line 15 skipping to change at page 18, line 30
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 7.2. Informative References
[GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for [GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for
Database Search", Proc. of the Twenty-Eighth Annual ACM Database Search", Proc. of the Twenty-Eighth Annual ACM
Symposium on the Theory of Computing (STOC 1996), 1996. Symposium on the Theory of Computing (STOC 1996), 1996.
[I-D.ietf-ipsecme-qr-ikev2]
Fluhrer, S., McGrew, D., Kampanakis, P., and V. Smyslov,
"Mixing Preshared Keys in IKEv2 for Post-quantum
Resistance", draft-ietf-ipsecme-qr-ikev2-10 (work in
progress), December 2019.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383, (IKEv2) Message Fragmentation", RFC 7383,
skipping to change at page 18, line 43 skipping to change at page 19, line 5
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>. August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. [RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A.
Mohaisen, "XMSS: eXtended Merkle Signature Scheme", Mohaisen, "XMSS: eXtended Merkle Signature Scheme",
RFC 8391, DOI 10.17487/RFC8391, May 2018, RFC 8391, DOI 10.17487/RFC8391, May 2018,
<https://www.rfc-editor.org/info/rfc8391>. <https://www.rfc-editor.org/info/rfc8391>.
[RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov,
"Mixing Preshared Keys in the Internet Key Exchange
Protocol Version 2 (IKEv2) for Post-quantum Security",
RFC 8784, DOI 10.17487/RFC8784, June 2020,
<https://www.rfc-editor.org/info/rfc8784>.
Appendix A. Alternative Design Appendix A. Alternative Design
This section gives an overview on a number of alternative approaches This section gives an overview on a number of alternative approaches
that we have considered, but later discarded. These approaches are: that we have considered, but later discarded. These approaches are:
o Sending the classical and post-quantum key exchanges as a single o Sending the classical and post-quantum key exchanges as a single
transform transform
We considered combining the various key exchanges into a single We considered combining the various key exchanges into a single
large KE payload; this effort is documented in a previous version large KE payload; this effort is documented in a previous version
skipping to change at page 22, line 28 skipping to change at page 22, line 45
Post-Quantum Post-Quantum
Email: cjt@post-quantum.com Email: cjt@post-quantum.com
M. Tomlinson M. Tomlinson
Post-Quantum Post-Quantum
Email: mt@post-quantum.com Email: mt@post-quantum.com
G. Bartlett G. Bartlett
Cisco Systems Quantum Secret
Email: grbartle@cisco.com
Email: graham.ietf@gmail.com
S. Fluhrer S. Fluhrer
Cisco Systems Cisco Systems
Email: sfluhrer@cisco.com Email: sfluhrer@cisco.com
D. Van Geest D. Van Geest
ISARA Corporation ISARA Corporation
Email: daniel.vangeest@isara.com Email: daniel.vangeest@isara.com
 End of changes. 46 change blocks. 
85 lines changed or deleted 87 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/