idnits 2.17.1 draft-tjhai-ikev2-beyond-64k-limit-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 1, 2020) is 1264 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-ipsecme-ikev2-intermediate-05 == Outdated reference: A later version (-12) exists of draft-ietf-ipsecme-ikev2-multiple-ke-01 -- Obsolete informational reference (is this intentional?): RFC 8229 (Obsoleted by RFC 9329) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group CJ. Tjhai 3 Internet-Draft Post-Quantum 4 Intended status: Standards Track T. Heider 5 Expires: May 5, 2021 genua GmbH 6 V. Smyslov 7 ELVIS-PLUS 8 November 1, 2020 10 Beyond 64KB Limit of IKEv2 Payload 11 draft-tjhai-ikev2-beyond-64k-limit-00 13 Abstract 15 The maximum Internet Key Exchange Version 2 (IKEv2) payload size is 16 limited to 64KB. This makes IKEv2 not usable for conservative post- 17 quantum cryptosystem whose public-key is larger than 64KB. This 18 document describes the mechanisms and considerations to exchange such 19 large key-establishment data in IKEv2. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 5, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Fragmentation of Large Payload . . . . . . . . . . . . . . . 4 58 2.1. Hash and URL . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1.1. Key Exchange Payload . . . . . . . . . . . . . . . . 4 60 2.1.2. Certificate Payload . . . . . . . . . . . . . . . . . 5 61 2.2. Payload Fragmentation . . . . . . . . . . . . . . . . . . 5 62 2.2.1. Bulk Transfer and Confirmation . . . . . . . . . . . 6 63 2.2.2. Incremental Transfer and Confirmation . . . . . . . . 7 64 3. Operational Considerations . . . . . . . . . . . . . . . . . 8 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 10 68 5.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 Our digital communications are secured by public-key cryptography 74 algorithms that relies on computational hardness assumptions such as 75 the difficulty in factoring large integers or that of finding the 76 discrete logarithm on an elliptic curve group or finite-field. 77 Recent advances in quantum computing, however, have caused some 78 concerns on the security of these assumptions. It is conjectured 79 that these hard computational problems can be solved in polynomial 80 time when sufficiently large quantum computers become available. The 81 concerns have prompted the National Institute of Standards and 82 Technology (NIST) to initiate a process to standardize one or more 83 public-key algorithms that are quantum-resistant. This family of 84 algorithms is known as post-quantum or quantum-resistant 85 cryptographic algorithms. 87 It would be ideal if these cryptographic algorithms can be drop-in 88 replacements to the classical algorithms we currently use. 89 Unfortunately, almost all of the post-quantum cryptography algorithms 90 have either public-key, ciphertext or signature size that is many 91 times larger than their classical counterparts. One of the issues 92 that this will cause, in particular for UDP-based protocols such as 93 IPsec, is fragmentation of packets at IP layer. In the context of 94 IPsec/IKEv2 post-quantum key exchange, the fragmentation issue can be 95 addressed by sending the post-quantum exchange data in 96 IKE_INTERMEDIATE [I-D.ietf-ipsecme-ikev2-intermediate], which is the 97 intermediary state between IKE_SA_INIT and IKE_AUTH. This is the 98 approach taken in [I-D.ietf-ipsecme-ikev2-multiple-ke] whereby a 99 classical and one or more post-quantum key exchanges are combined in 100 order to establish security associations that are quantum-resistant. 102 Because all public-key cryptography algorithms rely on computational 103 hardness assumptions, the confidence of a cryptographic algorithm is 104 an important consideration. An algorithm that has been well-studied 105 and field-tested is better trusted than newer ones. Unfortunately, 106 the confidence of post-quantum cryptographic algorithms is relatively 107 low. All of the algorithms submitted to NIST post-quantum 108 standardization are based on new computational hardness assumptions 109 and despite being conjectured to be resistant to quantum computer 110 attacks, they have not been well cryptanalyzed compared to the 111 classical counterparts. An exception to this is the Goppa-code based 112 McEliece cryptosystem [McEliece] which has withstood years of 113 cryptanalysis since 1978 and still remains unbroken. It is not 114 surprising that a more efficient and CCA secure version of McEliece 115 cryptosystem, Classic McEliece [CM], is selected as one of the 116 finalists in NIST post-quantum standardization. Furthermore, this 117 cryptosystem has also been recommended for long-term confidentiality 118 protection of data, see [BSI]. 120 While there is interest in using McEliece cryptosystem, in particular 121 for information that needs to remain secure for a long time, there is 122 a challenge in integrating it with IKEv2 [RFC7296]. One 123 characteristic of McElieces cryptosystem is the very asymmetric size 124 of its ciphertext and public-key. While its ciphertext is the 125 smallest compared to all other post-quantum key-establishment 126 algorithms submitted to NIST, the size of its public-key, however, is 127 the largest. The smallest public-key size of Classic McEliece is 128 255KB. This presents a problem if one were to use Classic McEliece 129 for key-establishment with IKEv2, as the maximum payload size 130 supported by IKEv2 is limited to 64KB. This document describes a 131 mechanism to support IKEv2 key-exchange with key size larger than 132 64KB, building on the works in [I-D.ietf-ipsecme-ikev2-multiple-ke] 133 and [I-D.ietf-ipsecme-ikev2-intermediate]. 135 1.1. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 This document assumes familiarity with IKEv2 concept described in 142 [RFC7296]. 144 2. Fragmentation of Large Payload 146 A method to extend IKEv2 that allows quantum-resistant shared secret 147 to be derived from at least one post-quantum key-establishment 148 algorithm is proposed in [I-D.ietf-ipsecme-ikev2-multiple-ke]. Each 149 post-quantum key-establishment data is transported using an 150 IKE_INTERMEDIATE message, which appears following an IKE_SA_INIT 151 exchange. This is necessary because most post-quantum key- 152 establishment data are larger than 1KB and therefore are likely to be 153 dropped by firewalls and network middleboxes if they are sent in the 154 IKE_SA_INIT message over a UDP channel. IKEv2 has a mechanism to 155 handle IP-level fragmentation [RFC7383], but it is only available to 156 messages sent after the IKE_SA_INIT exchange. As such, it is 157 necessary to send these post-quantum key-establishment payloads in 158 IKE_INTERMEDIATE so that it can benefit from the IKEv2 message 159 fragmentation mechanism. 161 IKEv2 message fragmentation [RFC7383] allows a big payload to be 162 broken up into a number of smaller UDP datagrams. However, this 163 mechanism can only be used to fragment payloads up to 64KB in size. 164 For larger messages, different mechanisms are required and two of 165 which are discussed below. 167 2.1. Hash and URL 169 [RFC7296] defines a mechanism whereby an authentication payload such 170 as a certificate can be encoded using a hash value and a URL. A peer 171 utilizes HTTP_CERT_LOOKUP_SUPPORTED Notify payload to indicate that 172 X.509 certificates are not transported in-band, instead the other 173 peer shall fetch the certificates from the given URL and verify its 174 integrity from the hash value. In this way, the peer needs to send 175 20 octets plus a variable length URL only over the wire, instead of a 176 few kilobytes of payload, which is useful in the event IKEv2 message 177 fragmentation is not available. 179 Large public keys can be transported by reusing the same technique 180 and this can be done in two ways, as described below. 182 2.1.1. Key Exchange Payload 184 The Key Exchange Data field of IKEv2 Key Exchange Payload contains a 185 single format, which is a blob that is only meaningful to the 186 specified key exchange method. In order to support hash and URL 187 data, an encoding format needs to be specified on the header. 189 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Next Payload |C|F| RESERVED | Payload Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Key Exchange Method | RESERVED | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | | 197 ~ Key Exchange Data ~ 198 | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 The reserved bit-field F above specifies the encoding format. If it 202 is 0, the Key Exchange Data is a blob as specified in RFC7296. On 203 the other hand if it is 1, the Key Exchange Data is in the form of 204 hash and URL format, whereby the hash value is the SHA3-256 digest 205 [FIPS-202] of the replaced value truncated to 20 octets and the URL 206 value is a variable length URL (in either http or https schema) that 207 resolves to the DER-encoded of the replaced value itself. 209 Because the hash and URL value is transported in a Key Exchange 210 Payload, it is possible to support the use-case of a single post- 211 quantum key-establishment with large public-key. This payload will 212 be sent as part of IKE_SA_INIT exchange and it will not require 213 IKE_INTERMEDIATE exchanges. 215 2.1.2. Certificate Payload 217 An alternative is to re-purpose Certificate Payload to carry the hash 218 and URL value of the post-quantum key-establishment data. At the 219 time of writing, the IANA registry defines two hash and URL encoding 220 values, namely X.509 certificate and X.509 certificate bundle. In 221 order to use this payload, a new encoding value for key establishment 222 data will be required. 224 Because a Certificate Payload is part of IKE_AUTH message, unlike the 225 previous approach, the hash and URL value of the key-establishment 226 data shall be transported via IKE_INTERMEDIATE message. As such, it 227 will not be able to support a single post-quantum key-establishment 228 with a large public-key case. Furthermore, it is semantically 229 incorrect to repurpose Certificate Payload, which is intended to 230 carry authentication data, to transport key-establishment data. 232 2.2. Payload Fragmentation 234 As mentioned earlier, IKEv2 support for fragmentation as specified in 235 [RFC7383] allows IKE messages up to 64KB to be broken down into 236 smaller fragments. While the size of IKE payloads is constrained to 237 a 16-bit field, an IKE message itself has a 32-bit length field and 238 therefore, in order to support payloads larger than 64KB limit, a 239 fragmentation needs to be carried out at an upper level. In this 240 case, the large key-establishment data is first fragmented into a 241 number of payload fragments that are no bigger than 64KB and each of 242 which is subjected to further fragmentation using IKEv2 standard 243 message fragmentation when transported in IKE_INTERMEDIATE messages. 245 There are two possible ways to perform large payload fragmentation, 246 as discussed below. 248 2.2.1. Bulk Transfer and Confirmation 250 The large key-establishment payload is first split into a sequence of 251 Key Exchange payload chunks where each share the same value of Key 252 Exchange Method value and has no more than 64KB in size. This 253 sequence of payload chunks is encrypted and is treated as an 254 Encrypted and Authenticated payload as per Section 3.14 of [RFC7296], 255 which is then sent over an IKE_INTERMEDIATE message. 257 Initiator Responder 258 ------------------------------------------------------------------- 259 HDR, SAi1, KEi1, Ni, 260 N(IKEV2_FRAGMENTATION_SUPPORTED)*, 261 N(INTERMEDIATE_EXCHANGE_SUPPORTED) ---> 263 HDR, SAr1, KEr1, Nr, 264 N(IKEV2_FRAGMENTATION_SUPPORTED)*, 265 <--- N(INTERMEDIATE_EXCHANGE_SUPPORTED) 267 HDR, SK{KEi2.1, KEi2.2, KEi2.3, ...} ---> 269 <--- HDR, SK{KEr2, ...} 270 *: optional 272 While the IKE header (HDR) has a 32-bit field to denote the length of 273 its message, that for Encrypted payload header (SK) is capped at 274 16-bit, which is not long enough. As a consequence, the payload 275 length field of the Encrypted Payload SHALL be set to 0. Because the 276 Encrypted payload is always the last payload in an IKE message, it is 277 possible to compute the encrypted IKE payload length instead of 278 relying on the information in its payload length field. 280 When IKEv2 standard message fragmentation is used, each of the Key 281 Exchange payload chunk is subjected to further fragmentation as per 282 [RFC7383]. 284 2.2.2. Incremental Transfer and Confirmation 286 As stated in Section 4 of [RFC7383], if any single fragment is lost, 287 the receiving peer will not be able to reassemble the original large 288 key-establishment payload. The above bulk transfer is susceptible to 289 this issue. There is another way to transfer these payload chunks 290 that is less susceptible to this, but at the cost of higher latency. 291 Instead of transferring in a bulk, each Key Exchange payload chunk 292 must be acknowledged prior to sending the subsequent chunk. As 293 before, the large key-establishment payload is split over several Key 294 Exchange payload chunks where each of them share the same Key 295 Exchange Method value. Each chunk is then sent to the peer using the 296 IKE_INTERMEDIATE message, and each one must be acknowledged by the 297 receiving peer before the subsequent chunk can be sent. 299 Initiator Responder 300 ------------------------------------------------------------------- 301 HDR, SAi1, KEi1, Ni, 302 N(IKEV2_FRAGMENTATION_SUPPORTED)*, 303 N(INTERMEDIATE_EXCHANGE_SUPPORTED) ---> 305 HDR, SAr1, KEr1, Nr, 306 N(IKEV2_FRAGMENTATION_SUPPORTED)*, 307 <--- N(INTERMEDIATE_EXCHANGE_SUPPORTED) 309 HDR, SK{KEi2.1, ...} ---> 311 <--- HDR, SK{} 313 HDR, SK{KEi2.2, ...} ---> 315 <--- HDR, SK{} 317 HDR, SK{KEi2.3, ...} ---> 319 <--- HDR, SK{KEr2, ...} 321 HDR, SK{} ---> 323 *: optional 325 In order to support key-encapsulation mechanism, the receiving peer 326 has to wait until the entire chunks are received before it can 327 respond with its own Key Exchange payload, which may not be large. 329 While the description above focuses on the transfer of Key Exchange 330 payload larger than 64KB, the same approach can be used to transfer 331 large public-key, certificate or signature if there is a need to 332 support hybrid authentication or even multiple certificates with 333 large constituent component. 335 3. Operational Considerations 337 While using hash and URL method to transport large key-establishment 338 data requires minimal modification to IKEv2 protocol, there are 339 disadvantages from deployment point of view that may make this method 340 impractical. Firstly, an IKE peer that originates a hash and URL 341 value will also need to implement additional infrastructure so that 342 it can serve HTTP requests in order to allow the actual key- 343 establishment data to be fetched. While this may not be an issue for 344 Internet facing peers, in the context of road-warrior or remote- 345 access cases, the hash and URL value is initiated by an IKE peer that 346 is usually a device sitting behind a network address translation 347 (NAT) device and as such, it may not be able to run a publicly 348 reachable HTTP server infrastructure on the same device. An possible 349 solution for these cases is to publish the key-establishment data to 350 a separate server, which is not practical as one cannot expect an IKE 351 initiator to always have deployed an HTTP server. Lastly, IKE peers 352 are predominantly deployed at the network edge where strict firewall 353 rules are generally enforced. The need to open up another port to 354 serve HTTP requests may cause either technical or policy complication 355 that render this approach unacceptable. 357 Unlike the aforementioned hash and URL method, the payload 358 fragmentation method does not require additional infrastructure, 359 however, there is non-zero probability of lost packets when sending a 360 large number of fragments over a UDP connection. Given a set of 361 fragments, when transmitted, each one of them is not individually 362 acknowledged and if any one of them is lost, the entire set will have 363 to be retransmitted. As a consequence, given the size of the payload 364 and also the potential of multiple retransmissions, there may be a 365 noticeable delay in establishing an security association (SA), in 366 particular in lossy network conditions. Therefore, implementations 367 MAY use a longer timeout value for the purpose of dead-peer 368 detection, but a balance needs to be struck as too large of a value 369 will open up security vulnerabilities as discussed in the following 370 section. In the unlikely event where there is a frequent 371 retransmission due to loss of fragments, implementations MAY send the 372 IKE messages over a TCP connection as specified in [RFC8229]. In 373 this instance, the peers SHOULD NOT advertise support for IKE 374 fragmentation as this is already handled inherently by the TCP 375 stream. 377 4. Security Considerations 379 The hash and URL approach is vulnerable to (distributed) denial of 380 service attacks as an unauthenticated rogue peer may trick a 381 legitimate peer to fetch a large amount of random meaningless data 382 from a remote server. Implementations SHOULD NOT blindly download 383 all of the data in the given URL. Because a legitimate key- 384 establishment payload should be DER-encoded, they SHOULD download the 385 first few octets to determine the length of the ASN.1 structure 386 representing these octets, then only continue to download the 387 remaining decoded number of octets if the length is expected for the 388 chosen key-establishment algorithm. It should be noted that the 389 content of the data to be downloaded may be under attacker's control 390 and therefore even if the length is as expected, the content may be 391 meaningless bit that is of no use for key-establishment. 393 There is no exception to the payload fragmentation method, it is also 394 vulnerable to the same attack vectors. Malicious peers may send a 395 large number of fragments, but incomplete, to the legitimate peer 396 causing memory exhaustion. 398 In order to counter these attacks, downloading or accepting the 399 transfer of a large number of octets SHOULD only be carried out when 400 the peer has been authenticated. In other words, key-establishment 401 using large data should not be done to establish an IKE SA, but it 402 should only be used to establish Child SA or rekeying of IKE SA from 403 Child SA. If, for whatever reason, an IKE SA has to be established 404 using the large key-establishment data, then it is RECOMMENDED that 405 the strategies and recommendations described in [RFC8019] be 406 implemented. 408 If TCP encapsulation is used, refer to the security considerations in 409 [RFC8229]. 411 Lastly, downloading or transferring large amounts of data is an 412 expensive operation, bandwidth and memory wise. Consequently, 413 implementations should consider using a longer rekeying interval or 414 SHOULD consider relaxing forward secrecy requirements but using CCA- 415 secure key-establishment algorithm only. With chosen-ciphertext 416 attack (CCA)-secure schemes, there is no loss in security if the 417 public-key is reused. 419 5. References 420 5.1. Normative References 422 [I-D.ietf-ipsecme-ikev2-intermediate] 423 Smyslov, V., "Intermediate Exchange in the IKEv2 424 Protocol", draft-ietf-ipsecme-ikev2-intermediate-05 (work 425 in progress), September 2020. 427 [I-D.ietf-ipsecme-ikev2-multiple-ke] 428 Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S., 429 Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple 430 Key Exchanges in IKEv2", draft-ietf-ipsecme-ikev2- 431 multiple-ke-01 (work in progress), July 2020. 433 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 434 Kivinen, "Internet Key Exchange Protocol Version 2 435 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 436 2014, . 438 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 439 (IKEv2) Message Fragmentation", RFC 7383, 440 DOI 10.17487/RFC7383, November 2014, 441 . 443 5.2. Informative References 445 [BSI] Federal Office for Information Security, "Cryptographic 446 Mechanisms: Recommendations and Key Lengths", 2020, . 450 [CM] Classic McEliece submission team, "Classic McEliece: NIST 451 post-quantum cryptography standardization finalist", 2020, 452 . 454 [FIPS-202] 455 National Institute of Standards and Technology, "SHA-3 456 Standard: Permutation-Based Hash and Extendable-Output 457 Functions", 2015, . 459 [McEliece] 460 McEliece, R., "A Public-key Cryptosystem based on 461 Algebraic Coding Theory", DSN Progress Report 42-44, 462 1978. 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, 466 DOI 10.17487/RFC2119, March 1997, 467 . 469 [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange 470 Protocol Version 2 (IKEv2) Implementations from 471 Distributed Denial-of-Service Attacks", RFC 8019, 472 DOI 10.17487/RFC8019, November 2016, 473 . 475 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 476 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 477 August 2017, . 479 Authors' Addresses 481 CJ Tjhai 482 Post-Quantum 483 UK 485 Email: cjt@post-quantum.com 487 Tobias Heider 488 genua GmbH 489 DE 491 Email: me@tobhe.de 493 Valery Smyslov 494 ELVIS-PLUS 495 PO Box 81 496 Moscow (Zelenograd) 124460 497 RU 499 Phone: +7 495 276 0211 500 Email: svan@elvis.ru