draft-ietf-ipsecme-ikev2-intermediate-01.txt   draft-ietf-ipsecme-ikev2-intermediate-02.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track June 27, 2019 Intended status: Standards Track July 24, 2019
Expires: December 29, 2019 Expires: January 25, 2020
Intermediate Exchange in the IKEv2 Protocol Intermediate Exchange in the IKEv2 Protocol
draft-ietf-ipsecme-ikev2-intermediate-01 draft-ietf-ipsecme-ikev2-intermediate-02
Abstract Abstract
This documents defines a new exchange, called Intermediate Exchange, This documents defines a new exchange, called Intermediate Exchange,
for the Internet Key Exchange protocol Version 2 (IKEv2). This for the Internet Key Exchange protocol Version 2 (IKEv2). This
exchange can be used for transferring large amount of data in the exchange can be used for transferring large amount of data in the
process of IKEv2 Security Association (SA) establishment. process of IKEv2 Security Association (SA) establishment.
Introducing Intermediate Exchange allows re-using existing IKE Introducing Intermediate Exchange allows re-using existing IKE
Fragmentation mechanism, that helps to avoid IP fragmentation of Fragmentation mechanism, that helps to avoid IP fragmentation of
large IKE messages, but cannot be used in the initial IKEv2 exchange. large IKE messages, but cannot be used in the initial IKEv2 exchange.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 December 29, 2019. This Internet-Draft will expire on January 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
3. Intermediate Exchange Details . . . . . . . . . . . . . . . . 3 3. Intermediate Exchange Details . . . . . . . . . . . . . . . . 3
3.1. Support for Intermediate Exchange Negotiation . . . . . . 3 3.1. Support for Intermediate Exchange Negotiation . . . . . . 3
3.2. Using Intermediate Exchange . . . . . . . . . . . . . . . 4 3.2. Using Intermediate Exchange . . . . . . . . . . . . . . . 4
3.3. The IKE_INTERMEDIATE Exchange Protection and 3.3. The IKE_INTERMEDIATE Exchange Protection and
Authentication . . . . . . . . . . . . . . . . . . . . . 5 Authentication . . . . . . . . . . . . . . . . . . . . . 5
3.3.1. Protection of the IKE_INTERMEDIATE Messages . . . . . 5 3.3.1. Protection of the IKE_INTERMEDIATE Messages . . . . . 5
3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges . . 5 3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges . . 5
3.4. Error Handling in the IKE_INTERMEDIATE Exchange . . . . . 8 3.4. Error Handling in the IKE_INTERMEDIATE Exchange . . . . . 8
4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 8 4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Internet Key Exchange protocol version 2 (IKEv2) defined in The Internet Key Exchange protocol version 2 (IKEv2) defined in
[RFC7296] uses UDP as a transport for its messages. If size of the [RFC7296] uses UDP as a transport for its messages. If size of the
messages is large enough, IP fragmentation takes place, that may messages is large enough, IP fragmentation takes place, that may
interfere badly with some network devices. The problem is described interfere badly with some network devices. The problem is described
in more detail in [RFC7383], which also defines an extension to the in more detail in [RFC7383], which also defines an extension to the
IKEv2 called IKE Fragmentation. This extension allows IKE messages IKEv2 called IKE Fragmentation. This extension allows IKE messages
to be fragmented at IKE level, eliminating possible issues caused by to be fragmented at IKE level, eliminating possible issues caused by
skipping to change at page 3, line 47 skipping to change at page 3, line 47
3. Intermediate Exchange Details 3. Intermediate Exchange Details
3.1. Support for Intermediate Exchange Negotiation 3.1. Support for Intermediate Exchange Negotiation
The initiator indicates its support for Intermediate Exchange by The initiator indicates its support for Intermediate Exchange by
including a notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in including a notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in
the IKE_SA_INIT request message. If the responder also supports this the IKE_SA_INIT request message. If the responder also supports this
exchange, it includes this notification in the response message. exchange, it includes this notification in the response message.
Initiator Responder Initiator Responder
HDR, SAi1, KEi, Ni, ----------- -----------
[N(INTERMEDIATE_EXCHANGE_SUPPORTED)] --> HDR, SAi1, KEi, Ni,
<-- HDR, SAr1, KEr, Nr, [CERTREQ], [N(INTERMEDIATE_EXCHANGE_SUPPORTED)] -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ],
[N(INTERMEDIATE_EXCHANGE_SUPPORTED)] [N(INTERMEDIATE_EXCHANGE_SUPPORTED)]
The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2 The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2
notification. Its Notify Message Type is <TBA by IANA>. Protocol ID notification. Its Notify Message Type is <TBA by IANA>. Protocol ID
and SPI Size are both set to 0. This specification doesn't define and SPI Size are both set to 0. This specification doesn't define
any data this notification may contain, so the Notification Data is any data this notification may contain, so the Notification Data is
left empty. However, future enhancements of this specification may left empty. However, future enhancements of this specification may
override this. Implementations MUST ignore the non-empty override this. Implementations MUST ignore the non-empty
Notification Data if they don't understand its purpose. Notification Data if they don't understand its purpose.
skipping to change at page 5, line 40 skipping to change at page 5, line 40
blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is
modified as follows: modified as follows:
InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI [| IntAuth] InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI [| IntAuth]
ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR [| IntAuth] ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR [| IntAuth]
IntAuth = IntAuth_1 | [| IntAuth_2 [| IntAuth_3]] ... IntAuth = IntAuth_1 | [| IntAuth_2 [| IntAuth_3]] ...
IntAuth_1 = IntAuth_1_I | IntAuth_1_R IntAuth_1 = IntAuth_1_I | IntAuth_1_R
IntAuth_2 = IntAuth_2_I | IntAuth_2_R IntAuth_2 = IntAuth_2_I | IntAuth_2_R
IntAuth_3 = IntAuth_3_I | IntAuth_3_R IntAuth_3 = IntAuth_3_I | IntAuth_3_R...
...
IntAuth_1_I = prf(SK_pi_1, [IntAuth_1_I_P |] IntAuth_1_I_A) IntAuth_1_I = prf(SK_pi_1, IntAuth_1_I_A [| IntAuth_1_I_P])
IntAuth_2_I = prf(SK_pi_2, [IntAuth_2_I_P |] IntAuth_2_I_A) IntAuth_2_I = prf(SK_pi_2, IntAuth_2_I_A [| IntAuth_2_I_P])
IntAuth_3_I = prf(SK_pi_3, [IntAuth_3_I_P |] IntAuth_3_I_A) IntAuth_3_I = prf(SK_pi_3, IntAuth_3_I_A [| IntAuth_3_I_P])
... ...
IntAuth_1_R = prf(SK_pr_1, [IntAuth_1_R_P |] IntAuth_1_R_A) IntAuth_1_R = prf(SK_pr_1, IntAuth_1_R_A [| IntAuth_1_R_P])
IntAuth_2_R = prf(SK_pr_2, [IntAuth_2_R_P |] IntAuth_2_R_A) IntAuth_2_R = prf(SK_pr_2, IntAuth_2_R_A [| IntAuth_2_R_P])
IntAuth_3_R = prf(SK_pr_3, [IntAuth_3_R_P |] IntAuth_3_R_A) IntAuth_3_R = prf(SK_pr_3, IntAuth_3_R_A [| IntAuth_3_R_P])
... ...
IntAuth_1_I/IntAuth_1_R, IntAuth_2_I/IntAuth_2_R, IntAuth_3_I/ IntAuth_1_I/IntAuth_1_R, IntAuth_2_I/IntAuth_2_R, IntAuth_3_I/
IntAuth_3_R, etc. represent the results of applying the negotiated IntAuth_3_R, etc. represent the results of applying the negotiated
prf to the content of the IKE_INTERMEDIATE messages sent by the prf to the content of the IKE_INTERMEDIATE messages sent by the
initiator (IntAuth_*_I) and by the responder (IntAuth_*_R) in an initiator (IntAuth_*_I) and by the responder (IntAuth_*_R) in an
order of increasing Message IDs (i.e. in an order the order of increasing Message IDs (i.e. in an order the
IKE_INTERMEDIATE exchanges took place). The prf is applied to the IKE_INTERMEDIATE exchanges took place). The prf is applied to the
two chunks of data: optional IntAuth_*_[I/R]_P and mandatory two chunks of data: mandatory IntAuth_*_[I/R]_A and optional
IntAuth_*_[I/R]_A. The IntAuth_*_[I/R]_A chunk lasts from the first IntAuth_*_[I/R]_P. The IntAuth_*_[I/R]_A chunk lasts from the first
octet of the IKE Header (not including prepended four octets of octet of the IKE Header (not including prepended four octets of
zeros, if port 4500 is used) to the last octet of the Encrypted zeros, if port 4500 is used) to the last octet of the Encrypted
Payload header. The IntAuth_*_[I/R]_P chunk is present if the Payload header. The IntAuth_*_[I/R]_P chunk is present if the
Encrypted payload is not empty. It consists of the not yet encrypted Encrypted payload is not empty. It consists of the not yet encrypted
content of the Encrypted payload, excluding Initialization Vector, content of the Encrypted payload, excluding Initialization Vector,
Padding, Pad Length and Integrity Checksum Data fields (see 3.14 of Padding, Pad Length and Integrity Checksum Data fields (see 3.14 of
[RFC7296] for description of the Encrypted payload). In other words, [RFC7296] for description of the Encrypted payload). In other words,
the IntAuth_*_[I/R]_P chunk is the inner payloads of the Encrypted the IntAuth_*_[I/R]_P chunk is the inner payloads of the Encrypted
payload in plaintext form. payload in plaintext form.
skipping to change at page 7, line 18 skipping to change at page 7, line 18
| IKE SA Initiator's SPI | | | | IKE SA Initiator's SPI | | |
| | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I |
| IKE SA Responder's SPI | K | | IKE SA Responder's SPI | K |
| | E | | | E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Next Payload | MjVer | MnVer | Exchange Type | Flags | H | | Next Payload | MjVer | MnVer | Exchange Type | Flags | H |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d |
| Message ID | r A | Message ID | r A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| Length | | | | Adjusted Length | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v |
| | | | | |
~ Unencrypted payloads (if any) ~ | ~ Unencrypted payloads (if any) ~ |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |
| Next Payload |C| RESERVED | Payload Length | | | | Next Payload |C| RESERVED | Adjusted Payload Length | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E v
| Initialization Vector | n | Initialization Vector | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^
| | r | | | r |
~ Inner payloads (not yet encrypted) ~ P ~ Inner payloads (not yet encrypted) ~ P
| | P | | | P |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v
| Padding (0-255 octets) | Pad Length | d | Padding (0-255 octets) | Pad Length | d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Integrity Checksum Data ~ | ~ Integrity Checksum Data ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
Figure 1: Data to Authenticate in the IKE_INTERMEDIATE Exchange Figure 1: Data to Authenticate in the IKE_INTERMEDIATE Exchange
Messages Messages
Figure 1 illustrates the layout of the IntAuth_*_[I/R]_P (denoted as Figure 1 illustrates the layout of the IntAuth_*_[I/R]_P (denoted as
P) and the IntAuth_*_[I/R]_A (denoted as A) chunks in case the P) and the IntAuth_*_[I/R]_A (denoted as A) chunks in case the
Encrypted payload is not empty. Encrypted payload is not empty.
The calculations are applied to whole messages only, before possible For the purpose of prf calculation the Length field in the IKE header
IKE Fragmentation. This ensures that the IntAuth will be the same and the Payload Length field in the Encrypted Payload header are
regardless of whether IKE Fragmentation takes place or not. This is adjusted so that they don't count the lengths of Initialization
important since [RFC7383] allows sending first unfragmented message Vector, Integrity Checksum Data and Padding (along with Pad Length
and then resending it in fragmented form in case of no reply is field). In other words, the Length field in the IKE header (denoted
received. as Adjusted Length in Figure 1) is set to the sum of the lengths of
IntAuth_*_[I/R]_A and IntAuth_*_[I/R]_P, and the Payload Length field
in the Encrypted Payload header (denoted as Adjusted Payload Length
in Figure 1) is set to the length of IntAuth_*_[I/R]_P plus the size
of the Payload header (four octets).
The prf calculations MUST be applied to whole messages only, before
possible IKE Fragmentation. This ensures that the IntAuth will be
the same regardless of whether IKE Fragmentation takes place or not.
This is important since [RFC7383] allows sending first unfragmented
message and then resending it in fragmented form in case of no reply
is received. If the message was received in fragmented form, it
should be reconstructed before calculating prf as if it were received
unfragmented. The RESERVED field in the recontructed Encrypted
Payload header MUST be set to the value of the RESERVED field in the
Encrypted Fragment payload header from the first fragment (that with
Fragment Number equal to 1).
Note that it is possible to avoid actual reconstruction of the
message by incrementally calculating prf on decrypted fragments.
However care must be taken to properly replace the content of the
Next Header and the Length fields so that the result of computing prf
is the same as if it were computed on reconstructed message.
Each calculation of IntAuth_*_[I/R] uses its own keys SK_p[i/r]_*, Each calculation of IntAuth_*_[I/R] uses its own keys SK_p[i/r]_*,
which are the most recently updated SK_p[i/r] keys available before which are the most recently updated SK_p[i/r] keys available before
the corresponded IKE_INTERMEDIATE exchange is started. The first the corresponded IKE_INTERMEDIATE exchange is started. The first
IKE_INTERMEDIATE exchange always uses SK_p[i/r] keys that were IKE_INTERMEDIATE exchange always uses SK_p[i/r] keys that were
computed in the IKE_SA_INIT as SK_p[i/r]_1. If the first computed in the IKE_SA_INIT as SK_p[i/r]_1. If the first
IKE_INTERMEDIATE exchange performs additional key exchange resulting IKE_INTERMEDIATE exchange performs additional key exchange resulting
in SK_p[i/r] update, then this updated SK_p[i/r] are used as SK_p[i/ in SK_p[i/r] update, then this updated SK_p[i/r] are used as SK_p[i/
r]_2, otherwise the original SK_p[i/r] are used, and so on. Note, r]_2, otherwise the original SK_p[i/r] are used, and so on. Note,
that if keys are updated then for any given IKE_INTERMEDIATE exchange that if keys are updated then for any given IKE_INTERMEDIATE exchange
skipping to change at page 9, line 40 skipping to change at page 10, line 22
This document also defines a new Notify Message Types in the "Notify This document also defines a new Notify Message Types in the "Notify
Message Types - Status Types" registry: Message Types - Status Types" registry:
<TBA> INTERMEDIATE_EXCHANGE_SUPPORTED <TBA> INTERMEDIATE_EXCHANGE_SUPPORTED
7. Acknowledgements 7. Acknowledgements
The idea to use an intermediate exchange between IKE_SA_INIT and The idea to use an intermediate exchange between IKE_SA_INIT and
IKE_AUTH was first suggested by Tero Kivinen. Scott Fluhrer and IKE_AUTH was first suggested by Tero Kivinen. Scott Fluhrer and
Daniel Van Geest identified a possible problem with authentication of Daniel Van Geest identified a possible problem with authentication of
the IKE_INTERMEDIATE exchange and helped to resolve it. the IKE_INTERMEDIATE exchange and helped to resolve it. Author is
also grateful to Tobias Brunner for raising good points concerning
authentication of the IKE_INTERMEDIATE exchange.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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>.
 End of changes. 13 change blocks. 
35 lines changed or deleted 59 lines changed or added

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