Network Working Group CJ. Tjhai Internet-Draft Post-Quantum Intended status: Standards Track T. Heider Expires: May 5, 2021 genua GmbH V. Smyslov ELVIS-PLUS November 1, 2020 Beyond 64KB Limit of IKEv2 Payload draft-tjhai-ikev2-beyond-64k-limit-00 Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document assumes familiarity with IKEv2 concept described in [RFC7296]. 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, N(IKEV2_FRAGMENTATION_SUPPORTED)*, N(INTERMEDIATE_EXCHANGE_SUPPORTED) ---> HDR, SAr1, KEr1, Nr, N(IKEV2_FRAGMENTATION_SUPPORTED)*, <--- 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 [RFC7383]. 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, N(IKEV2_FRAGMENTATION_SUPPORTED)*, N(INTERMEDIATE_EXCHANGE_SUPPORTED) ---> HDR, SAr1, KEr1, Nr, N(IKEV2_FRAGMENTATION_SUPPORTED)*, <--- 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 stream. 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 implemented. If TCP encapsulation is used, refer to the security considerations in [RFC8229]. 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 [I-D.ietf-ipsecme-ikev2-intermediate] Smyslov, V., "Intermediate Exchange in the IKEv2 Protocol", draft-ietf-ipsecme-ikev2-intermediate-05 (work in progress), September 2020. [I-D.ietf-ipsecme-ikev2-multiple-ke] 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, . [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, . [CM] Classic McEliece submission team, "Classic McEliece: NIST post-quantum cryptography standardization finalist", 2020, . [FIPS-202] National Institute of Standards and Technology, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", 2015, . [McEliece] McEliece, R., "A Public-key Cryptosystem based on Algebraic Coding Theory", DSN Progress Report 42-44, 1978. [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, . Authors' Addresses CJ Tjhai Post-Quantum UK Email: cjt@post-quantum.com Tobias Heider genua GmbH DE Email: me@tobhe.de Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 RU Phone: +7 495 276 0211 Email: svan@elvis.ru Tjhai, et al. Expires May 5, 2021 [Page 11]