[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Network Working Group                                          CJ. Tjhai
Internet-Draft                                              Post-Quantum
Intended status: Standards Track                               T. Heider
Expires: May 5, 2021                                          genua GmbH
                                                              V. Smyslov
                                                        November 1, 2020

                   Beyond 64KB Limit of IKEv2 Payload


   The maximum Internet Key Exchange Version 2 (IKEv2) payload size is
   limited to 64KB.  This makes IKEv2 not usable for conservative post-
   quantum cryptosystem whose public-key is larger than 64KB.  This
   document describes the mechanisms and considerations to exchange such
   large key-establishment data in IKEv2.

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 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 May 5, 2021.

Copyright Notice

   Copyright (c) 2020 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
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Tjhai, et al.              Expires May 5, 2021                  [Page 1]

Internet-Draft                 Beyond 64KB                 November 2020

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Fragmentation of Large Payload  . . . . . . . . . . . . . . .   4
     2.1.  Hash and URL  . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.1.  Key Exchange Payload  . . . . . . . . . . . . . . . .   4
       2.1.2.  Certificate Payload . . . . . . . . . . . . . . . . .   5
     2.2.  Payload Fragmentation . . . . . . . . . . . . . . . . . .   5
       2.2.1.  Bulk Transfer and Confirmation  . . . . . . . . . . .   6
       2.2.2.  Incremental Transfer and Confirmation . . . . . . . .   7
   3.  Operational Considerations  . . . . . . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     5.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Our digital communications are secured by public-key cryptography
   algorithms that relies on computational hardness assumptions such as
   the difficulty in factoring large integers or that of finding the
   discrete logarithm on an elliptic curve group or finite-field.
   Recent advances in quantum computing, however, have caused some
   concerns on the security of these assumptions.  It is conjectured
   that these hard computational problems can be solved in polynomial
   time when sufficiently large quantum computers become available.  The
   concerns have prompted the National Institute of Standards and
   Technology (NIST) to initiate a process to standardize one or more
   public-key algorithms that are quantum-resistant.  This family of
   algorithms is known as post-quantum or quantum-resistant
   cryptographic algorithms.

   It would be ideal if these cryptographic algorithms can be drop-in
   replacements to the classical algorithms we currently use.
   Unfortunately, almost all of the post-quantum cryptography algorithms
   have either public-key, ciphertext or signature size that is many
   times larger than their classical counterparts.  One of the issues
   that this will cause, in particular for UDP-based protocols such as
   IPsec, is fragmentation of packets at IP layer.  In the context of
   IPsec/IKEv2 post-quantum key exchange, the fragmentation issue can be
   addressed by sending the post-quantum exchange data in
   IKE_INTERMEDIATE [I-D.ietf-ipsecme-ikev2-intermediate], which is the

Tjhai, et al.              Expires May 5, 2021                  [Page 2]

Internet-Draft                 Beyond 64KB                 November 2020

   intermediary state between IKE_SA_INIT and IKE_AUTH.  This is the
   approach taken in [I-D.ietf-ipsecme-ikev2-multiple-ke] whereby a
   classical and one or more post-quantum key exchanges are combined in
   order to establish security associations that are quantum-resistant.

   Because all public-key cryptography algorithms rely on computational
   hardness assumptions, the confidence of a cryptographic algorithm is
   an important consideration.  An algorithm that has been well-studied
   and field-tested is better trusted than newer ones.  Unfortunately,
   the confidence of post-quantum cryptographic algorithms is relatively
   low.  All of the algorithms submitted to NIST post-quantum
   standardization are based on new computational hardness assumptions
   and despite being conjectured to be resistant to quantum computer
   attacks, they have not been well cryptanalyzed compared to the
   classical counterparts.  An exception to this is the Goppa-code based
   McEliece cryptosystem [McEliece] which has withstood years of
   cryptanalysis since 1978 and still remains unbroken.  It is not
   surprising that a more efficient and CCA secure version of McEliece
   cryptosystem, Classic McEliece [CM], is selected as one of the
   finalists in NIST post-quantum standardization.  Furthermore, this
   cryptosystem has also been recommended for long-term confidentiality
   protection of data, see [BSI].

   While there is interest in using McEliece cryptosystem, in particular
   for information that needs to remain secure for a long time, there is
   a challenge in integrating it with IKEv2 [RFC7296].  One
   characteristic of McElieces cryptosystem is the very asymmetric size
   of its ciphertext and public-key.  While its ciphertext is the
   smallest compared to all other post-quantum key-establishment
   algorithms submitted to NIST, the size of its public-key, however, is
   the largest.  The smallest public-key size of Classic McEliece is
   255KB.  This presents a problem if one were to use Classic McEliece
   for key-establishment with IKEv2, as the maximum payload size
   supported by IKEv2 is limited to 64KB.  This document describes a
   mechanism to support IKEv2 key-exchange with key size larger than
   64KB, building on the works in [I-D.ietf-ipsecme-ikev2-multiple-ke]
   and [I-D.ietf-ipsecme-ikev2-intermediate].

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   This document assumes familiarity with IKEv2 concept described in

Tjhai, et al.              Expires May 5, 2021                  [Page 3]

Internet-Draft                 Beyond 64KB                 November 2020

2.  Fragmentation of Large Payload

   A method to extend IKEv2 that allows quantum-resistant shared secret
   to be derived from at least one post-quantum key-establishment
   algorithm is proposed in [I-D.ietf-ipsecme-ikev2-multiple-ke].  Each
   post-quantum key-establishment data is transported using an
   IKE_INTERMEDIATE message, which appears following an IKE_SA_INIT
   exchange.  This is necessary because most post-quantum key-
   establishment data are larger than 1KB and therefore are likely to be
   dropped by firewalls and network middleboxes if they are sent in the
   IKE_SA_INIT message over a UDP channel.  IKEv2 has a mechanism to
   handle IP-level fragmentation [RFC7383], but it is only available to
   messages sent after the IKE_SA_INIT exchange.  As such, it is
   necessary to send these post-quantum key-establishment payloads in
   IKE_INTERMEDIATE so that it can benefit from the IKEv2 message
   fragmentation mechanism.

   IKEv2 message fragmentation [RFC7383] allows a big payload to be
   broken up into a number of smaller UDP datagrams.  However, this
   mechanism can only be used to fragment payloads up to 64KB in size.
   For larger messages, different mechanisms are required and two of
   which are discussed below.

2.1.  Hash and URL

   [RFC7296] defines a mechanism whereby an authentication payload such
   as a certificate can be encoded using a hash value and a URL.  A peer
   utilizes HTTP_CERT_LOOKUP_SUPPORTED Notify payload to indicate that
   X.509 certificates are not transported in-band, instead the other
   peer shall fetch the certificates from the given URL and verify its
   integrity from the hash value.  In this way, the peer needs to send
   20 octets plus a variable length URL only over the wire, instead of a
   few kilobytes of payload, which is useful in the event IKEv2 message
   fragmentation is not available.

   Large public keys can be transported by reusing the same technique
   and this can be done in two ways, as described below.

2.1.1.  Key Exchange Payload

   The Key Exchange Data field of IKEv2 Key Exchange Payload contains a
   single format, which is a blob that is only meaningful to the
   specified key exchange method.  In order to support hash and URL
   data, an encoding format needs to be specified on the header.

Tjhai, et al.              Expires May 5, 2021                  [Page 4]

Internet-Draft                 Beyond 64KB                 November 2020

                          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
     | Next Payload  |C|F| RESERVED  |         Payload Length        |
     |      Key Exchange Method      |           RESERVED            |
     |                                                               |
     ~                       Key Exchange Data                       ~
     |                                                               |

   The reserved bit-field F above specifies the encoding format.  If it
   is 0, the Key Exchange Data is a blob as specified in RFC7296.  On
   the other hand if it is 1, the Key Exchange Data is in the form of
   hash and URL format, whereby the hash value is the SHA3-256 digest
   [FIPS-202] of the replaced value truncated to 20 octets and the URL
   value is a variable length URL (in either http or https schema) that
   resolves to the DER-encoded of the replaced value itself.

   Because the hash and URL value is transported in a Key Exchange
   Payload, it is possible to support the use-case of a single post-
   quantum key-establishment with large public-key.  This payload will
   be sent as part of IKE_SA_INIT exchange and it will not require
   IKE_INTERMEDIATE exchanges.

2.1.2.  Certificate Payload

   An alternative is to re-purpose Certificate Payload to carry the hash
   and URL value of the post-quantum key-establishment data.  At the
   time of writing, the IANA registry defines two hash and URL encoding
   values, namely X.509 certificate and X.509 certificate bundle.  In
   order to use this payload, a new encoding value for key establishment
   data will be required.

   Because a Certificate Payload is part of IKE_AUTH message, unlike the
   previous approach, the hash and URL value of the key-establishment
   data shall be transported via IKE_INTERMEDIATE message.  As such, it
   will not be able to support a single post-quantum key-establishment
   with a large public-key case.  Furthermore, it is semantically
   incorrect to repurpose Certificate Payload, which is intended to
   carry authentication data, to transport key-establishment data.

2.2.  Payload Fragmentation

   As mentioned earlier, IKEv2 support for fragmentation as specified in
   [RFC7383] allows IKE messages up to 64KB to be broken down into
   smaller fragments.  While the size of IKE payloads is constrained to

Tjhai, et al.              Expires May 5, 2021                  [Page 5]

Internet-Draft                 Beyond 64KB                 November 2020

   a 16-bit field, an IKE message itself has a 32-bit length field and
   therefore, in order to support payloads larger than 64KB limit, a
   fragmentation needs to be carried out at an upper level.  In this
   case, the large key-establishment data is first fragmented into a
   number of payload fragments that are no bigger than 64KB and each of
   which is subjected to further fragmentation using IKEv2 standard
   message fragmentation when transported in IKE_INTERMEDIATE messages.

   There are two possible ways to perform large payload fragmentation,
   as discussed below.

2.2.1.  Bulk Transfer and Confirmation

   The large key-establishment payload is first split into a sequence of
   Key Exchange payload chunks where each share the same value of Key
   Exchange Method value and has no more than 64KB in size.  This
   sequence of payload chunks is encrypted and is treated as an
   Encrypted and Authenticated payload as per Section 3.14 of [RFC7296],
   which is then sent over an IKE_INTERMEDIATE message.

    Initiator                      Responder
    HDR, SAi1, KEi1, Ni,

                                   HDR, SAr1, KEr1, Nr,
                             <---    N(INTERMEDIATE_EXCHANGE_SUPPORTED)

    HDR, SK{KEi2.1, KEi2.2, KEi2.3, ...} --->

                             <---  HDR, SK{KEr2, ...}
    *: optional

   While the IKE header (HDR) has a 32-bit field to denote the length of
   its message, that for Encrypted payload header (SK) is capped at
   16-bit, which is not long enough.  As a consequence, the payload
   length field of the Encrypted Payload SHALL be set to 0.  Because the
   Encrypted payload is always the last payload in an IKE message, it is
   possible to compute the encrypted IKE payload length instead of
   relying on the information in its payload length field.

   When IKEv2 standard message fragmentation is used, each of the Key
   Exchange payload chunk is subjected to further fragmentation as per

Tjhai, et al.              Expires May 5, 2021                  [Page 6]

Internet-Draft                 Beyond 64KB                 November 2020

2.2.2.  Incremental Transfer and Confirmation

   As stated in Section 4 of [RFC7383], if any single fragment is lost,
   the receiving peer will not be able to reassemble the original large
   key-establishment payload.  The above bulk transfer is susceptible to
   this issue.  There is another way to transfer these payload chunks
   that is less susceptible to this, but at the cost of higher latency.
   Instead of transferring in a bulk, each Key Exchange payload chunk
   must be acknowledged prior to sending the subsequent chunk.  As
   before, the large key-establishment payload is split over several Key
   Exchange payload chunks where each of them share the same Key
   Exchange Method value.  Each chunk is then sent to the peer using the
   IKE_INTERMEDIATE message, and each one must be acknowledged by the
   receiving peer before the subsequent chunk can be sent.

    Initiator                      Responder
    HDR, SAi1, KEi1, Ni,

                                   HDR, SAr1, KEr1, Nr,
                             <---    N(INTERMEDIATE_EXCHANGE_SUPPORTED)

    HDR, SK{KEi2.1, ...}     --->

                             <---  HDR, SK{}

    HDR, SK{KEi2.2, ...}     --->

                             <---  HDR, SK{}

    HDR, SK{KEi2.3, ...}     --->

                             <---  HDR, SK{KEr2, ...}

    HDR, SK{}                --->

    *: optional

   In order to support key-encapsulation mechanism, the receiving peer
   has to wait until the entire chunks are received before it can
   respond with its own Key Exchange payload, which may not be large.

   While the description above focuses on the transfer of Key Exchange
   payload larger than 64KB, the same approach can be used to transfer
   large public-key, certificate or signature if there is a need to

Tjhai, et al.              Expires May 5, 2021                  [Page 7]

Internet-Draft                 Beyond 64KB                 November 2020

   support hybrid authentication or even multiple certificates with
   large constituent component.

3.  Operational Considerations

   While using hash and URL method to transport large key-establishment
   data requires minimal modification to IKEv2 protocol, there are
   disadvantages from deployment point of view that may make this method
   impractical.  Firstly, an IKE peer that originates a hash and URL
   value will also need to implement additional infrastructure so that
   it can serve HTTP requests in order to allow the actual key-
   establishment data to be fetched.  While this may not be an issue for
   Internet facing peers, in the context of road-warrior or remote-
   access cases, the hash and URL value is initiated by an IKE peer that
   is usually a device sitting behind a network address translation
   (NAT) device and as such, it may not be able to run a publicly
   reachable HTTP server infrastructure on the same device.  An possible
   solution for these cases is to publish the key-establishment data to
   a separate server, which is not practical as one cannot expect an IKE
   initiator to always have deployed an HTTP server.  Lastly, IKE peers
   are predominantly deployed at the network edge where strict firewall
   rules are generally enforced.  The need to open up another port to
   serve HTTP requests may cause either technical or policy complication
   that render this approach unacceptable.

   Unlike the aforementioned hash and URL method, the payload
   fragmentation method does not require additional infrastructure,
   however, there is non-zero probability of lost packets when sending a
   large number of fragments over a UDP connection.  Given a set of
   fragments, when transmitted, each one of them is not individually
   acknowledged and if any one of them is lost, the entire set will have
   to be retransmitted.  As a consequence, given the size of the payload
   and also the potential of multiple retransmissions, there may be a
   noticeable delay in establishing an security association (SA), in
   particular in lossy network conditions.  Therefore, implementations
   MAY use a longer timeout value for the purpose of dead-peer
   detection, but a balance needs to be struck as too large of a value
   will open up security vulnerabilities as discussed in the following
   section.  In the unlikely event where there is a frequent
   retransmission due to loss of fragments, implementations MAY send the
   IKE messages over a TCP connection as specified in [RFC8229].  In
   this instance, the peers SHOULD NOT advertise support for IKE
   fragmentation as this is already handled inherently by the TCP

Tjhai, et al.              Expires May 5, 2021                  [Page 8]

Internet-Draft                 Beyond 64KB                 November 2020

4.  Security Considerations

   The hash and URL approach is vulnerable to (distributed) denial of
   service attacks as an unauthenticated rogue peer may trick a
   legitimate peer to fetch a large amount of random meaningless data
   from a remote server.  Implementations SHOULD NOT blindly download
   all of the data in the given URL.  Because a legitimate key-
   establishment payload should be DER-encoded, they SHOULD download the
   first few octets to determine the length of the ASN.1 structure
   representing these octets, then only continue to download the
   remaining decoded number of octets if the length is expected for the
   chosen key-establishment algorithm.  It should be noted that the
   content of the data to be downloaded may be under attacker's control
   and therefore even if the length is as expected, the content may be
   meaningless bit that is of no use for key-establishment.

   There is no exception to the payload fragmentation method, it is also
   vulnerable to the same attack vectors.  Malicious peers may send a
   large number of fragments, but incomplete, to the legitimate peer
   causing memory exhaustion.

   In order to counter these attacks, downloading or accepting the
   transfer of a large number of octets SHOULD only be carried out when
   the peer has been authenticated.  In other words, key-establishment
   using large data should not be done to establish an IKE SA, but it
   should only be used to establish Child SA or rekeying of IKE SA from
   Child SA.  If, for whatever reason, an IKE SA has to be established
   using the large key-establishment data, then it is RECOMMENDED that
   the strategies and recommendations described in [RFC8019] be

   If TCP encapsulation is used, refer to the security considerations in

   Lastly, downloading or transferring large amounts of data is an
   expensive operation, bandwidth and memory wise.  Consequently,
   implementations should consider using a longer rekeying interval or
   SHOULD consider relaxing forward secrecy requirements but using CCA-
   secure key-establishment algorithm only.  With chosen-ciphertext
   attack (CCA)-secure schemes, there is no loss in security if the
   public-key is reused.

5.  References

Tjhai, et al.              Expires May 5, 2021                  [Page 9]

Internet-Draft                 Beyond 64KB                 November 2020

5.1.  Normative References

              Smyslov, V., "Intermediate Exchange in the IKEv2
              Protocol", draft-ietf-ipsecme-ikev2-intermediate-05 (work
              in progress), September 2020.

              Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S.,
              Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
              Key Exchanges in IKEv2", draft-ietf-ipsecme-ikev2-
              multiple-ke-01 (work in progress), July 2020.

   [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>.

   [RFC7383]  Smyslov, V., "Internet Key Exchange Protocol Version 2
              (IKEv2) Message Fragmentation", RFC 7383,
              DOI 10.17487/RFC7383, November 2014,

5.2.  Informative References

   [BSI]      Federal Office for Information Security, "Cryptographic
              Mechanisms: Recommendations and Key Lengths", 2020, <https

   [CM]       Classic McEliece submission team, "Classic McEliece: NIST
              post-quantum cryptography standardization finalist", 2020,

              National Institute of Standards and Technology, "SHA-3
              Standard: Permutation-Based Hash and Extendable-Output
              Functions", 2015, <https://doi.org/10.6028/NIST.FIPS.202>.

              McEliece, R., "A Public-key Cryptosystem based on
              Algebraic Coding Theory",  DSN Progress Report 42-44,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

Tjhai, et al.              Expires May 5, 2021                 [Page 10]

Internet-Draft                 Beyond 64KB                 November 2020

   [RFC8019]  Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange
              Protocol Version 2 (IKEv2) Implementations from
              Distributed Denial-of-Service Attacks", RFC 8019,
              DOI 10.17487/RFC8019, November 2016,

   [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>.

Authors' Addresses

   CJ Tjhai

   Email: cjt@post-quantum.com

   Tobias Heider
   genua GmbH

   Email: me@tobhe.de

   Valery Smyslov
   PO Box 81
   Moscow (Zelenograd)  124460

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

Tjhai, et al.              Expires May 5, 2021                 [Page 11]