[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                         V. Smyslov
Internet-Draft                                                ELVIS-PLUS
Intended status: Standards Track                           July 27, 2018
Expires: January 28, 2019


                Auxiliary Exchange in the IKEv2 Protocol
                   draft-smyslov-ipsecme-ikev2-aux-01

Abstract

   This documents defines a new exchange, called Auxiliary 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 Auxiliary
   Exchange allows to re-use existing IKE Fragmentation mechanism, that
   helps to avoid IP fragmentation of large IKE messages, but cannot be
   used in the initial IKEv2 exchange.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 http://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 28, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Smyslov                 Expires January 28, 2019                [Page 1]


Internet-Draft         Auxiliary Exchange in IKEv2             July 2018


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Notation  . . . . . . . . . . . . . . . . . .   3
   3.  Auxiliary Exchange Details  . . . . . . . . . . . . . . . . .   3
     3.1.  Support for Auxiliary Exchange Negotiation  . . . . . . .   3
     3.2.  Using Auxiliary Exchange  . . . . . . . . . . . . . . . .   4
     3.3.  IKE_AUX Protection and Authentication . . . . . . . . . .   4
       3.3.1.  Protection of IKE_AUX Messages  . . . . . . . . . . .   4
       3.3.2.  Authentication of IKE_AUX Exchanges . . . . . . . . .   5
     3.4.  Error Handling in IKE_AUX . . . . . . . . . . . . . . . .   7
   4.  Interaction with other IKEv2 Extensions . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The Internet Key Exchange protocol version 2 (IKEv2) defined in
   [RFC7296] uses UDP as a transport for its messages.  If size of the
   messages 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
   IP fragmentation.  However, the IKE Fragmentation cannot be used in
   the initial IKEv2 exchange, IKE_SA_INIT.  This limitation in most
   cases is not a problem, since the IKE_SA_INIT messages used to be
   small enough to not cause IP fragmentation.

   Recent progress in Quantum Computing has brought a concern that
   classical Diffie-Hellman key exchange methods will become insecure in
   a relatively near future and should be replaced with Quantum Computer
   (QC) resistant ones.  Currently most of QC-resistant key exchange
   methods have large public keys.  If these keys are exchanged in the
   IKE_SA_INIT, then most probably IP fragmentation would take place,
   therefore all the problems caused by it would become inevitable.

   A possible solution to the problem would be to use TCP as a transport
   for IKEv2, as described in [RFC8229].  However this approach has




Smyslov                 Expires January 28, 2019                [Page 2]


Internet-Draft         Auxiliary Exchange in IKEv2             July 2018


   significant drawbacks and is intended to be a "last resort" when UDP
   transport is blocked by intermediate network devices.

   This document defines a new exchange for the IKEv2 protocol, called
   Auxiliary Exchange or IKE_AUX.  One or more these exchanges may take
   place right after the IKE_SA_INIT exchange and prior to the IKE_AUTH
   exchange.  These exchanges may be used to exchange large amounts of
   data, which don't fit into the IKE_SA_INIT exchange without causing
   IP fragmentation.  The IKE_AUX messages can be fragmented using IKE
   Fragmentation mechanism.

   While ability to transfer large public keys of QC-resistant key
   exchange methods was a primary motivation for the Auxiliary Exchange,
   its application is not limited to this use case.  This exchange may
   be used whenever some data need to be transferred before the IKE_AUTH
   exchange and for some reason the IKE_SA_INIT exchange is not suited
   for this purpose.  It is expected that separate specifications will
   define how and when the IKE_AUX exchange is used in the IKEv2.

2.  Terminology and Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Auxiliary Exchange Details

3.1.  Support for Auxiliary Exchange Negotiation

   The initiator indicates its support for Auxiliary Exchange by
   including a notification of type AUX_EXCHANGE_SUPPORTED in the
   IKE_SA_INIT request message.  If the responder also supports this
   exchange, it includes this notification in the response message.

   Initiator                              Responder
   -----------                            -----------
   HDR, SAi1, KEi, Ni,
        [N(AUX_EXCHANGE_SUPPORTED)]  -->
                                     <--  HDR, SAr1, KEr, Nr, [CERTREQ],
                                             [N(AUX_EXCHANGE_SUPPORTED)]

   The AUX_EXCHANGE_SUPPORTED is a Status Type IKEv2 notification.  Its
   Notify Message Type is <TBA by IANA>.  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.



Smyslov                 Expires January 28, 2019                [Page 3]


Internet-Draft         Auxiliary Exchange in IKEv2             July 2018


   Implementations MUST ignore the non-empty Notification Data if they
   don't understand its purpose.

3.2.  Using Auxiliary Exchange

   If both peers indicated their support for the Auxiliary Exchange, the
   initiator may use one or more these exchanges to transfer additional
   data.  Using the IKE_AUX exchange is optional, the initiator may find
   it unnecessary after completing the IKE_SA_INIT exchange.

   The Auxiliary Exchange is denoted as IKE_AUX, its Exchange Type is
   <TBA by IANA>.

   Initiator                              Responder
   -----------                            -----------
   HDR, ..., SK {...}  -->
                                     <--  HDR, ..., SK {...}

   The initiator may use several IKE_AUX 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.  The IKE SA MUST
   NOT be considered as established until the IKE_AUTH exchange is
   successfully completed.

   The Message IDs for the IKE_AUX exchanges MUST be chosen according to
   the standard IKEv2 rule, described in the Section 2.2. of [RFC7296],
   i.e.  it is set to 1 for the first IKE_AUX exchange, 2 for the next
   (if any) and so on.  The message ID for the first pair of the
   IKE_AUTH messages is one more than the last IKE_AUX Message ID.

   The content of the IKE_AUX messages depends on the data being
   transferred and will be defined by specifications utilizing this
   exchange.  However, since the main motivation for IKE_AUX is to avoid
   IP fragmentation when large amount of data need to be transferred
   prior to IKE_AUTH, the Encrypted payload SHOULD be present in the
   IKE_AUX messages and payloads containing large data SHOULD be placed
   inside.  This will allow IKE Fragmentation [RFC7383] to take place,
   provided it is supported by the peers and negotiated in the initial
   exchange.

3.3.  IKE_AUX Protection and Authentication

3.3.1.  Protection of IKE_AUX Messages

   The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the
   IKE_AUX exchanges are computed in a standard fashion, as defined in
   the Section 2.14 of [RFC7296].  Every subsequent IKE_AUX exchange



Smyslov                 Expires January 28, 2019                [Page 4]


Internet-Draft         Auxiliary Exchange in IKEv2             July 2018


   uses the most recently calculated keys before this exchange is
   started.  The first IKE_AUX exchange always uses SK_e[i/r] and
   SK_a[i/r] keys that were computed as result the IKE_SA_INIT exchange.
   If this IKE_AUX exchange performs additional key exchange resulting
   in the update of SK_e[i/r] and SK_a[i/r], then these updated keys are
   used for encryption and authentication of next IKE_AUX exchange,
   otherwise the current keys are used, and so on.

3.3.2.  Authentication of IKE_AUX Exchanges

   The data transferred in the IKE_AUX exchanges must be authenticated
   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
   modified as follows:

 InitiatorSignedOctets = RealMessage1 | AUX_I | NonceRData | MACedIDForI
 AUX_I =  [AUX_PRF_I_1 [| AUX_PRF_I_2 [| AUX_PRF_I_3]]] ...
 AUX_PRF_I_1 = prf(SK_pi_1, IKE_AUX_I_1_H [| IKE_AUX_I_1_E])
 AUX_PRF_I_2 = prf(SK_pi_2, IKE_AUX_I_2_H [| IKE_AUX_I_2_E])
 AUX_PRF_I_3 = prf(SK_pi_3, IKE_AUX_I_3_H [| IKE_AUX_I_3_E])
 ...

 ResponderSignedOctets = RealMessage2 | AUX_R | NonceIData | MACedIDForR
 AUX_R =  [AUX_PRF_R_1 [| AUX_PRF_R_2 [| AUX_PRF_R_3]]] ...
 AUX_PRF_R_1 = prf(SK_pr_1, IKE_AUX_R_1_H [| IKE_AUX_R_1_E])
 AUX_PRF_R_2 = prf(SK_pr_2, IKE_AUX_R_2_H [| IKE_AUX_R_2_E])
 AUX_PRF_R_3 = prf(SK_pr_3, IKE_AUX_R_3_H [| IKE_AUX_R_3_E])
 ...

   AUX_PRF_I_1/AUX_PRF_R_1, AUX_PRF_I_2/AUX_PRF_R_2, AUX_PRF_I_3/
   AUX_PRF_R_1, etc. represent the results of applying the negotiated
   prf to the content of the IKE_AUX messages sent by the initiator
   (AUX_PRF_I_*) by the responder (AUX_PRF_R_*) in an order of
   increasing MessageIDs (i.e. in an order the IKE_AUX exchanges took
   place).  The prf is applied to the two chunks of data: IKE_AUX_[I/
   R]_*_H and optionally IKE_AUX_[I/R]_*_E.  The IKE_AUX_[I/R]_*_H chunk
   lasts from the first octet of the IKE Header (not including prepended
   four octets of zeros, if any) to the last octet of the Encrypted
   Payload header (or to the end of the message in case the Encrypted
   payload is not present).  The IKE_AUX_[I/R]_*_E chunk is computed if
   the Encrypted payload is present and consists of the not yet
   encrypted content of the Encrypted payload, excluding Initialization
   Vector, Padding, Pad Length and Integrity Checksum Data fields (see
   3.14 of [RFC7296] for description of the Encrypted payload).  In
   other words, the IKE_AUX_[I/R]_*_E chunk is the inner payloads of the
   Encrypted payload in plaintext form.





Smyslov                 Expires January 28, 2019                [Page 5]


Internet-Draft         Auxiliary Exchange in IKEv2             July 2018


                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^
   |                       IKE SA Initiator's SPI                  | | |
   |                                                               | | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I |
   |                       IKE SA Responder's SPI                  | K |
   |                                                               | E |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   |  Next Payload | MjVer | MnVer | Exchange Type |     Flags     | H |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d |
   |                          Message ID                           | r H
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
   |                            Length                             | | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v |
   |                                                               |   |
   ~                 Unencrypted payloads (if any)                 ~   |
   |                                                               |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |
   | Next Payload  |C|  RESERVED   |         Payload Length        | | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E v
   |                     Initialization Vector                     | n
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^
   |                                                               | r |
   ~             Inner payloads (not yet encrypted)                ~   E
   |                                                               | P |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v
   |              Padding (0-255 octets)           |  Pad Length   | d
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   ~                    Integrity Checksum Data                    ~ |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v

            Figure 1: Data to Authenticate in IKE_AUX Exchange

   Figure 1 illustrates the layout of the IKE_AUX_*_*_H (denoted as H)
   and the IKE_AUX_*_*_E (denoted as E) chunks in case the Encrypted
   payload is present in the message.  Note, that while the Encrypted
   payload is not required to be present in the IKE_AUX messages, the
   intended purpose of this exchange is to allow transferring large
   amount of data utilizing IKE fragmentation, so in most cases the
   Encrypted payload will be present.

   The calculations are applied to whole messages only, before possible
   fragmentation.  This ensures that the AUX_I/AUX_R will be the same
   regardless of whether fragmentation takes place or not ([RFC7383]
   allows sending first unfragmented message and then trying
   fragmentation in case of no reply).




Smyslov                 Expires January 28, 2019                [Page 6]


Internet-Draft         Auxiliary Exchange in IKEv2             July 2018


   Each calculation of AUX_PRF_[I/R]_* uses its own key SK_p[i/r]_*,
   which is the most recently updated SK_p[i/r] key available before the
   corresponded IKE_AUX exchange is started.  The first IKE_AUX exchange
   always uses SK_p[i/r] key that was computed in the IKE_SA_INIT as
   SK_p[i/r]_1.  If the first IKE_AUX exchange performs additional key
   exchange resulting in SK_p[i/r] update, then this updated SK_p[i/r]
   is used as SK_p[i/r]_2, otherwise the original SK_p[i/r] is used, and
   so on.  Note, that if keys are updated then for any given IKE_AUX
   exchange the keys SK_e[i/r] and SK_a[i/r] used for IKE_AUX messages
   protection (see Section 3.3.1) and the keys SK_p[i/r] for their
   authentication are always from the same generation.

3.4.  Error Handling in IKE_AUX

   Since IKE_AUX messages are not authenticated until the IKE_AUTH
   exchange successfully completes, possible errors need to be handled
   carefully.  There is a trade-off between providing a better
   diagnostics of the problem and a risk to become a part of DoS attack.
   See Section 2.21.1 and 2.21.2 of [RFC7296] describe how errors are
   handled in initial IKEv2 exchanges, these considerations are applied
   to an IKE_AUX exchange too.

4.  Interaction with other IKEv2 Extensions

   The IKE_AUTH exchanges may be used in the IKEv2 Session Resumption
   [RFC5723] between the IKE_SESSION_RESUME and the IKE_AUTH exchanges.

5.  Security Considerations

   The data that is transferred by means of the IKE_AUX exchanges is not
   authenticated until the subsequent IKE_AUTH exchange is completed.
   However, if the data is placed inside the Encrypted payload, then it
   is protected from passive eavesdroppers.  In addition the peers can
   be certain that they receives messages from the party he/she
   performed the IKE_SA_INIT with if they can successfully verify the
   Integrity Checksum Data of the Encrypted payload.

   The main application for Auxiliary Exchange is to transfer large
   amount of data before IKE SA is set up without causing IP
   fragmentation.  For that reason it is expected that in most cases IKE
   Fragmentation will be employed in the IKE_AUX exchanges.  Section 5
   of [RFC7383] contains security considerations for IKE Fragmentation.

   Note, that if an attacker was able to break key exchange in real time
   (e.g. by means of Quantum Computer), then the security of IKE_AUX
   would degrade.  In particular, such an attacker would be able both to
   read data contained in the Encrypted payload and to forge it.  The
   forgery would become evident in the IKE_AUTH exchange (provided the



Smyslov                 Expires January 28, 2019                [Page 7]


Internet-Draft         Auxiliary Exchange in IKEv2             July 2018


   attacker cannot break employed authentication mechanism), but the
   ability to inject forged IKE_AUX messages with valid ICV would allow
   the attacker to mount Denial-of-Service attack.  Moreover, if in this
   situation the negotiated prf was not secure against preimage attack
   with known key, then the attacker could forge IKE_AUX messages
   without later being detected in the IKE_AUTH exchange.  To do this
   the attacker should find the same AUX_PRF_*_* value for the forged
   message as for original.

6.  IANA Considerations

   This document defines a new Exchange Type in the "IKEv2 Exchange
   Types" registry:

     <TBA>       IKE_AUX

   This document also defines a new Notify Message Types in the "Notify
   Message Types - Status Types" registry:

     <TBA>       AUX_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
   IKE_AUX exchange and helped to resolve it.

8.  References

8.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, <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.






Smyslov                 Expires January 28, 2019                [Page 8]


Internet-Draft         Auxiliary Exchange in IKEv2             July 2018


   [RFC7383]  Smyslov, V., "Internet Key Exchange Protocol Version 2
              (IKEv2) Message Fragmentation", RFC 7383,
              DOI 10.17487/RFC7383, November 2014, <https://www.rfc-
              editor.org/info/rfc7383>.

8.2.  Informative References

   [RFC8229]  Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
              of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
              August 2017, <https://www.rfc-editor.org/info/rfc8229>.

   [RFC5723]  Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
              Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
              DOI 10.17487/RFC5723, January 2010, <https://www.rfc-
              editor.org/info/rfc5723>.

Author's Address

   Valery Smyslov
   ELVIS-PLUS
   PO Box 81
   Moscow (Zelenograd)  124460
   RU

   Phone: +7 495 276 0211
   Email: svan@elvis.ru

























Smyslov                 Expires January 28, 2019                [Page 9]


Html markup produced by rfcmarkup 1.128, available from https://tools.ietf.org/tools/rfcmarkup/