--- 1/draft-ietf-ipsecme-ikev2-intermediate-06.txt 2021-08-03 08:13:58.373563011 -0700 +++ 2/draft-ietf-ipsecme-ikev2-intermediate-07.txt 2021-08-03 08:13:58.473565495 -0700 @@ -1,18 +1,18 @@ Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS -Intended status: Standards Track March 9, 2021 -Expires: September 10, 2021 +Intended status: Standards Track August 3, 2021 +Expires: February 4, 2022 Intermediate Exchange in the IKEv2 Protocol - draft-ietf-ipsecme-ikev2-intermediate-06 + draft-ietf-ipsecme-ikev2-intermediate-07 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 September 10, 2021. + This Internet-Draft will expire on February 4, 2022. Copyright Notice Copyright (c) 2021 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 @@ -53,30 +53,31 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 3. Intermediate Exchange Details . . . . . . . . . . . . . . . . 3 3.1. Support for Intermediate Exchange Negotiation . . . . . . 3 3.2. Using Intermediate Exchange . . . . . . . . . . . . . . . 4 3.3. The IKE_INTERMEDIATE Exchange Protection and Authentication . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. Protection of the IKE_INTERMEDIATE Messages . . . . . 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 . . . . . 9 4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 + Appendix A. Example of IKE_INTERMEDIATE exchange . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The Internet Key Exchange protocol version 2 (IKEv2) defined in [RFC7296] uses UDP as a transport for its messages. If size of a message is large enough, IP fragmentation takes place, that may interfere badly with some network devices. The problem is described in more detail in [RFC7383], which also defines an extension to the IKEv2 called IKE fragmentation. This extension allows IKE messages to be fragmented at IKE level, eliminating possible issues caused by @@ -194,38 +195,45 @@ The content of the IKE_INTERMEDIATE exchange messages depends on the data being transferred and will be defined by specifications utilizing this exchange. However, since the main motivation for the IKE_INTERMEDIATE exchange is to avoid IP fragmentation when large amount of data need to be transferred prior to IKE_AUTH, the Encrypted payload MUST be present in the IKE_INTERMEDIATE exchange messages and payloads containing large data MUST be placed inside it. This will allow IKE fragmentation [RFC7383] to take place, provided it is supported by the peers and negotiated in the initial exchange. + Appendix A contains an example of using IKE_INTERMEDIATE exchange in + creating IKE SA. + 3.3. The IKE_INTERMEDIATE Exchange Protection and Authentication 3.3.1. Protection of the IKE_INTERMEDIATE Messages The keys SK_e[i/r] and SK_a[i/r] for the IKE_INTERMEDIATE exchanges protection are computed in a standard fashion, as defined in the Section 2.14 of [RFC7296]. Every subsequent IKE_INTERMEDIATE exchange uses the most recently calculated IKE SA keys before this exchange is started. So, the first IKE_INTERMEDIATE exchange always uses SK_e[i/r] and SK_a[i/r] keys that were computed as a result of the IKE_SA_INIT exchange. If additional key exchange is performed in the first IKE_INTERMEDIATE exchange resulting in the update of SK_e[i/r] and SK_a[i/r], then these updated keys are used for protection of the second IKE_INTERMEDIATE exchange, otherwise the original SK_e[i/r] and SK_a[i/r] keys are used again, and so on. + Once all the IKE_INTERMEDIATE exchanges are completed, the most + recently calculated SK_e[i/r] and SK_a[i/r] keys are used for + protection of the IKE_AUTH and all the subsequent exchanges. + 3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges The IKE_INTERMEDIATE messages must be authenticated in the IKE_AUTH exchange, which is performed by adding their content into the AUTH payload calculation. It is anticipated that in many use cases IKE_INTERMEDIATE messages will be fragmented using IKE fragmentation [RFC7383] mechanism. According to [RFC7383], when IKE fragmentation is negotiated, initiator may first send request message in unfragmented form, but later turn IKE fragmentation on and re-send it fragmented if no response is received after few retransmissions. In @@ -445,26 +453,28 @@ o ELVIS-PLUS o strongSwan o libreswan (only one IKE_INTERMEDIATE exchange is supported) 8. 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 and to Paul Wouters - who suggested text improvements for the document. + IKE_AUTH was first suggested by Tero Kivinen. He also helped with + writing an example of using IKE_INTERMEDIATE exchange (shown in + Appendix A). 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 and to Paul Wouters who suggested text + improvements for the document. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -486,20 +496,103 @@ [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, August 2017, . [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, DOI 10.17487/RFC5723, January 2010, . +Appendix A. Example of IKE_INTERMEDIATE exchange + + This appendix contains an example of the messages using + IKE_INTERMEDIATE exchange. This appendix is purely informative; if + it disagrees with the body of this document, the other text is + considered correct. + + In this example there is one IKE_SA_INIT exchange, two + IKE_INTERMEDIATE exchanges followed by the IKE_AUTH exchange to + authenticate all initial exchanges. The xxx in the HDR(xxx,MID=yyy) + indicates the exchange type, and yyy tells the message id used for + that exchange. The keys used for each SK {} payload are indicated in + the parenthesis after the SK. Otherwise payload notation is same as + is used in [RFC7296]. + + Initiator Responder + ----------- ----------- + HDR(IKE_SA_INIT,MID=0), + SAi1, KEi, Ni, + N(INTERMEDIATE_EXCHANGE_SUPPORTED) --> + + <-- HDR(IKE_SA_INIT,MID=0), + SAr1, KEr, Nr, [CERTREQ], + N(INTERMEDIATE_EXCHANGE_SUPPORTED) + + At this point peers calculate SK_* and store them as SK_*_1. SK_e[i/ + r]_1 and SK_a[i/r]_1 will be used to protect the first + IKE_INTERMEDIATE exchange and SK_p[i/r]_1 will be used for its + authentication. + + Initiator Responder + ----------- ----------- + HDR(IKE_INTERMEDIATE,MID=1), + SK(SK_ei_1,SK_ai_1) {...} --> + + + + <-- HDR(IKE_INTERMEDIATE,MID=1), + SK(SK_er_1,SK_ar_1) {...} + + + + If after completing this IKE_INTERMEDIATE exchange SK_*_1 keys are + updated (e.g., as a result of a new key exchange), then peers store + updated keys as SK_*_2, otherwise they use SK_*_1 as SK_*_2. SK_e[i/ + r]_2 and SK_a[i/r]_2 will be used to protect the second + IKE_INTERMEDIATE exchange and SK_p[i/r]_2 will be used for its + authentication. + + Initiator Responder + ----------- ----------- + HDR(IKE_INTERMEDIATE,MID=2), + SK(SK_ei_2,SK_ai_2) {...} --> + + + + <-- HDR(IKE_INTERMEDIATE,MID=2), + SK(SK_er_2,SK_ar_2) {...} + + + + If after completing the second IKE_INTERMEDIATE exchange SK_*_2 keys + are updated (e.g., as a result of a new key exchange), then peers + store updated keys as SK_*_3, otherwise they use SK_*_2 as SK_*_3. + SK_e[i/r]_3 and SK_a[i/r]_3 will be used to protect the IKE_AUTH + exchange, SK_p[i/r]_3 will be used for authentication and SK_d_3 will + be used for derivation of other keys (e.g. for Child SAs). + + Initiator Responder + ----------- ----------- + HDR(IKE_AUTH,MID=3), + SK(SK_ei_3,SK_ai_3) + {IDi, [CERT,] [CERTREQ,] + [IDr,] AUTH, SAi2, TSi, TSr} --> + <-- HDR(IKE_AUTH,MID=3), + SK(SK_er_3,SK_ar_3) + {IDr, [CERT,] AUTH, SAr2, TSi, TSr} + + In this example two IKE_INTERMEDIATE exchanges took place, therefore + SK_*_3 keys would be used as SK_* keys for further cryptographic + operations in the context of the created IKE SA, as defined in + [RFC7296]. + Author's Address Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 RU Phone: +7 495 276 0211 Email: svan@elvis.ru