draft-ietf-ipsecme-ikev2-intermediate-02.txt   draft-ietf-ipsecme-ikev2-intermediate-03.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track July 24, 2019 Intended status: Standards Track December 16, 2019
Expires: January 25, 2020 Expires: June 18, 2020
Intermediate Exchange in the IKEv2 Protocol Intermediate Exchange in the IKEv2 Protocol
draft-ietf-ipsecme-ikev2-intermediate-02 draft-ietf-ipsecme-ikev2-intermediate-03
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 January 25, 2020. This Internet-Draft will expire on June 18, 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 4, line 6 skipping to change at page 4, line 6
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 <TBA by IANA>. Protocol ID notification. Its Notify Message Type is 16438. Protocol ID and SPI
and SPI Size are both set to 0. This specification doesn't define Size are both set to 0. This specification doesn't define any data
any data this notification may contain, so the Notification Data is this notification may contain, so the Notification Data is left
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.
3.2. Using Intermediate Exchange 3.2. Using Intermediate Exchange
If both peers indicated their support for the Intermediate Exchange, If both peers indicated their support for the Intermediate Exchange,
the initiator may use one or more these exchanges to transfer the initiator may use one or more these exchanges to transfer
additional data. Using the IKE_INTERMEDIATE exchange is optional, additional data. Using the IKE_INTERMEDIATE exchange is optional,
the initiator may find it unnecessary after completing the the initiator may find it unnecessary after completing the
IKE_SA_INIT exchange. IKE_SA_INIT exchange.
The Intermediate Exchange is denoted as IKE_INTERMEDIATE, its The Intermediate Exchange is denoted as IKE_INTERMEDIATE, its
Exchange Type is <TBA by IANA>. Exchange Type is 43.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, ..., SK {...} --> HDR, ..., SK {...} -->
<-- HDR, ..., SK {...} <-- HDR, ..., SK {...}
The initiator may use several IKE_INTERMEDIATE exchanges if The initiator may use several IKE_INTERMEDIATE exchanges if
necessary. Since initiator's Window Size is initially set to one necessary. Since initiator's Window Size is initially set to one
(Section 2.3 of [RFC7296]), these exchanges MUST follow each other (Section 2.3 of [RFC7296]), these exchanges MUST follow each other
and MUST all be completed before the IKE_AUTH exchange is initiated. and MUST all be completed before the IKE_AUTH exchange is initiated.
skipping to change at page 8, line 20 skipping to change at page 8, line 20
This is important since [RFC7383] allows sending first unfragmented This is important since [RFC7383] allows sending first unfragmented
message and then resending it in fragmented form in case of no reply message and then resending it in fragmented form in case of no reply
is received. If the message was received in fragmented form, it is received. If the message was received in fragmented form, it
should be reconstructed before calculating prf as if it were received should be reconstructed before calculating prf as if it were received
unfragmented. The RESERVED field in the recontructed Encrypted unfragmented. The RESERVED field in the recontructed Encrypted
Payload header MUST be set to the value of the RESERVED field in the Payload header MUST be set to the value of the RESERVED field in the
Encrypted Fragment payload header from the first fragment (that with Encrypted Fragment payload header from the first fragment (that with
Fragment Number equal to 1). Fragment Number equal to 1).
Note that it is possible to avoid actual reconstruction of the Note that it is possible to avoid actual reconstruction of the
message by incrementally calculating prf on decrypted fragments. message by incrementally calculating prf on decrypted (or ready to be
However care must be taken to properly replace the content of the encrypted) fragments. However care must be taken to properly replace
Next Header and the Length fields so that the result of computing prf the content of the Next Header and the Length fields so that the
is the same as if it were computed on reconstructed message. 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 10, line 10 skipping to change at page 10, line 10
with known key, then the attacker could forge the IKE_INTERMEDIATE with known key, then the attacker could forge the IKE_INTERMEDIATE
exchange messages without later being detected in the IKE_AUTH exchange messages without later being detected in the IKE_AUTH
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:
<TBA> 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 Types in the "Notify
Message Types - Status Types" registry: Message Types - Status Types" registry:
<TBA> 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
also grateful to Tobias Brunner for raising good points concerning also grateful to Tobias Brunner for raising good points concerning
authentication of the IKE_INTERMEDIATE exchange. authentication of the IKE_INTERMEDIATE exchange.
 End of changes. 8 change blocks. 
15 lines changed or deleted 16 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/