< draft-ietf-ipsecme-ikev2-multiple-ke-03.txt   draft-ietf-ipsecme-ikev2-multiple-ke-04.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: January 7, 2022 Quantum Secret Expires: 3 April 2022 Quantum Secret
S. Fluhrer 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
July 6, 2021 30 September 2021
Multiple Key Exchanges in IKEv2 Multiple Key Exchanges in IKEv2
draft-ietf-ipsecme-ikev2-multiple-ke-03 draft-ietf-ipsecme-ikev2-multiple-ke-04
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 a shared secret during a Security Association place while computing a shared secret during a Security Association
(SA) setup. The primary application of this feature in IKEv2 is the (SA) setup. The primary application of this feature in IKEv2 is the
ability to perform one or more post-quantum key exchanges in ability to perform one or more post-quantum key exchanges in
conjunction with the classical (Elliptic Curve) Diffie-Hellman key conjunction with the classical (Elliptic Curve) Diffie-Hellman key
exchange, so that the resulting shared key is resistant against exchange, so that the resulting shared key is resistant against
skipping to change at page 2, line 12 skipping to change at page 2, line 15
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 January 7, 2022. This Internet-Draft will expire on 3 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Document Organization . . . . . . . . . . . . . . . . . . 6 1.4. Document Organization . . . . . . . . . . . . . . . . . . 7
2. Design Criteria . . . . . . . . . . . . . . . . . . . . . . . 6 2. Design Criteria . . . . . . . . . . . . . . . . . . . . . . . 7
3. Multiple Key Exchanges . . . . . . . . . . . . . . . . . . . 8 3. Multiple Key Exchanges . . . . . . . . . . . . . . . . . . . 9
3.1. Overall Design . . . . . . . . . . . . . . . . . . . . . 8 3.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 9
3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . 10 3.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 11
3.2.1. IKE_SA_INIT Round: Negotiation . . . . . . . . . . . 10 3.2.1. IKE_SA_INIT Round: Negotiation . . . . . . . . . . . 11
3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges . . 12 3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges . . 15
3.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 13 3.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 15
3.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 13 3.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 16
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 3.2.5. Interaction with Childless IKE SA . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Alternative Design . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Sample Multiple Key Exchanges . . . . . . . . . . . 24
A.1. No Additional Key Exchange Used . . . . . . . . . . . . . 24
A.2. Additional Key Exchange in the CREATE_CHILD_SA Exchange
only . . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.3. Not Matching Proposal for Additional Key Exchanges . . . 26
Appendix B. Alternative Design . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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
skipping to change at page 4, line 46 skipping to change at page 5, line 19
requirement. However, if such a requirement is needed, requirement. However, if such a requirement is needed,
[I-D.tjhai-ikev2-beyond-64k-limit] discusses approaches that should [I-D.tjhai-ikev2-beyond-64k-limit] discusses approaches that should
be taken to exchange huge payloads. be taken to exchange huge payloads.
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-04
* Introduction and initial sections are reorganized.
* More clarifications for error handling added.
* ASCII arts displaying SA payload are added.
* Clarification for handling multiple round trips key exchange
methods added.
* DoS concerns added into Security Considerations section.
* Explicitly allow scenario when additional key exchanges are
performed only after peers are authenticated.
draft-ietf-ipsecme-ikev2-multiple-ke-03 draft-ietf-ipsecme-ikev2-multiple-ke-03
o More clarifications added. * More clarifications added.
o Figure illustrating initial exchange added. * Figure illustrating initial exchange added.
o Minor editorial changes. * Minor editorial changes.
draft-ietf-ipsecme-ikev2-multiple-ke-02 draft-ietf-ipsecme-ikev2-multiple-ke-02
o Added a reference on the handling of KE payloads larger than 64KB. * Added a reference on the handling of KE payloads larger than 64KB.
draft-ietf-ipsecme-ikev2-multiple-ke-01 draft-ietf-ipsecme-ikev2-multiple-ke-01
o References are updated. * References are updated.
draft-ietf-ipsecme-ikev2-multiple-ke-00 draft-ietf-ipsecme-ikev2-multiple-ke-00
* 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 * 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. * Nonces are removed from all additional key exchanges.
o Clarification that IKE_INTERMEDIATE must be negotiated is added. * Clarification that IKE_INTERMEDIATE must be negotiated is added.
draft-tjhai-ipsecme-hybrid-qske-ikev2-04 draft-tjhai-ipsecme-hybrid-qske-ikev2-04
o Clarification about key derivation in case of multiple key * 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 * 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. * Using multiple key exchanges CREATE_CHILD_SA is defined.
draft-tjhai-ipsecme-hybrid-qske-ikev2-02 draft-tjhai-ipsecme-hybrid-qske-ikev2-02
o Use new transform types to negotiate additional key exchanges, * Use new transform types to negotiate additional key exchanges,
rather than using the KE payloads of IKE SA. rather than using the KE payloads of IKE SA.
draft-tjhai-ipsecme-hybrid-qske-ikev2-01 draft-tjhai-ipsecme-hybrid-qske-ikev2-01
o Use IKE_INTERMEDIATE to perform multiple key exchanges in * Use IKE_INTERMEDIATE to perform multiple key exchanges in
succession. succession.
o Handle fragmentation by keeping the first key exchange (a standard * Handle fragmentation by keeping the first key exchange (a standard
IKE_SA_INIT with a few extra notifies) small, and encrypting the IKE_SA_INIT with a few extra notifies) small, and encrypting the
rest of the key exchanges. rest of the key exchanges.
o Simplify the negotiation of the 'extra' key exchanges. * Simplify the negotiation of the 'extra' key exchanges.
draft-tjhai-ipsecme-hybrid-qske-ikev2-00 draft-tjhai-ipsecme-hybrid-qske-ikev2-00
o We added a feature to allow more than one post-quantum key * We added a feature to allow more than one post-quantum key
exchange algorithms to be negotiated and used to exchange a post- exchange algorithms to be negotiated and used to exchange a post-
quantum shared secret. quantum shared secret.
o Instead of relying on TCP encapsulation to deal with IP level * Instead of relying on TCP encapsulation to deal with IP level
fragmentation, we introduced a new key exchange payload that can fragmentation, we introduced a new key exchange payload that can
be sent as multiple fragments within IKE_SA_INIT message. be sent as multiple fragments within IKE_SA_INIT message.
1.4. Document Organization 1.4. Document Organization
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows. Section 2
summarizes design criteria. Section 3 describes how multiple key summarizes design criteria. Section 3 describes how multiple key
exchanges are performed between two IKE peers and how keying exchanges are performed between two IKE peers and how keying
materials are derived for both SAs and Child SAs. A summary of materials are derived for both SAs and Child SAs. A summary of
alternative approaches that have been considered, but later alternative approaches that have been considered, but later
discarded, are described in Appendix A. Section 4 discusses IANA discarded, are described in Appendix B. Section 4 discusses IANA
considerations for the namespaces introduced in this document, and considerations for the namespaces introduced in this document, and
lastly Section 5 discusses security considerations. lastly Section 5 discusses security considerations.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Design Criteria 2. Design Criteria
skipping to change at page 8, line 28 skipping to change at page 9, line 22
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. Design Overview
This design assigns new Transform Type 4 identifiers to the various Most post-quantum key agreement algorithms are relatively new, and
post-quantum key exchanges (which will be defined later). We thus are not fully trusted. There are also many proposed algorithms,
specifically do not make a distinction between classical (DH and with different trade-offs and relying on different hard problems.
ECDH) and post-quantum key exchanges, nor post-quantum algorithms The concern is that some of these hard problems may turn out to be
which are true key exchanges versus post-quantum algorithms that act easier to solve than anticipated and thus the key agreement algorithm
as key transport mechanisms; all are treated equivalently by the may not be as secure as expected. A hybrid solution, when multiple
protocol. To be more specific, this document renames Transform Type key exchanges are performed and the calculated shared key depends on
4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and all of them, allows us to deal with this uncertainty by combining a
renames a field in the Key Exchange Payload from "Diffie-Hellman classical key exchange with a post-quantum one, as well as leaving
Group Num" to "Key Exchange Method". The corresponding IANA registry open the possibility of multiple post-quantum key exchanges.
is also renamed from "Diffie-Hellman Group Transform IDs" to "Key
Exchange Method Transform IDs".
In order to support IKE fragmentation for additional key exchanges In order to be able to use IKE fragmentation [RFC7383] for those key
that may have long public keys, the proposed framework utilizes the exchanges that may have long public keys, the proposed framework
IKE_INTERMEDIATE exchange defined in utilizes the IKE_INTERMEDIATE exchange defined in
[I-D.ietf-ipsecme-ikev2-intermediate]. [I-D.ietf-ipsecme-ikev2-intermediate]. The initial IKE_INIT messages
do not have any inherent fragmentation support within IKE; however
that can include a relatively short KE payload. The additional key
exchanges are performed using IKE_INTERMEDIATE messages; because
these messages are encrypted, the standard IKE fragmentation
mechanism is available.
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. To negotiate
this several new Transform Types are defined, each sharing allowed additional key exchanges seven new Transform Types are defined.
Transform IDs with Transform Type 4. The IKE_SA_INIT message These transforms share allowed Transform IDs with Transform Type 4.
includes one or more newly defined SA transforms that lists the extra
key exchange policy required by the initiator; the responder selects
a single transform of each type, and returns them in the response
IKE_SA_INIT message. Then, provided that additional key exchanges
are negotiated, the initiator and the responder perform one or more
IKE_INTERMEDIATE exchanges; every such exchange includes a KE payload
for the next method from the negotiated list.
Here is an overview of the initial exchanges: We assume that new Transform Type 4 identifiers will be assigned
later to the various post-quantum key exchanges. We specifically do
not make a distinction between classical (DH and ECDH) and post-
quantum key exchanges, nor post-quantum algorithms which are true key
exchanges versus post-quantum algorithms that act as key transport
mechanisms; all are treated equivalently by the protocol. To be more
specific, this document renames Transform Type 4 from "Diffie-Hellman
Group (D-H)" to "Key Exchange Method (KE)" and renames a field in the
Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange
Method". The corresponding IANA registry is also renamed from
"Diffie-Hellman Group Transform IDs" to "Key Exchange Method
Transform IDs".
The fact, that newly defined transforms share the same registry for
possible Transform IDs with Transform Type 4, allows additional key
exchanges to be of any type - either post-quantum or classical (EC)DH
one. This approach allows any combination of defined key exchange
methods to take place. This also allows performing a single post-
quantum key exchange in the IKE_SA_INIT without additional key
exchanges, provided that IP fragmentation is not an issue and that
hybrid key exchange is not needed.
The SA payload in the IKE_SA_INIT message includes one or more newly
defined transforms which represent the extra key exchange policy
required by the initiator. The responder follows the usual IKEv2
negotiation rules: it selects a single transform of each type, and
returns all of them in the IKE_SA_INIT response message.
Then, provided that additional key exchanges are negotiated, the
initiator and the responder perform one or more IKE_INTERMEDIATE
exchanges. Then the IKE_AUTH exchange authenticates peers and
completes IKE SA establishment.
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)} -->
... ...
<-- {IKE_INTERMEDIATE (additional key exchange)} --> <-- {IKE_INTERMEDIATE (additional key exchange)} -->
<-- {IKE_AUTH} --> <-- {IKE_AUTH} -->
Note, that this document assumes, that each key exchange method
requires one round trip and consumes exactly one IKE_INTERMEDIATE
exchange. This assumption is valid for all classic key exchange
methods defined so far and for all post-quantum methods currently
known. For hypothetical future key exchange methods requiring
multiple round trips to complete, a separate document should define
how such methods are splitted into several IKE_INTERMEDIATE
exchanges.
The additional key exchanges may use algorithms that are currently 3.2. Protocol Details
considered to be resistant to quantum computer attacks. These
algorithms are collectively referred to as post-quantum algorithms in
this document. However, it is also possible to use classical (EC)DH
primitives for non post-quantum requirements.
Most post-quantum key agreement algorithms are relatively new, and
thus are not fully trusted. There are also many proposed algorithms,
with different trade-offs and relying on different hard problems.
The concern is that some of these hard problems may turn out to be
easier to solve than anticipated and thus the key agreement algorithm
may not be as secure as expected. A hybrid solution allows us to
deal with this uncertainty by combining a classical key exchange with
a post-quantum one, as well as leaving open the possibility of
multiple post-quantum key exchanges.
The method that we use to perform additional key exchanges also
addresses the fragmentation issue. The initial IKE_INIT messages do
not have any inherent fragmentation support within IKE; however that
can include a relatively short KE payload. The rest of the KE
payloads are transferred within IKE_INTERMEDIATE messages; because
these messages are encrypted, the standard IKE fragmentation solution
[RFC7383] is available.
The fact, that all Additional Key Exchange Transform Types share the
same registry with Transform Type 4, allows additional key exchanges
to be of any type - either post-quantum ones or classical (EC)DH
ones. This approach allows any combination of defined key exchange
methods to take place. This also allows performing a single post-
quantum key exchange in the IKE_SA_INIT without additional key
exchanges, provided that IP fragmentation is not an issue and that
hybrid key exchange is not needed.
3.2. Overall Protocol
In the simplest case, the initiator is happy with a single key In the simplest case, the initiator is happy with a single key
exchange (and has no interest in supporting multiple), and it is not exchange (and has no interest in supporting multiple), and it is not
concerned with possible fragmentation of the IKE_SA_INIT messages concerned with possible fragmentation of the IKE_SA_INIT messages
(either because the key exchange it selects is small enough not to (either because the key exchange it selects is small enough not to
fragment, or the initiator is confident that fragmentation will be fragment, or the initiator is confident that fragmentation will be
handled either by IP fragmentation, or transport via TCP). handled either by IP fragmentation, or transport via TCP).
In this case, the initiator performs the IKE_SA_INIT as usual, In this case, the initiator performs the IKE_SA_INIT as usual,
inserting a preferred key exchange (which is possibly a post-quantum inserting a preferred key exchange (which is possibly a post-quantum
algorithm) as the listed Transform Type 4, and including the algorithm) as the listed Transform Type 4, and including the
initiator KE payload. If the responder accepts the policy, it initiator KE payload. If the responder accepts the policy, it
responds with an IKE_SA_INIT response, and IKE continues as usual. responds with an IKE_SA_INIT response, and IKE continues as usual.
If the initiator desires to negotiate multiple key exchanges, then If the initiator desires to negotiate multiple key exchanges, then
the initiator uses the protocol listed below. the initiator uses the protocol listed below.
3.2.1. IKE_SA_INIT Round: Negotiation 3.2.1. IKE_SA_INIT Round: Negotiation
Multiple key exchanges are negotiated using the standard IKEv2 Multiple key exchanges are negotiated using the standard IKEv2
mechanism, via SA payload. For this purpose several new transform mechanism, via SA payload. For this purpose seven new transform
types, namely Additional Key Exchange 1, Additional Key Exchange 2, types, namely Additional Key Exchange 1 (<TBA by IANA>), Additional
Additional Key Exchange 3, etc., are defined. They are collectively Key Exchange 2 (<TBA by IANA>), Additional Key Exchange 3 (<TBA by
called Additional Key Exchanges and have slightly different semantics IANA>), Additional Key Exchange 4 (<TBA by IANA>), Additional Key
than existing IKEv2 transform types. They are interpreted as Exchange 5 (<TBA by IANA>), Additional Key Exchange 6 (<TBA by IANA>)
additional key exchanges that peers agreed to perform in a series of and Additional Key Exchange 7 (<TBA by IANA>) are defined. They are
IKE_INTERMEDIATE exchanges. The allowed transform IDs for these collectively called Additional Key Exchange transforms in this
transform types are the same as IDs for the Transform Type 4, so they document and have slightly different semantics than existing IKEv2
all share a single IANA registry for transform IDs. transform types. They are interpreted as an indication of additional
key exchanges methods that peers agreed to perform in a series of
IKE_INTERMEDIATE exchanges following the IKE_SA_INIT exchange. The
allowed transform IDs for these transform types are the same as IDs
for the Transform Type 4, so they all share a single IANA registry
for transform IDs.
Key exchange methods negotiated via Transform Type 4 MUST always take Key exchange method negotiated via Transform Type 4 always takes
place in the IKE_SA_INIT exchange. Additional key exchanges place in the IKE_SA_INIT exchange, as defined in [RFC7296].
negotiated via newly defined transforms MUST take place in a series Additional key exchanges negotiated via newly defined transforms MUST
of IKE_INTERMEDIATE exchanges, in an order of the values of their take place in a series of IKE_INTERMEDIATE exchanges following the
IKE_SA_INIT exchange, performed 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 additional key
IKE_INTERMEDIATE exchange MUST bear exactly one key exchange method. exchange method MUST be fully completed before the next one is
started.
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 do are not associated with any particular type of key exchange and do
not 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
not a requirement. Additional key exchange methods are proposed not a requirement. Additional key exchange methods are proposed
using Additional Key Exchanges transform types. All these transform using Additional Key Exchanges transform types. All these transform
types are optional, the initiator is free to select any of them for types are optional, the initiator is free to select any of them for
proposing additional key exchange methods. Consequently, if none of proposing additional key exchange methods. Consequently, if none of
Additional Key Exchange transforms are included in the proposal, then Additional Key Exchange transforms are included in the proposal, then
this proposal indicates performing standard IKEv2, as defined in this proposal indicates performing standard IKEv2, as defined in
[RFC7296]. If the initiator includes any transform of type n (where [RFC7296]. If the initiator includes any Additional Key Exchanges
n is among Additional Key Exchanges) in the proposal, the responder transform in the proposal, the responder MUST select one of the
MUST select one of the algorithms proposed using this type. A algorithms proposed using this type. A transform ID NONE MAY be
transform ID NONE may be added to those transform types which contain added to those transform types which contain key exchange methods
key exchange methods that the initiator believes are optional. that the initiator believes are optional according to its local
policy.
The responder performs negotiation using standard IKEv2 procedure
described in Section 3.3 of [RFC7296]. However, for the Additional
Key Exchange types the responder's choice MUST NOT contain equal
algorithms, except for transform ID of NONE. An algorithm is
represented as a transform, in some cases the transform could include
a set of associated attributes that define details of the algorithm.
In this case two ransforms can be the same, but the attributes must
be different. Additionally, the order of the attributes does not
affect the equality of the algorithm, so two transforms
(ID=alg1,ATTR1=attr1,ATTR2=attr2) and
(ID=alg1,ATTR2=attr2,ATTR1=attr1) define the same algorithm.
If the responder selected NONE for some Additional Key Exchange types
(provided they were proposed by the initiator), then the
corresponding IKE_INTERMEDIATE exchanges should not take place. The
IKE_INTERMEDIATE exchanges MUST only be performed for Additional Key
Exchange types containing non-NONE responders choices. It means that
if the initiator includes NONE in all Additional Key Exchange
transforms and the responder selects this value for all of them, then
no IKE_INTERMEDIATE exchanges will take place between the peers.
perform additional key exchanges will take place (note that they
still may take place for other purposes).
Below is an example of the SA payload in the initiator's IKE_SA_INIT
request message. Here we use an abbreviation AKE1, AKE 2 etc. to
denote Additional Key Exchange 1, Additional Key Exchange 2 etc.
transforms, that this document defines, and an abbreviation KE for
the Key Exchange transform, that this document renames from the
Diffie-Hellman Group transform. We also use not yet defined
Transform IDs PQ_KEM_1, PQ_KEM_2 and PQ_KEM_3 to denote some of
popular post-quantum key exchange methods.
SA Payload
|
+--- Proposal #1 ( Proto ID = IKE(1), SPI size = 8,
| 9 transforms, SPI = 0x35a1d6f22564f89d )
|
+-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
| +-- Attribute ( Key Length = 256 )
|
+-- Transform KE ( ID = 4096-bit MODP Group )
|
+-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
|
+-- Transform AKE2 ( ID = PQ_KEM_1 )
|
+-- Transform AKE2 ( ID = PQ_KEM_2 )
|
+-- Transform AKE3 ( ID = PQ_KEM_1 )
|
+-- Transform AKE3 ( ID = PQ_KEM_2 )
|
+-- Transform AKE5 ( ID = PQ_KEM_3 )
|
+-- Transform AKE5 ( ID = NONE )
In this example the initiator proposes to perform initial key
exchange using 4096-bit MODP group following by two mandatory
additional key exchanges using PQ_KEM_1 and PQ_KEM_2 methods in any
order, following by additional key exchange using PQ_KEM_3 method
that may be omitted.
The responder might return the following SA payload, indicating that
it agrees to perform two additional key exchanges PQ_KEM_2 followed
by PQ_KEM_1 and doesn't want to perform PQ_KEM_3 additionally.
SA Payload
|
+--- Proposal #1 ( Proto ID = IKE(1), SPI size = 8,
| 6 transforms, SPI = 0x8df52b331a196e7b )
|
+-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
| +-- Attribute ( Key Length = 256 )
|
+-- Transform KE ( ID = 4096-bit MODP Group )
|
+-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
|
+-- Transform AKE2 ( ID = PQ_KEM_2 )
|
+-- Transform AKE3 ( ID = PQ_KEM_1 )
|
+-- Transform AKE5 ( ID = NONE )
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 in the IKE_SA_INIT exchange request message, it
exchange as described in [I-D.ietf-ipsecme-ikev2-intermediate], by MUST also negotiate using IKE_INTERMEDIATE exchange as described in
including INTERMEDIATE_EXCHANGE_SUPPORTED notification in the [I-D.ietf-ipsecme-ikev2-intermediate], by including
IKE_SA_INIT request message. If the responder agrees to use INTERMEDIATE_EXCHANGE_SUPPORTED notification in the same message. If
additional key exchanges, it MUST also return this notification, thus the responder agrees to use additional key exchanges while
confirming that IKE_INTERMEDIATE exchange is supported and will be establishing initial IKE SA, it MUST also return this notification in
used for transferring additional key exchange data. The presence of the IKE_SA_INIT response message, thus confirming that
Additional Key Exchanges transform types in SA payload without IKE_INTERMEDIATE exchange is supported and will be used for
negotiation of using IKE_INTERMEDIATE exchange MUST be treated as transferring additional key exchange data. If the IKE_INTERMEDIATE
protocol error by both initiator and responder. exchange is not negotiated, then the peers MUST treat any Additional
Key Exchange transforms in the IKE_SA_INIT exchange messages as
unknown transform types and skip the proposals they appear in. If no
other proposals are present in the SA payload, the peers will proceed
as when no proposal is chosen (i.e. the responder will send
NO_PROPOSAL_CHOSEN notification).
Initiator Responder Initiator Responder
--------------------------------------------------------------------- ---------------------------------------------------------------------
HDR, SAi1(.. AKE*...), KEi1, Ni, HDR, SAi1(.. AKE*...), KEi1, Ni,
N(INTERMEDIATE_EXCHANGE_SUPPORTED) ---> N(INTERMEDIATE_EXCHANGE_SUPPORTED) --->
HDR, SAr1(.. AKE*...), KEr1, Nr, HDR, SAr1(.. AKE*...), KEr1, Nr,
[CERTREQ], [CERTREQ],
<--- N(INTERMEDIATE_EXCHANGE_SUPPORTED) <--- N(INTERMEDIATE_EXCHANGE_SUPPORTED)
The responder performs negotiation using standard IKEv2 procedure
described in Section 3.3 of [RFC7296]. However, for the Additional
Key Exchange types the responder's choice MUST NOT contain equal
transform IDs (apart from NONE), and the ID selected for Transform
Type 4 MUST NOT appear in any of Additional Key Exchange transforms.
In other words, all selected key exchange methods must be different.
If the responder selected NONE for some Additional Key Exchange types
(provided they were proposed by the initiator), then the
corresponding IKE_INTERMEDIATE exchanges should not take place. The
IKE_INTERMEDIATE exchanges MUST only be performed for Additional Key
Exchange types containing non-NONE responders choices.
3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges 3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges
For each extra key exchange agreed to in the IKE_SA_INIT exchange, For each additional key exchange agreed to in the IKE_SA_INIT
the initiator and the responder perform one IKE_INTERMEDIATE exchange, the initiator and the responder perform IKE_INTERMEDIATE
exchange, as described in [I-D.ietf-ipsecme-ikev2-intermediate]. exchange, as described in [I-D.ietf-ipsecme-ikev2-intermediate].
These exchanges are as follows:
Initiator Responder Initiator Responder
--------------------------------------------------------------------- ---------------------------------------------------------------------
HDR, SK {KEi(n)} --> HDR, SK {KEi(n)} -->
<-- HDR, SK {KEr(n)} <-- HDR, SK {KEr(n)}
The initiator sends key exchange data in the KEi(n) payload. This The initiator sends key exchange data in the KEi(n) payload. This
packet is protected with the current SK_ei/SK_ai keys. packet is protected with the current SK_ei/SK_ai keys.
On receiving this, the responder sends back key exchange payload On receiving this, the responder sends back key exchange payload
KEr(n); again, this packet is protected with the current SK_er/SK_ar KEr(n); again, this packet is protected with the current SK_er/SK_ar
keys. keys.
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. Note that the negotiated negotiated additional key exchange.
transform types (the encryption type, integrity type, prf type) are
not modified.
Once this exchange is done, both sides compute an updated keying Once this exchange is done, 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), SK(n) | Ni | Nr)
where KE(n) is the resulting shared secret of this key exchange, Ni where SK(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 have not 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 these updated key values in Both the initiator and the responder use these updated key values in
skipping to change at page 13, line 23 skipping to change at page 16, line 12
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 purposes of The CREATE_CHILD_SA exchange is used in IKEv2 for the purposes 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-Hellman 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. Peers supporting this specification may want
to use multiple key exchanges in these situations.
If the IKE SA was created using multiple key exchange methods, the Using multiple key exchanges with CREATE_CHILD_SA exchange is
peers may want to continue using multiple key exchanges in the negotiated similarly as in initial exchange, see Section 3.2.1. If
CREATE_CHILD_SA exchange too. If the initiator includes any the initiator includes any Additional Key Exchanges transform in the
Additional Key Exchanges transform in the SA payload (along with SA payload (along with Transform Type 4) and the responder agrees to
Transform Type 4) and the responder agrees to perform additional key perform additional key exchanges, then the additional key exchanges
exchanges, then the additional key exchanges are performed in a are performed in a series of new IKE_FOLLOWUP_KE exchanges that
series of new IKE_FOLLOWUP_KE exchanges that follows the follows the CREATE_CHILD_SA exchange. The IKE_FOLLOWUP_KE exchange
CREATE_CHILD_SA exchange. The IKE_FOLLOWUP_KE exchange is introduced is introduced as a dedicated exchange for transferring data of
as a dedicated exchange for transferring data of additional key additional key exchanges following the key exchange performed in the
exchanges following the key exchange performed in the
CREATE_CHILD_SA. Its Exchange Type is <TBA by IANA>. CREATE_CHILD_SA. Its Exchange Type is <TBA by IANA>.
Additional key exchanges are performed in an order of the values of Key exchange negotiated via Transform Type 4 always takes place in
their transform types, so that key exchange negotiated using the CREATE_CHILD_SA exchange, as per IKEv2 specification. Additional
Transform Type n always precedes key exchange negotiated using key exchanges are performed in an order of the values of their
Transform Type n + 1. Each IKE_FOLLOWUP_KE exchange MUST bear transform types, so that key exchange negotiated using Transform Type
exactly one key exchange method. Key exchange negotiated via n always precedes key exchange negotiated using Transform Type n + 1.
Transform Type 4 always takes place in the CREATE_CHILD_SA exchange, Each additional key exchange method MUST be fully completed before
as per IKEv2 specification. the next one is started. Note, that this document assumes, that each
key exchange method consumes exactly one IKE_FOLLOWUP_KE exchange.
For the methods requiring multiple round trips, a separate document
should define how such methods are splitted into several
IKE_FOLLOWUP_KE exchanges.
Since after IKE SA is created the window size may be greater than one Since after IKE SA is created the window size may be greater than one
and multiple concurrent exchanges may be in progress, it is essential and multiple concurrent exchanges may be in progress, it is essential
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 the next IKE_FOLLOWUP_KE IKE_FOLLOWUP_KE response message in case the next IKE_FOLLOWUP_KE
exchange is expected, filling it with some data that would allow exchange is expected, filling it with some data that would allow
linking current exchange to the next one. The initiator MUST send linking current exchange to the next one. The initiator MUST send
back the content of the received notification intact in the request back this notification intact in the request message of the next
message of the next exchange. IKE_FOLLOWUP_KE exchange.
Below is an example of three additional key exchanges. Below is an example of CREATE_CHILD_SA exchange followed by 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),
skipping to change at page 14, line 41 skipping to change at page 17, line 40
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 may lose its state and forget that it is in the process of
additional key exchanges and never starts next IKE_FOLLOWUP_KE performing additional key exchanges and thus never start the
exchanges. The responder MUST handle this situation gracefully and remaining IKE_FOLLOWUP_KE exchanges. The responder MUST handle this
delete the associated state if it does not receive the next expected situation gracefully and delete the associated state if it does not
IKE_FOLLOWUP_KE request after some reasonable period of time. receive the next expected 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
does not 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
skipping to change at page 15, line 33 skipping to change at page 18, line 32
situation. In a nutshell IKEv2 follows the rule that if in case of situation. In a nutshell IKEv2 follows the rule that if in case of
simultaneous rekeying two identical new IKE SAs (or two pairs 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
which the smallest nonce was used should be deleted by the initiator which the smallest nonce was used should be deleted by the initiator
of this exchange. of this exchange.
With multiple key exchanges the SAs are not yet created when the With multiple key exchanges the SAs are not yet created when the
CRETE_CHILD_SA is completed, they would be created only after the CREATE_CHILD_SA is completed, they would be created only after the
series of IKE_FOLLOWUP_KE exchanges is finished. For this reason if series of IKE_FOLLOWUP_KE exchanges is finished. For this reason if
additional key exchanges were negotiated in the CREATE_CHILD_SA additional key exchanges were negotiated in the CREATE_CHILD_SA
initiated by the losing side, there is nothing to delete and this initiated by the losing side, there is nothing to delete and this
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 the CREATE_CHILD_SA message requesting one of the peers receives the CREATE_CHILD_SA message requesting
rekey of SA that is already being rekeyed by this peer (i.e. the rekey of 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, TEMPORARY_FAILURE notification MUST be sent progress). In this case, TEMPORARY_FAILURE notification MUST be sent
in response to such a request. 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, SK(0) | Ni | Nr | SK(1) | ... SK(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, SK(0) | Ni | Nr | SK(1) | ... SK(n))
In both cases SK_d is from existing IKE SA; KE, Ni, Nr are the shared In both cases SK_d is from existing IKE SA; SK(0), Ni, Nr are the
key and nonces from the CREATE_CHILD_SA respectively; KE(1)...KE(n) shared key and nonces from the CREATE_CHILD_SA respectively;
are the shared keys from additional key exchanges. SK(1)...SK(n) are the shared keys from additional key exchanges.
3.2.5. Interaction with Childless IKE SA
It is also possible to establish a fully quantum-resistant IKE SAs
from additional key exchanges without using IKE_INTERMEDIATE
exchanges. In this case, the IKE SA created from IKE_SA_INIT
exchange can be immediately rekeyed with CREATE_CHILD_SA using
additional key exchanges and IKE_FOLLOWUP_KE message to carry the key
exchange payload. If only classical key exchange method is used in
the IKE_SA_INIT message, the very first Child SA created in IKE_AUTH
will not be quantum resistant. Consequently, if the peers' local
policy requires that all Child SAs should be fully-protected, then
the peers can avoid creating the very first Child SA by adopting
[RFC6023]. In this case, the peers exchange
CHILDLESS_IKEV2_SUPPORTED notification in the IKE_SA_INIT exchange
and a fully-protected Child SA can be created with CREATE_CHILD_SA
using additional key exchanges.
Note that if the initial IKE SA is used to transfer sensitive
information, then this information will not be protected using the
additional (e.g. quantum safe) key exchanges, so this scenario may be
inappropriate. One such example is in G-IKEv2 protocol
[I-D.ietf-ipsecme-g-ikev2] where cryptographic materials are
exchanged in IKE_SA_INIT messages between group member and the group
controller.
4. IANA Considerations 4. IANA Considerations
This document adds new exchange type into the "IKEv2 Exchange Types" This document adds new exchange type into the "IKEv2 Exchange Types"
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
skipping to change at page 17, line 12 skipping to change at page 20, line 39
<TBA> STATE_NOT_FOUND <TBA> STATE_NOT_FOUND
5. Security Considerations 5. Security Considerations
The key length of the Encryption Algorithm (Transform Type 1), the The key length of the Encryption Algorithm (Transform Type 1), the
Pseudorandom Function (Transform Type 2) and the Integrity Algorithm Pseudorandom Function (Transform Type 2) and the Integrity Algorithm
(Transform Type 3), all have to be of sufficient length to prevent (Transform Type 3), all have to be of sufficient length to prevent
attacks using Grover's algorithm [GROVER]. In order to use the attacks using Grover's algorithm [GROVER]. In order to use the
extension proposed in this document, the key lengths of these extension proposed in this document, the key lengths of these
transforms SHALL be at least 256 bits long in order to provide transforms MUST be at least 256 bits long in order to provide
sufficient resistance to quantum attacks. Accordingly the post- sufficient resistance to quantum attacks. Accordingly the post-
quantum security level achieved is at least 128 bits. quantum security level achieved is at least 128 bits.
SKEYSEED is calculated from shared KE(x) using an algorithm defined SKEYSEED is calculated from shared SK(x) using an algorithm defined
in Transform Type 2. While a quantum attacker may learn the value of in Transform Type 2. While a quantum attacker may learn the value of
KE(x), if this value is obtained by means of a classical key SK(x), if this value is obtained by means of a classical key
exchange, other KE(x) values generated by means of a quantum- exchange, other SK(x) values generated by means of a quantum-
resistant algorithm ensure that the final SKEYSEED is not resistant algorithm ensure that the final SKEYSEED is not
compromised. This assumes that the algorithm defined in the compromised. This assumes that the algorithm defined in the
Transform Type 2 is post-quantum. Transform Type 2 is post-quantum.
The main focus of this document is to prevent a passive attacker The main focus of this document is to prevent a passive attacker
performing a "harvest and decrypt" attack. In other words, an performing a "harvest and decrypt" attack. In other words, an
attacker that records messages exchanges today and proceeds to attacker that records messages exchanged today and proceeds to
decrypt them once he owns a quantum computer. This attack is decrypt them once he owns a quantum computer. This attack is
prevented due to the hybrid nature of the key exchange. Other prevented due to the hybrid nature of the key exchange. Other
attacks involving an active attacker using a quantum-computer are not attacks involving an active attacker using a quantum-computer are not
completely solved by this document. This is for two reasons. completely solved by this document. This is for two reasons.
The first reason is because the authentication step remains The first reason is because the authentication step remains
classical. In particular, the authenticity of the SAs established classical. In particular, the authenticity of the SAs established
under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA
algorithms. Whilst the pre-shared key option, provided the key is algorithms. Whilst the pre-shared key option, provided the key is
long enough, is post-quantum, the other algorithms are not. long enough, is post-quantum, the other algorithms are not.
skipping to change at page 18, line 8 skipping to change at page 21, line 38
provide resistance to attacks mounted in the future. The current provide resistance to attacks mounted in the future. The current
threat is that encrypted sessions are subject to eavesdropping and threat is that encrypted sessions are subject to eavesdropping and
archived with decryption by quantum computers taking place at some archived with decryption by quantum computers taking place at some
point in the future. Until quantum computers become available there point in the future. Until quantum computers become available there
is no point in attacking the authenticity of a connection because is no point in attacking the authenticity of a connection because
there are no possibilities for exploitation. These only occur at the there are no possibilities for exploitation. These only occur at the
time of the connection, for example by mounting a man-in-the-middle time of the connection, for example by mounting a man-in-the-middle
(MitM) attack. Consequently there is not such a pressing need for (MitM) attack. Consequently there is not such a pressing need for
quantum-safe authenticity. quantum-safe authenticity.
Performing multiple key exchanges while establishing IKEv2 SA
increases the responder's susceptibility to DoS attacks, because of
an increased amount of resources needed to spend before the initiator
is authenticated. This is especially true for post-quantum key
exchange methods, where many of them are more memory and/or CPU
intensive than the classical counterparts.
Responders may consider recommendations from [RFC8019] to deal with
increased DoS attack susceptibility. It is also possible that the
responder only agrees to create initial IKE SA without performing
additional key exchanges, provided the initiator includes such an
option in its proposals. Then peers immediately rekey initial IKE SA
with the CREATE_CHILD_SA exchange and additional key exchanges
performed via the IKE_FOLLOWUP_KE exchanges. In this case at the
point when resource-intensive operations are required, peers have
already authenticated each other. However, in the context of hybrid
post-quantum key exchange this scenario would leave initial IKE SA
(and initial Child SA if it is created) unprotected against quantum
computers. Nevertheless the rekeyed IKE SA (and Child SAs that will
be created over it) will have full protection. This is similar to
the scenario described in [RFC8784]. Depending on peers' policy,
this scenario may or may not be appropriate.
6. Acknowledgements 6. Acknowledgements
The authors would like to thanks Frederic Detienne and Olivier The authors would like to thank Frederic Detienne and Olivier Pelerin
Pelerin for their comments and suggestions, including the idea to for their comments and suggestions, including the idea to negotiate
negotiate the post-quantum algorithms using the existing KE payload. the post-quantum algorithms using the existing KE payload. The
The authors are also grateful to Tobias Heider and Tobias Guggemos authors are also grateful to Tobias Heider and Tobias Guggemos for
for valuable comments. valuable comments. Thanks to Paul Wouters for reviewing the
document.
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-06 (work Protocol", Work in Progress, Internet-Draft, draft-ietf-
in progress), March 2021. ipsecme-ikev2-intermediate-07, 3 August 2021,
<https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-
intermediate-07.txt>.
[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 45 skipping to change at page 23, line 5
[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-g-ikev2]
Smyslov, V. and B. Weis, "Group Key Management using
IKEv2", Work in Progress, Internet-Draft, draft-ietf-
ipsecme-g-ikev2-03, 11 July 2021, <https://www.ietf.org/
internet-drafts/draft-ietf-ipsecme-g-ikev2-03.txt>.
[I-D.tjhai-ikev2-beyond-64k-limit] [I-D.tjhai-ikev2-beyond-64k-limit]
Tjhai, C., Heider, T., and V. Smyslov, "Beyond 64KB Limit Tjhai, C., Heider, T., and V. Smyslov, "Beyond 64KB Limit
of IKEv2 Payload", draft-tjhai-ikev2-beyond-64k-limit-00 of IKEv2 Payloads", Work in Progress, Internet-Draft,
(work in progress), October 2020. draft-tjhai-ikev2-beyond-64k-limit-01, 9 July 2021,
<https://www.ietf.org/archive/id/draft-tjhai-ikev2-beyond-
64k-limit-01.txt>.
[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>.
[RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A
Childless Initiation of the Internet Key Exchange Version
2 (IKEv2) Security Association (SA)", RFC 6023,
DOI 10.17487/RFC6023, October 2010,
<https://www.rfc-editor.org/info/rfc6023>.
[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,
DOI 10.17487/RFC7383, November 2014, DOI 10.17487/RFC7383, November 2014,
<https://www.rfc-editor.org/info/rfc7383>. <https://www.rfc-editor.org/info/rfc7383>.
[RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange
Protocol Version 2 (IKEv2) Implementations from
Distributed Denial-of-Service Attacks", RFC 8019,
DOI 10.17487/RFC8019, November 2016,
<https://www.rfc-editor.org/info/rfc8019>.
[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, [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov,
"Mixing Preshared Keys in the Internet Key Exchange "Mixing Preshared Keys in the Internet Key Exchange
Protocol Version 2 (IKEv2) for Post-quantum Security", Protocol Version 2 (IKEv2) for Post-quantum Security",
RFC 8784, DOI 10.17487/RFC8784, June 2020, RFC 8784, DOI 10.17487/RFC8784, June 2020,
<https://www.rfc-editor.org/info/rfc8784>. <https://www.rfc-editor.org/info/rfc8784>.
Appendix A. Alternative Design Appendix A. Sample Multiple Key Exchanges
This appendix shows some examples of multiple key exchanges. These
examples are purely for information purposes and they describe some
message flow scenarios that may occur in establishing an IKE or CHILD
SA. Note that some payloads that are not relevant to multiple key
exchanges may be omitted for brevity.
A.1. No Additional Key Exchange Used
The initiator proposes two sets of optional additional key exchanges,
but the responder does not support any of them. The responder
chooses NONE for each set and consequently, IKE_INTERMEDIATE exchange
does not takes place and the exchange proceeds to IKE_AUTH phase.
The resulting keying materials are the same as those derived with
[RFC7296].
Initiator Responder
------------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. AKE*...), --->
KEi1, Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform AKE1 (ID = PQ_KEM_1)
Transform AKE1 (ID = PQ_KEM_2)
Transform AKE1 (ID = NONE)
Transform AKE2 (ID = PQ_KEM_3)
Transform AKE2 (ID = PQ_KEM_4)
Transform AKE2 (ID = NONE)
<--- HDR(IKE_SA_INIT), SAr1(.. AKE*...),
KEr1, Nr, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform AKE1 (ID = NONE)
Transform AKE2 (ID = NONE)
HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } --->
<--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2,
TSi, TSr }
A.2. Additional Key Exchange in the CREATE_CHILD_SA Exchange only
The exchanges below show that the initiator does not propose the use
of additional key exchanges to establish an IKE SA, but they are
required in order to establish a Child SA. In order to establish a
fully quantum-resistant IPsec SA, both peers include
CHILDLESS_IKEV2_SUPPORTED notification in their exchange so that the
first Child SA is not created in IKE_AUTH, but instead the IKE SA is
immediately rekeyed using CREATED_CHILD_SA. Any Child SA will have
to be created via subsequent CREATED_CHILD_SA exchange.
Initiator Responder
------------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1, --->
KEi1, Ni, N(IKEV2_FRAG_SUPPORTED),
N(CHILDLESS_IKEV2_SUPPORTED)
<--- HDR(IKE_SA_INIT), SAr1,
KEr1, Nr, N(IKEV2_FRAG_SUPPORTED),
N(CHILDLESS_IKEV2_SUPPORTED)
HDR(IKE_AUTH), SK{ IDi, AUTH } --->
<--- HDR(IKE_AUTH), SK{ IDr, AUTH }
HDR(CREATE_CHILD_SA), SK{ SAi(.. AKE*...), Ni, KEi } --->
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform AKE1 (ID = PQ_KEM_1)
Transform AKE1 (ID = PQ_KEM_2)
Transform AKE2 (ID = PQ_KEM_5)
Transform AKE2 (ID = PQ_KEM_6)
Transform AKE2 (ID = NONE)
<--- HDR(CREATE_CHILD_SA), SK{ SAr(.. AKE*...),
Nr, KEr,
N(ADDITIONAL_KEY_EXCHANGE)(link1) }
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform AKE1 (ID = PQ_KEM_2)
Transform AKE2 (ID = PQ_KEM_5)
HDR(IKE_FOLLOWUP_KE), SK{ KEi(1), --->
N(ADDITIONAL_KEY_EXCHANGE)(link1) }
<--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(1),
N(ADDITIONAL_KEY_EXCHANGE)(link2) }
HDR(IKE_FOLLOWUP_KE), SK{ KEi(2), --->
N(ADDITIONAL_KEY_EXCHANGE)(link2) }
<--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(2) }
A.3. Not Matching Proposal for Additional Key Exchanges
The initiator proposes the combination of PQ_KEM_1, PQ_KEM_2,
PQ_KEM_3, and PQ_KEM_4 as the additional key exchanges. The
initiator indicates, using the key exchange method NONE, that either
PQ_KEM_1 or PQ_KEM_2 must be used to establish a security
association. The responder, although supports the optional PQ_KEM_3
and PQ_KEM_4 method, does not support either PQ_KEM_1 or PQ_KEM_2
mandatory method and therefore responds with NO_PROPOSAL_CHOSEN
notification.
Initiator Responder
------------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. AKE*...), --->
KEi1, Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform AKE1 (ID = PQ_KEM_1)
Transform AKE1 (ID = PQ_KEM_2)
Transform AKE2 (ID = PQ_KEM_3)
Transform AKE2 (ID = PQ_KEM_4)
Transform AKE2 (ID = NONE)
<--- HDR(IKE_SA_INIT), N(NO_PROPOSAL_CHOSEN)
Appendix B. 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 * 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
of this draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This of this draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This
does allow us to cleanly apply hybrid key exchanges during the does allow us to cleanly apply hybrid key exchanges during the
child SA; however it does add considerable complexity, and child SA; however it does add considerable complexity, and
requires an independent fragmentation solution. requires an independent fragmentation solution.
o Sending post-quantum proposals and policies in KE payload only * Sending post-quantum proposals and policies in KE payload only
With the objective of not introducing unnecessary notify payloads, With the objective of not introducing unnecessary notify payloads,
we considered communicating the hybrid post-quantum proposal in we considered communicating the hybrid post-quantum proposal in
the KE payload during the first pass of the protocol exchange. the KE payload during the first pass of the protocol exchange.
Unfortunately, this design is susceptible to the following Unfortunately, this design is susceptible to the following
downgrade attack. Consider the scenario where there is an MitM downgrade attack. Consider the scenario where there is an MitM
attacker sitting between an initiator and a responder. The attacker sitting between an initiator and a responder. The
initiator proposes, through SAi payload, to use a hybrid post- initiator proposes, through SAi payload, to use a hybrid post-
quantum group and as a backup a Diffie-Hellman group, and through quantum group and as a backup a Diffie-Hellman group, and through
KEi payload, the initiator proposes a list of hybrid post-quantum KEi payload, the initiator proposes a list of hybrid post-quantum
proposals and policies. The MitM attacker intercepts this traffic proposals and policies. The MitM attacker intercepts this traffic
and replies with N(INVALID_KE_PAYLOAD) suggesting to downgrade to and replies with N(INVALID_KE_PAYLOAD) suggesting to downgrade to
the backup Diffie-Hellman group instead. The initiator then the backup Diffie-Hellman group instead. The initiator then
resends the same SAi payload and the KEi payload containing the resends the same SAi payload and the KEi payload containing the
skipping to change at page 20, line 31 skipping to change at page 28, line 22
group but not offering the corresponding public value in the KEi group but not offering the corresponding public value in the KEi
payload; and (b) the responder has not specifically acknowledged payload; and (b) the responder has not specifically acknowledged
that it does not supported the requested hybrid group. However, that it does not supported the requested hybrid group. However,
the checking of this policy introduces unnecessary protocol the checking of this policy introduces unnecessary protocol
complexity. Therefore, in order to fully prevent any downgrade complexity. Therefore, in order to fully prevent any downgrade
attacks, using KE payload alone is not sufficient and that the attacks, using KE payload alone is not sufficient and that the
initiator MUST always indicate its preferred post-quantum initiator MUST always indicate its preferred post-quantum
proposals and policies in a notify payload in the subsequent proposals and policies in a notify payload in the subsequent
IKE_SA_INIT messages following a N(INVALID_KE_PAYLOAD) response. IKE_SA_INIT messages following a N(INVALID_KE_PAYLOAD) response.
o New payload types to negotiate hybrid proposal and to carry post- * New payload types to negotiate hybrid proposal and to carry post-
quantum public values quantum public values
Semantically, it makes sense to use a new payload type, which Semantically, it makes sense to use a new payload type, which
mimics the SA payload, to carry a hybrid proposal. Likewise, mimics the SA payload, to carry a hybrid proposal. Likewise,
another new payload type that mimics the KE payload, could be used another new payload type that mimics the KE payload, could be used
to transport hybrid public value. Although, in theory a new to transport hybrid public value. Although, in theory a new
payload type could be made backwards compatible by not setting its payload type could be made backwards compatible by not setting its
critical flag as per Section 2.5 of RFC7296, we believe that it critical flag as per Section 2.5 of RFC7296, we believe that it
may not be that simple in practice. Since the original release of may not be that simple in practice. Since the original release of
IKEv2 in RFC4306, no new payload type has ever been proposed and IKEv2 in RFC4306, no new payload type has ever been proposed and
therefore, this creates a potential risk of having a backward therefore, this creates a potential risk of having a backward
compatibility issue from non-conforming RFC IKEv2 implementations. compatibility issue from non-conforming RFC IKEv2 implementations.
Since we could not see any other compelling advantages apart from Since we could not see any other compelling advantages apart from
a semantic one, we use the existing transform type and notify a semantic one, we use the existing transform type and notify
payloads instead. In fact, as described above, we use the KE payloads instead. In fact, as described above, we use the KE
payload in the first IKE_SA_INIT request round and the notify payload in the first IKE_SA_INIT request round and the notify
payload to carry the post-quantum proposals and policies. We use payload to carry the post-quantum proposals and policies. We use
one or more of the existing KE payloads to carry the hybrid public one or more of the existing KE payloads to carry the hybrid public
values. values.
o Hybrid public value payload * Hybrid public value payload
One way to transport the negotiated hybrid public payload, which One way to transport the negotiated hybrid public payload, which
contains one classical Diffie-Hellman public value and one or more contains one classical Diffie-Hellman public value and one or more
post-quantum public values, is to bundle these into a single KE post-quantum public values, is to bundle these into a single KE
payload. Alternatively, these could also be transported in a payload. Alternatively, these could also be transported in a
single new hybrid public value payload, but following the same single new hybrid public value payload, but following the same
reasoning as above, this may not be a good idea from a backward reasoning as above, this may not be a good idea from a backward
compatibility perspective. Using a single KE payload would compatibility perspective. Using a single KE payload would
require an encoding or formatting to be defined so that both peers require an encoding or formatting to be defined so that both peers
are able to compose and extract the individual public values. are able to compose and extract the individual public values.
However, we believe that it is cleaner to send the hybrid public However, we believe that it is cleaner to send the hybrid public
values in multiple KE payloads--one for each group or algorithm. values in multiple KE payloads--one for each group or algorithm.
Furthermore, at this point in the protocol exchange, both peers Furthermore, at this point in the protocol exchange, both peers
should have indicated support of handling multiple KE payloads. should have indicated support of handling multiple KE payloads.
o Fragmentation * Fragmentation
Handling of large IKE_SA_INIT messages has been one of the most Handling of large IKE_SA_INIT messages has been one of the most
challenging tasks. A number of approaches have been considered challenging tasks. A number of approaches have been considered
and the two prominent ones that we have discarded are outlined as and the two prominent ones that we have discarded are outlined as
follows. follows.
The first approach was to treat the entire IKE_SA_INIT message as The first approach was to treat the entire IKE_SA_INIT message as
a stream of bytes, which we then split it into a number of a stream of bytes, which we then split it into a number of
fragments, each of which is wrapped onto a payload that would fit fragments, each of which is wrapped onto a payload that would fit
into the size of the network MTU. The payload that wraps each into the size of the network MTU. The payload that wraps each
skipping to change at page 22, line 42 skipping to change at page 30, line 42
We discarded this approach because we believe that the working We discarded this approach because we believe that the working
group may not be happy using the RESERVED field to change the group may not be happy using the RESERVED field to change the
format of a packet and that implementers may not like the format of a packet and that implementers may not like the
complexity added from checking the fragmentation flag in each complexity added from checking the fragmentation flag in each
received payload. More importantly, fragmenting the messages in received payload. More importantly, fragmenting the messages in
this way may leave the system to be more prone to denial of this way may leave the system to be more prone to denial of
service (DoS) attacks. By using IKE_INTERMEDIATE to transport the service (DoS) attacks. By using IKE_INTERMEDIATE to transport the
large post-quantum key exchange payloads, there is no longer any large post-quantum key exchange payloads, there is no longer any
issue with fragmentation. issue with fragmentation.
o Group sub-identifier * Group sub-identifier
As discussed before, each group identifier is used to distinguish As discussed before, each group identifier is used to distinguish
a post-quantum algorithm. Further classification could be made on a post-quantum algorithm. Further classification could be made on
a particular post-quantum algorithm by assigning additional value a particular post-quantum algorithm by assigning additional value
alongside the group identifier. This sub- identifier value may be alongside the group identifier. This sub- identifier value may be
used to assign different security parameter sets to a given post- used to assign different security parameter sets to a given post-
quantum algorithm. However, this level of details does not fit quantum algorithm. However, this level of details does not fit
the principles of the document where it should deal with generic the principles of the document where it should deal with generic
hybrid key exchange protocol, not a specific ciphersuite. hybrid key exchange protocol, not a specific ciphersuite.
Furthermore, there are enough Diffie- Hellman group identifiers Furthermore, there are enough Diffie- Hellman group identifiers
should this be required in the future. should this be required in the future.
Authors' Addresses Authors' Addresses
C. Tjhai C. Tjhai
Post-Quantum Post-Quantum
Email: cjt@post-quantum.com Email: cjt@post-quantum.com
 End of changes. 76 change blocks. 
222 lines changed or deleted 527 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/