draft-ietf-ipsecme-ikev2-intermediate-06.txt   draft-ietf-ipsecme-ikev2-intermediate-07.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track March 9, 2021 Intended status: Standards Track August 3, 2021
Expires: September 10, 2021 Expires: February 4, 2022
Intermediate Exchange in the IKEv2 Protocol Intermediate Exchange in the IKEv2 Protocol
draft-ietf-ipsecme-ikev2-intermediate-06 draft-ietf-ipsecme-ikev2-intermediate-07
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 September 10, 2021. This Internet-Draft will expire on February 4, 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 18 skipping to change at page 2, line 18
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 . . . . . 9
4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 9 4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative 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 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 a [RFC7296] uses UDP as a transport for its messages. If size of a
message is large enough, IP fragmentation takes place, that may message 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 5, line 17 skipping to change at page 5, line 17
The content of the IKE_INTERMEDIATE exchange messages depends on the The content of the IKE_INTERMEDIATE exchange messages depends on the
data being transferred and will be defined by specifications data being transferred and will be defined by specifications
utilizing this exchange. However, since the main motivation for the utilizing this exchange. However, since the main motivation for the
IKE_INTERMEDIATE exchange is to avoid IP fragmentation when large IKE_INTERMEDIATE exchange is to avoid IP fragmentation when large
amount of data need to be transferred prior to IKE_AUTH, the amount of data need to be transferred prior to IKE_AUTH, the
Encrypted payload MUST be present in the IKE_INTERMEDIATE exchange Encrypted payload MUST be present in the IKE_INTERMEDIATE exchange
messages and payloads containing large data MUST be placed inside it. messages and payloads containing large data MUST be placed inside it.
This will allow IKE fragmentation [RFC7383] to take place, provided This will allow IKE fragmentation [RFC7383] to take place, provided
it is supported by the peers and negotiated in the initial exchange. 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. The IKE_INTERMEDIATE Exchange Protection and Authentication
3.3.1. Protection of the IKE_INTERMEDIATE Messages 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 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 protection are computed in a standard fashion, as defined in the
Section 2.14 of [RFC7296]. Section 2.14 of [RFC7296].
Every subsequent IKE_INTERMEDIATE exchange uses the most recently Every subsequent IKE_INTERMEDIATE exchange uses the most recently
calculated IKE SA keys before this exchange is started. So, the 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] 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 keys that were computed as a result of the IKE_SA_INIT exchange. If
additional key exchange is performed in the first IKE_INTERMEDIATE 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 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 these updated keys are used for protection of the second
IKE_INTERMEDIATE exchange, otherwise the original SK_e[i/r] and IKE_INTERMEDIATE exchange, otherwise the original SK_e[i/r] and
SK_a[i/r] keys are used again, and so on. 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 3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges
The IKE_INTERMEDIATE messages must be authenticated in the IKE_AUTH The IKE_INTERMEDIATE messages must be authenticated in the IKE_AUTH
exchange, which is performed by adding their content into the AUTH exchange, which is performed by adding their content into the AUTH
payload calculation. It is anticipated that in many use cases payload calculation. It is anticipated that in many use cases
IKE_INTERMEDIATE messages will be fragmented using IKE fragmentation IKE_INTERMEDIATE messages will be fragmented using IKE fragmentation
[RFC7383] mechanism. According to [RFC7383], when IKE fragmentation [RFC7383] mechanism. According to [RFC7383], when IKE fragmentation
is negotiated, initiator may first send request message in is negotiated, initiator may first send request message in
unfragmented form, but later turn IKE fragmentation on and re-send it unfragmented form, but later turn IKE fragmentation on and re-send it
fragmented if no response is received after few retransmissions. In fragmented if no response is received after few retransmissions. In
skipping to change at page 10, line 35 skipping to change at page 10, line 40
o ELVIS-PLUS o ELVIS-PLUS
o strongSwan o strongSwan
o libreswan (only one IKE_INTERMEDIATE exchange is supported) o libreswan (only one IKE_INTERMEDIATE exchange is supported)
8. Acknowledgements 8. 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. He also helped with
Daniel Van Geest identified a possible problem with authentication of writing an example of using IKE_INTERMEDIATE exchange (shown in
the IKE_INTERMEDIATE exchange and helped to resolve it. Author is Appendix A). Scott Fluhrer and Daniel Van Geest identified a
also grateful to Tobias Brunner for raising good points concerning possible problem with authentication of the IKE_INTERMEDIATE exchange
authentication of the IKE_INTERMEDIATE exchange and to Paul Wouters and helped to resolve it. Author is also grateful to Tobias Brunner
who suggested text improvements for the document. 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. References
9.1. Normative References 9.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>.
skipping to change at page 11, line 30 skipping to change at page 11, line 39
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>. August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
DOI 10.17487/RFC5723, January 2010, DOI 10.17487/RFC5723, January 2010,
<https://www.rfc-editor.org/info/rfc5723>. <https://www.rfc-editor.org/info/rfc5723>.
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) {...} -->
<Calculate IntAuth_1_I = prf(SK_pi_1, ...)>
<-- HDR(IKE_INTERMEDIATE,MID=1),
SK(SK_er_1,SK_ar_1) {...}
<Calculate IntAuth_1_R = prf(SK_pr_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) {...} -->
<Calculate IntAuth_2_I = prf(SK_pi_2, ...)>
<-- HDR(IKE_INTERMEDIATE,MID=2),
SK(SK_er_2,SK_ar_2) {...}
<Calculate IntAuth_2_R = prf(SK_pr_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 Author's Address
Valery Smyslov Valery Smyslov
ELVIS-PLUS ELVIS-PLUS
PO Box 81 PO Box 81
Moscow (Zelenograd) 124460 Moscow (Zelenograd) 124460
RU RU
Phone: +7 495 276 0211 Phone: +7 495 276 0211
Email: svan@elvis.ru Email: svan@elvis.ru
 End of changes. 10 change blocks. 
14 lines changed or deleted 107 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/