draft-ietf-ipsecme-ikev2-intermediate-03.txt   draft-ietf-ipsecme-ikev2-intermediate-04.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track December 16, 2019 Intended status: Standards Track June 15, 2020
Expires: June 18, 2020 Expires: December 17, 2020
Intermediate Exchange in the IKEv2 Protocol Intermediate Exchange in the IKEv2 Protocol
draft-ietf-ipsecme-ikev2-intermediate-03 draft-ietf-ipsecme-ikev2-intermediate-04
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 June 18, 2020. This Internet-Draft will expire on December 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 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, HDR, SAi1, KEi, Ni,
[N(INTERMEDIATE_EXCHANGE_SUPPORTED)] --> [N(INTERMEDIATE_EXCHANGE_SUPPORTED)] -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ], <-- 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 16438. Protocol ID and SPI notification. Its Notify Message Type is 16438. Protocol ID and SPI
Size are both set to 0. This specification doesn't define any data Size are both set to 0. This specification doesn't define any data
this notification may contain, so the Notification Data is left this notification may contain, so the Notification Data is left
empty. However, future enhancements of this specification may 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 31 skipping to change at page 5, line 31
IKE_INTERMEDIATE exchange performs additional key exchange resulting IKE_INTERMEDIATE exchange performs additional key exchange resulting
in the update of SK_e[i/r] and SK_a[i/r], then these updated keys are in the update of SK_e[i/r] and SK_a[i/r], then these updated keys are
used for encryption and authentication of the next IKE_INTERMEDIATE used for encryption and authentication of the next IKE_INTERMEDIATE
exchange, otherwise the current keys are used, and so on. exchange, otherwise the current keys are used, and so on.
3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges 3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges
The content of the IKE_INTERMEDIATE exchanges must be authenticated The content of the IKE_INTERMEDIATE exchanges must be authenticated
in the IKE_AUTH exchange. For this purpose the definition of the in the IKE_AUTH exchange. For this purpose the definition of the
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 in case INTERMEDIATE exchange(s) took place:
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_A [| IntAuth_1_I_P]) 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_A [| IntAuth_2_I_P]) 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_A [| IntAuth_3_I_P]) 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_A [| IntAuth_1_R_P]) 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_A [| IntAuth_2_R_P]) 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_A [| IntAuth_3_R_P]) 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: mandatory IntAuth_*_[I/R]_A and optional two chunks of data: mandatory IntAuth_*_[I/R]_A and optional
IntAuth_*_[I/R]_P. 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 the Initialization
Padding, Pad Length and Integrity Checksum Data fields (see 3.14 of Vector, the Padding, the Pad Length and the Integrity Checksum Data
[RFC7296] for description of the Encrypted payload). In other words, fields (see 3.14 of [RFC7296] for description of the Encrypted
the IntAuth_*_[I/R]_P chunk is the inner payloads of the Encrypted payload). In other words, the IntAuth_*_[I/R]_P chunk is the inner
payload in plaintext form. payloads of the Encrypted payload in plaintext form.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
skipping to change at page 10, line 12 skipping to change at page 10, line 12
exchange. To do this the attacker should find the same exchange. To do this the attacker should find the same
IntAuth_*_[I|R] value for the forged message as for original. IntAuth_*_[I|R] value for the forged message as for original.
6. IANA Considerations 6. IANA Considerations
This document defines a new Exchange Type in the "IKEv2 Exchange This document defines a new Exchange Type in the "IKEv2 Exchange
Types" registry: Types" registry:
43 IKE_INTERMEDIATE 43 IKE_INTERMEDIATE
This document also defines a new Notify Message Types in the "Notify This document also defines a new Notify Message Type in the "Notify
Message Types - Status Types" registry: Message Types - Status Types" registry:
16438 INTERMEDIATE_EXCHANGE_SUPPORTED 16438 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. Author is the IKE_INTERMEDIATE exchange and helped to resolve it. Author is
 End of changes. 13 change blocks. 
30 lines changed or deleted 31 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/