draft-ietf-ipsecme-ikev2-multiple-ke-02.txt   draft-ietf-ipsecme-ikev2-multiple-ke-03.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 14, 2021 Quantum Secret Expires: January 7, 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
January 10, 2021 July 6, 2021
Multiple Key Exchanges in IKEv2 Multiple Key Exchanges in IKEv2
draft-ietf-ipsecme-ikev2-multiple-ke-02 draft-ietf-ipsecme-ikev2-multiple-ke-03
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 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 14, 2021. This Internet-Draft will expire on January 7, 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/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 41 skipping to change at page 2, line 41
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 . . . . . . . . . . . . . . . . . . 6 1.4. Document Organization . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . 10 3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . 10
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 . . 12
3.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 12 3.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 13
3.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 3.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Alternative Design . . . . . . . . . . . . . . . . . 19 Appendix A. Alternative Design . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
1.1. Problem Description 1.1. Problem Description
skipping to change at page 4, line 6 skipping to change at page 4, line 6
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 sizes larger than Some post-quantum key exchange payloads may have sizes larger than
the standard maximum transmission unit (MTU) size, and therefore the standard maximum transmission unit (MTU) size, and therefore
there could be issues with fragmentation at the IP layer. IKE does there could be issues with fragmentation at the IP layer. IKE does
allow transmission over TCP where fragmentation is not an issue allow transmission over TCP where fragmentation is not an issue
[RFC8229]; however, we believe that a UDP-based solution will be [RFC8229]; however, we believe that a UDP-based solution will be
required too. IKE does have a mechanism to handle fragmentation required too. IKE does have a mechanism to handle fragmentation
within UDP [RFC7383], however that is only applicable to messages within UDP [RFC7383], however that is only applicable to messages
exchanged after the IKE_SA_INIT. To use this mechanism, this exchanged after the IKE_SA_INIT exchange. To use this mechanism,
specification relies on the IKE_INTERMEDIATE exchange as outlined in this specification relies on the IKE_INTERMEDIATE exchange as
[I-D.ietf-ipsecme-ikev2-intermediate]. With this mechanism, we do an outlined in [I-D.ietf-ipsecme-ikev2-intermediate]. With this
initial key exchange, using a smaller, possibly non-quantum resistant mechanism, we do an initial key exchange, using a smaller, possibly
primitive, such as ECDH. Then, before we do the IKE_AUTH exchange, non-quantum resistant primitive, such as ECDH. Then, before we do
we perform one or more IKE_INTERMEDIATE exchanges, each of which the IKE_AUTH exchange, we perform one or more IKE_INTERMEDIATE
contains an additional key exchange. As the IKE_INTERMEDIATE exchanges, each of which contains an additional key exchange. As the
exchange is encrypted, the IKE fragmentation protocol [RFC7383] can IKE_INTERMEDIATE exchange is encrypted, the IKE fragmentation
be used. The IKE SK_* values are updated after each exchange, and so protocol [RFC7383] can be used. The IKE SK_* values are updated
the final IKE SA keys depend on all the key exchanges, hence they are after each exchange, and so the final IKE SA keys depend on all the
secure if any of the key exchanges are secure. key exchanges, hence they are 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 [RFC8784]. 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
skipping to change at page 4, line 45 skipping to change at page 4, line 46
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-03
o More clarifications added.
o Figure illustrating initial exchange added.
o 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. o 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. o References are updated.
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.
skipping to change at page 8, line 41 skipping to change at page 8, line 50
is also renamed from "Diffie-Hellman Group Transform IDs" to "Key is also renamed from "Diffie-Hellman Group Transform IDs" to "Key
Exchange Method Transform IDs". Exchange Method Transform IDs".
In order to support IKE fragmentation for additional key exchanges In order to support IKE fragmentation for additional key exchanges
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 allowed
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
a single transform of each type, and returns them 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; every such exchange includes a KE payload
for one of the negotiated key exchanges. for the next method from the negotiated list.
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 36 skipping to change at page 9, line 45
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 algorithm easier to solve than anticipated and thus the key agreement algorithm
may not be as secure as expected. A hybrid solution allows us to may not be as secure as expected. A hybrid solution allows us to
deal with this uncertainty by combining a classical key exchange with deal with this uncertainty by combining a classical key exchange 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. The rest of the KE
or 31). The rest of the KE payloads are encrypted within payloads are transferred within IKE_INTERMEDIATE messages; because
IKE_INTERMEDIATE messages; because they are encrypted, the standard these messages are encrypted, the standard IKE fragmentation solution
IKE fragmentation solution [RFC7383] is available. [RFC7383] is available.
The fact that all Additional Key Exchange Transform Types share the The fact, that all Additional Key Exchange Transform Types share the
same registry with Transform Type 4 allows additional key exchanges same registry with Transform Type 4, allows additional key exchanges
to be of any type - either post-quantum ones or classical (EC)DH to be of any type - either post-quantum ones or classical (EC)DH
ones. This approach allows any combination of defined key exchange ones. This approach allows any combination of defined key exchange
methods to take place. This also allows performing a single post- methods to take place. This also allows performing a single post-
quantum key exchange in the IKE_SA_INIT without additional key quantum key exchange in the IKE_SA_INIT without additional key
exchanges, provided that IP fragmentation is not an issue and that exchanges, provided that IP fragmentation is not an issue and that
hybrid key exchange is not needed. hybrid key exchange is not needed.
3.2. Overall Protocol 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 standard, 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, or it If the initiator desires to negotiate multiple key exchanges, then
needs IKE to handle any possible fragmentation, then the initiator the initiator uses the protocol listed below.
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 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 allowed 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 methods 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.
skipping to change at page 11, line 32 skipping to change at page 11, line 39
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 this notification, thus additional key exchanges, it MUST also return this notification, thus
confirming that IKE_INTERMEDIATE exchange is supported and will be confirming that IKE_INTERMEDIATE exchange is supported and will be
used for transferring additional key exchange data. The 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.
Initiator Responder
---------------------------------------------------------------------
HDR, SAi1(.. AKE*...), KEi1, Ni,
N(INTERMEDIATE_EXCHANGE_SUPPORTED) --->
HDR, SAr1(.. AKE*...), KEr1, Nr,
[CERTREQ],
<--- N(INTERMEDIATE_EXCHANGE_SUPPORTED)
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.
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 extra key exchange agreed to in the IKE_SA_INIT exchange,
the initiator and the responder perform one IKE_INTERMEDIATE the initiator and the responder perform one 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: 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. Note that the negotiated
transform types (the encryption type, integrity type, prf type) are transform types (the encryption type, integrity type, prf type) are
not modified. not modified.
Once this exchange is done, then 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), 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 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
the next exchange. the next exchange (IKE_INTERMEDIATE or IKE_AUTH).
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 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.
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
CREATE_CHILD_SA exchange. The IKE_FOLLOWUP_KE exchange is introduced CREATE_CHILD_SA exchange. The IKE_FOLLOWUP_KE exchange is introduced
as a dedicated exchange type to transfer data of additional key as a dedicated exchange for transferring data of 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>.
These key exchanges are performed in an order of the values of their Additional key exchanges are performed in an order of the values of
transform types, so that key exchange negotiated using Transform Type their transform types, so that key exchange negotiated using
n always precedes key exchange negotiated using Transform Type n + 1. Transform Type n always precedes key exchange negotiated using
Each IKE_FOLLOWUP_KE exchange MUST bear exactly one key exchange Transform Type n + 1. Each IKE_FOLLOWUP_KE exchange MUST bear
method. Key exchange negotiated via Transform Type 4 always takes exactly one key exchange method. Key exchange negotiated via
place in the CREATE_CHILD_SA exchange, as per IKEv2 specification. Transform Type 4 always takes place in the CREATE_CHILD_SA exchange,
as per IKEv2 specification.
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 exchange is IKE_FOLLOWUP_KE response message in case the next IKE_FOLLOWUP_KE
expected, filling it with some data that would allow linking this exchange is expected, filling it with some data that would allow
exchange to the next one. The initiator MUST copy the received linking current exchange to the next one. The initiator MUST send
notification with its content intact into the request message of the back the content of the received notification intact in the request
next exchange. 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),
skipping to change at page 14, line 49 skipping to change at page 15, line 12
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). the responder's point of view, e.g. due to a temporary network
After receiving this notification the initiator MAY start a new failure). After receiving this notification the initiator MAY start
CREATE_CHILD_SA exchange (eventually followed by the IKE_FOLLOWUP_KE a new CREATE_CHILD_SA exchange (eventually followed by the
exchanges) to retry the failed attempt. If the initiator continues IKE_FOLLOWUP_KE exchanges) to retry the failed attempt. If the
to receive STATE_NOT_FOUND notifications after several retries, it initiator continues to receive STATE_NOT_FOUND notifications after
MUST treat this situation as a fatal error and delete IKE SA by several retries, it MUST treat this situation as a fatal error and
sending a DELETE payload. delete IKE SA by 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] describe how IKEv2 handles this
this situation. In a nutshell IKEv2 follows the rule that if in case situation. In a nutshell IKEv2 follows the rule that if in case of
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 CRETE_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 CREATE_CHILD_SA message requesting rekeying one of the peers receives the CREATE_CHILD_SA message requesting
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, a TEMPORARY_FAILURE notification MUST be progress). In this case, TEMPORARY_FAILURE notification MUST be sent
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, 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 18, line 11 skipping to change at page 18, line 22
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-05 (work Protocol", draft-ietf-ipsecme-ikev2-intermediate-06 (work
in progress), September 2020. in progress), March 2021.
[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>.
 End of changes. 31 change blocks. 
68 lines changed or deleted 93 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/