--- 1/draft-ietf-ipsecme-ikev2-intermediate-02.txt 2019-12-16 04:14:17.155786919 -0800 +++ 2/draft-ietf-ipsecme-ikev2-intermediate-03.txt 2019-12-16 04:14:17.187787738 -0800 @@ -1,18 +1,18 @@ Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS -Intended status: Standards Track July 24, 2019 -Expires: January 25, 2020 +Intended status: Standards Track December 16, 2019 +Expires: June 18, 2020 Intermediate Exchange in the IKEv2 Protocol - draft-ietf-ipsecme-ikev2-intermediate-02 + draft-ietf-ipsecme-ikev2-intermediate-03 Abstract This documents defines a new exchange, called Intermediate Exchange, for the Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Association (SA) establishment. Introducing Intermediate Exchange allows re-using existing IKE Fragmentation mechanism, that helps to avoid IP fragmentation of large IKE messages, but cannot be used in the initial IKEv2 exchange. @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 25, 2020. + This Internet-Draft will expire on June 18, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -138,37 +138,37 @@ exchange, it includes this notification in the response message. Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni, [N(INTERMEDIATE_EXCHANGE_SUPPORTED)] --> <-- HDR, SAr1, KEr, Nr, [CERTREQ], [N(INTERMEDIATE_EXCHANGE_SUPPORTED)] The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2 - notification. Its Notify Message Type is . Protocol ID - and SPI Size are both set to 0. This specification doesn't define - any data this notification may contain, so the Notification Data is - left empty. However, future enhancements of this specification may + notification. Its Notify Message Type is 16438. Protocol ID and SPI + Size are both set to 0. This specification doesn't define any data + this notification may contain, so the Notification Data is left + empty. However, future enhancements of this specification may override this. Implementations MUST ignore the non-empty Notification Data if they don't understand its purpose. 3.2. Using Intermediate Exchange If both peers indicated their support for the Intermediate Exchange, the initiator may use one or more these exchanges to transfer additional data. Using the IKE_INTERMEDIATE exchange is optional, the initiator may find it unnecessary after completing the IKE_SA_INIT exchange. The Intermediate Exchange is denoted as IKE_INTERMEDIATE, its - Exchange Type is . + Exchange Type is 43. Initiator Responder ----------- ----------- HDR, ..., SK {...} --> <-- HDR, ..., SK {...} The initiator may use several IKE_INTERMEDIATE exchanges if necessary. Since initiator's Window Size is initially set to one (Section 2.3 of [RFC7296]), these exchanges MUST follow each other and MUST all be completed before the IKE_AUTH exchange is initiated. @@ -314,24 +314,25 @@ 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. + message by incrementally calculating prf on decrypted (or ready to be + encrypted) 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]_*, which are the most recently updated SK_p[i/r] keys available before the corresponded IKE_INTERMEDIATE exchange is started. The first 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 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/ 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 @@ -391,26 +392,26 @@ with known key, then the attacker could forge the IKE_INTERMEDIATE exchange messages without later being detected in the IKE_AUTH exchange. To do this the attacker should find the same IntAuth_*_[I|R] value for the forged message as for original. 6. IANA Considerations This document defines a new Exchange Type in the "IKEv2 Exchange Types" registry: - IKE_INTERMEDIATE + 43 IKE_INTERMEDIATE This document also defines a new Notify Message Types in the "Notify Message Types - Status Types" registry: - INTERMEDIATE_EXCHANGE_SUPPORTED + 16438 INTERMEDIATE_EXCHANGE_SUPPORTED 7. Acknowledgements The idea to use an intermediate exchange between IKE_SA_INIT and IKE_AUTH was first suggested by Tero Kivinen. Scott Fluhrer and Daniel Van Geest identified a possible problem with authentication of 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.