idnits 2.17.00 (12 Aug 2021) /tmp/idnits7028/draft-tjhai-ikev2-beyond-64k-limit-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2021) is 316 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-06 == Outdated reference: A later version (-05) exists of draft-ietf-ipsecme-ikev2-multiple-ke-02 == Outdated reference: A later version (-06) exists of draft-ietf-ipsecme-rfc8229bis-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: January 10, 2022 genua GmbH 6 V. Smyslov 7 ELVIS-PLUS 8 July 9, 2021 10 Beyond 64KB Limit of IKEv2 Payloads 11 draft-tjhai-ikev2-beyond-64k-limit-01 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 discusses the considerations and defines a mechanism to 19 exchange large post-quantum public keys and signatures 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 January 10, 2022. 38 Copyright Notice 40 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Proposed Solution Overview . . . . . . . . . . . . . . . . . 4 58 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Operational Considerations . . . . . . . . . . . . . . . . . 8 60 5. Denial of Service Considerations . . . . . . . . . . . . . . 8 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 8.2. Informative References . . . . . . . . . . . . . . . . . 10 66 Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 11 67 A.1. Hash and URL . . . . . . . . . . . . . . . . . . . . . . 11 68 A.1.1. Key Exchange Payload . . . . . . . . . . . . . . . . 11 69 A.1.2. Certificate Payload . . . . . . . . . . . . . . . . . 13 70 A.2. Incremental Transfer and Confirmation . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 Digital communications are secured by public-key cryptography 76 algorithms that rely on computational hardness assumptions such as 77 the difficulty in factoring large integers or that of finding the 78 discrete logarithm on an elliptic curve group or finite-field. 79 Recent advances in quantum computing, however, have caused some 80 concerns on the security of these assumptions. It is conjectured 81 that these hard computational problems can be solved in polynomial 82 time when sufficiently large quantum computers become available. The 83 concerns have prompted the National Institute of Standards and 84 Technology (NIST) to initiate a process to standardize one or more 85 public-key algorithms that are quantum-resistant. This family of 86 algorithms is known as post-quantum or quantum-resistant 87 cryptographic algorithms. 89 It would be ideal if these cryptographic algorithms can be drop-in 90 replacements to the classical algorithms we currently use. 91 Unfortunately, almost all of the post-quantum cryptography algorithms 92 have either public-key, ciphertext or signature size that is many 93 times larger than their classical counterparts. One of the issues 94 that this will cause, in particular for UDP-based protocols such as 95 IPsec, is fragmentation of packets at IP layer. In the context of 96 IPsec/IKEv2 post-quantum key exchange, the fragmentation issue can be 97 addressed by sending the post-quantum exchange data in 98 IKE_INTERMEDIATE [I-D.ietf-ipsecme-ikev2-intermediate], which is the 99 intermediary state between IKE_SA_INIT and IKE_AUTH. This is the 100 approach taken in [I-D.ietf-ipsecme-ikev2-multiple-ke] whereby a 101 classical and one or more post-quantum key exchanges are combined in 102 order to establish security associations that are quantum-resistant. 104 Because all public-key cryptography algorithms rely on computational 105 hardness assumptions, the confidence of a cryptographic algorithm is 106 an important consideration. An algorithm that has been well-studied 107 and field-tested is generally better trusted than newer ones. 108 Unfortunately, the confidence of post-quantum cryptographic 109 algorithms is relatively low. All of the algorithms submitted to 110 NIST post-quantum standardization are based on new computational 111 hardness assumptions and despite being conjectured to be resistant to 112 quantum computer attacks, they have not been well cryptanalyzed 113 compared to the classical counterparts. An exception to this is the 114 Goppa-code based McEliece cryptosystem [McEliece] which has withstood 115 years of cryptanalysis since 1978 and still remains unbroken. It is 116 not surprising that a more efficient and CCA secure version of 117 McEliece cryptosystem, Classic McEliece [CM], is selected as one of 118 the finalists in NIST post-quantum cryptography standardization (at 119 the time of writing this document) [NIST]. Furthermore, this 120 cryptosystem has also been recommended for long-term confidentiality 121 protection of data, see [BSI]. 123 While there is interest in using McEliece cryptosystem, in particular 124 for information that needs to remain secure for a long time, there is 125 a challenge in integrating it with IKEv2 [RFC7296]. One 126 characteristic of McElieces cryptosystem is the very asymmetric size 127 of its ciphertext and public-key. While its ciphertext is the 128 smallest compared to all other post-quantum key-establishment 129 algorithms submitted to NIST, the size of its public-key, however, is 130 the largest. The smallest public-key size of Classic McEliece is 131 255KB. This presents a problem if one were to use Classic McEliece 132 for key-establishment with IKEv2, as the maximum payload size 133 supported by IKEv2 is limited to 64KB. This document describes a 134 mechanism to support IKEv2 key-exchange with key size larger than 135 64KB, building on the works in [I-D.ietf-ipsecme-ikev2-multiple-ke] 136 and [I-D.ietf-ipsecme-ikev2-intermediate]. 138 In addition, some post-quantum digital signature algorithms that are 139 finalists or alternate candidates of NIST post-quantum cryptography 140 standardization (at the time of writing this document) [NIST], also 141 have either public key size or signature size greater than 64 KB. 142 This makes impossible to use them in IKEv2 as drop-in replacement for 143 classic signature algorithms. 145 This document is focused on providing a solution for using large 146 post-quantum algorithms related data (public keys and signatures) in 147 IKEv2. It is not a goal of this document to provide a generic 148 solution to transport large data blocks of arbitrary type in IKEv2. 150 1.1. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119] and 155 [RFC8174]. 157 This document assumes familiarity with IKEv2 concept described in 158 [RFC7296]. 160 2. Proposed Solution Overview 162 While the Length field in IKEv2 header has a size of 32 bits, so that 163 the maximum size of an IKEv2 message can theoretically reach 4 GB, 164 the size of any individual payload inside a message is limited to 64 165 KB due to the fact that the Payload Length field in generic payload 166 header consumes 16 bits only. This makes impossible to transfer 167 blocks of data greater than 64 KB, such as public keys of some post- 168 quantum key exchange methods or some post-quantum signatures. In 169 IKEv2 three types of payloads may contain large amounts of data 170 related to post-quantum algorithms: 172 o Key Exchange (KE) payload in case of large public key of a post- 173 quantum key exchange method 175 o Authentication (AUTH) payload in case of large signature of a 176 post-quantum signature algorithm 178 o Certificate (CERT) payloads in case of large public key of a post- 179 quantum signature algorithm 181 This specification proposes the following solution to the problem: 182 when block of data of a particular type (public key, signature) 183 exceeds 64 KB in size, it is split into a series of chunks smaller 184 than 64 KB. Each chunk then is placed in its own payload, so that 185 the large block of data is eventually transferred in a series of 186 adjacent payloads of the same type. All these payloads MUST have the 187 same values in their headers (except for Next Payload and Payload 188 Length fields) and MUST be transferred adjacent to each other, so 189 that no other payload should appear between them. 191 This approach works well for KE and AUTH payloads, since only one 192 such large block is transferred in a message and there is no 193 ambiguity when it is split over multiple payloads. However, when 194 multiple certificates containing large public keys are transferred 195 and each of them is further splitted into several CERT payloads, 196 there must be a way to find boundaries between these certificates on 197 a receiving side. To solve this problem an empty CERT payload MUST 198 be inserted between other non-empty CERT payloads to mark boundaries 199 between individual certificates. Note that large certificates can 200 also be transferred using "Hash and URL" format (see Section 3.6 of 201 [RFC7296]. 203 The resulting message would exceed 64 KB in size, so that it would 204 not fit into a single UDP datagram. Even if TCP transport 205 [I-D.ietf-ipsecme-rfc8229bis] is used, the size of any individual IKE 206 message in a TCP stream is still limited to 64 KB. For this reason, 207 IKE Fragmentation [RFC7383] MUST be used regardless of the transport 208 protocol if peers are going to transfer large blocks of data. In the 209 case of TCP, the size of fragments is not related to path MTU and can 210 reach 64 KB. 212 Since IKE Fragmentation is mandatory with this extension and it only 213 can be used on encrypted IKE messages, large blocks of data cannot be 214 transferred in the IKE_SA_INIT exchange. 216 In encrypted IKE messages, the Encrypted Payload contains other 217 payloads in encrypted form. Since the Payload Length field in the 218 generic IKE payload header has a size of 16 bits, it is impossible to 219 set a proper value for it in the Encrypted Payload header when it 220 contains inner payloads with total length greater than 64 KB. 221 However, since using IKE Fragmentation is mandatory when transferring 222 large blocks of data (even in case of TCP transport), this 223 restriction has no effect. In the case of IKE Fragmentation, the 224 Payload Length field in the Encrypted payload is never transmitted 225 and is used for local processing only. Instead, the IKE message 226 fragments that appear on the wire are limited to 64 KB, so there is 227 no problem with setting a proper value in the Length field of 228 Encrypted Fragment payloads. However, implementations must be 229 prepared that when constructing messages before their fragmentation 230 and after their re-assembly, the total length of the Encrypted 231 payload content may exceed 64 KB. 233 While mandatory IKE Fragmentation makes it possible to transfer large 234 blocks of data using UDP transport, in practice it may be problematic 235 for the following reason. When fragmenting large messages the number 236 of fragments would be high and all of them are sent at once. If any 237 of these fragment were lost, all the fragments should be re-sent. In 238 congested network environments this would have a negative effect, 239 worsening the congestion. Moreover, the number of IKE message 240 fragments is limited to 2^16. With typical size of IKE message 241 fragment equal to PMTU or less, this would limit the size of a single 242 large block of data to ~30-100 MB. While this is enough for current 243 applications of this specification, it may be a limitation in the 244 future. 246 TCP transport has built-in acknowledgement and congestion control 247 mechanisms and does not suffer from these problems. In addition, 248 since the size of IKE message fragments in case of TCP may be up to 249 64 KB, the size of a single large block of data can in theory reach 4 250 GB. However, [I-D.ietf-ipsecme-rfc8229bis] implies that if TCP is 251 used as transport for IKE, it is also used for ESP. Encapsulation 252 ESP in TCP has a lot of negative effects on performance and on ESP 253 functionality (see Section 10 of [I-D.ietf-ipsecme-rfc8229bis]. 255 This specifications proposes a mixed transport mode as a solution to 256 the problem. In this mode, IKE uses TCP as its transport, while ESP 257 packets are still sent over IP or are encapsulated in UDP. The use 258 of mixed transport mode is optional and is negotiated in the 259 IKE_SA_INIT exchange. 261 3. Protocol Details 263 The initiator starts creating an IKEv2 SA by sending the IKE_SA_INIT 264 request message. If the initiator is going to transfer large blocks 265 of data (e.g. large public keys), then it should make some 266 preparations: 268 o IKEV2_FRAGMENTATION_SUPPORTED notification MUST be included to 269 negotiate support for IKE Fragmentation 271 o INTERMEDIATE_EXCHANGE_SUPPORTED notification MUST be included if 272 the initiator proposes key exchange methods with public keys 273 greater than 64 KB 275 o If the initiator is going to use mixed transport mode then it 276 starts the IKE_SA_INIT request using UDP port 4500 and includes a 277 new status type notification IKE_OVER_TCP (), which 278 has protocol 0, SPI size 0 and contains no data; if the initiator 279 starts the IKE_SA_INIT over TCP, then the mixed transport mode 280 cannot be used and this notification SHOULD NOT be included, it 281 MUST be ignored by the responder if it is still included in the 282 message 284 Note that UDP port 4500 (and not port 500) is used for the 285 IKE_SA_INIT messages, which is allowed by [RFC7296]. Using port 4500 286 allows return routability check for UDP messages to be carried out 287 and ensures ESP packets can get through if they are UDP encapsulated. 289 The responder supporting this specification MUST agree on using IKE 290 Fragmentation by sending back IKEV2_FRAGMENTATION_SUPPORTED 291 notification. If it selects proposal with key exchange method having 292 public key greater than 64 KB, then it MUST agree on using the 293 IKE_INTERMEDIATE exchange by sending back 294 INTERMEDIATE_EXCHANGE_SUPPORTED notification. 296 If the initiator proposed using mixed transport mode by initiating 297 the IKE_SA_INIT exchange over UDP port 4500 and including 298 IKE_OVER_TCP notification and the responder supports this mode and is 299 willing to use it, then it sends this notification back in the 300 IKE_SA_INIT response. In this case the initiator MUST switch to TCP 301 using destination port 4500 in the next exchange (IKE_INTERMEDIATE or 302 IKE_AUTH) and the responder MUST be prepared to receive the next 303 exchange request message on TCP port 4500. Once switched all 304 subsequent IKE exchanges MUST use TCP transport as described in 305 [I-D.ietf-ipsecme-rfc8229bis], but ESP packets MUST NOT be sent using 306 TCP, instead they are sent either over IP or using UDP encapsulation, 307 depending on the presence of NAT, which is determined in the 308 IKE_SA_INIT exchange. 310 If the responder does not support mixed transport mode, then it 311 ignores the IKE_OVER_TCP notification and all subsequent IKE 312 exchanges will use UDP transport. Note, that in case the initiator 313 started the IKE_SA_INIT over TCP then the IKE_OVER_TCP notification 314 would not be included in the request message and there would be no 315 option for mixed transport mode. 317 Initiator Responder 318 ------------------------------------------------------------------- 319 HDR, SAi1, KEi1, Ni, 320 N(NAT_DETECTION_SOURCE_IP), 321 N(NAT_DETECTION_DESTINATION_IP), 322 N(IKEV2_FRAGMENTATION_SUPPORTED), 323 [N(INTERMEDIATE_EXCHANGE_SUPPORTED),] 324 [N(IKE_OVER_TCP)] ---> 325 HDR, SAr1, KEr1, Nr, 326 N(NAT_DETECTION_SOURCE_IP), 327 N(NAT_DETECTION_DESTINATION_IP), 328 N(IKEV2_FRAGMENTATION_SUPPORTED), 329 [N(INTERMEDIATE_EXCHANGE_SUPPORTED),] 330 <--- [N(IKE_OVER_TCP)] 332 Once the IKE_SA_INIT exchange is completed, the peers continue with 333 the following exchanges: one or more IKE_INTERMEDITE exchanges in 334 case multiple key exchanges are negotiated or the IKE_AUTH exchange, 335 as shown below. Note that all messages containing large blocks of 336 data are sent fragmented using IKE Fragmentation mechanism, but they 337 are not shown here for the sake of simplicity. 339 Initiator Responder 340 ------------------------------------------------------------------- 341 HDR, SK{KEi2.1, KEi2.2, KEi2.3, ...} ---> 342 <--- HDR, SK{KEr2.1, KEr2.2, ...} 344 HDR, SK{KEi3.1, KEi3.2, ...} ---> 345 <--- HDR, SK{KEr3.1, KEr3.2, ...} 347 ... 349 HDR, SK{IDi, [IDr,] [CERTi1, CERTi2, ...] 350 [CERTREQ,] [IDr,] AUTHi1, AUTHi2, ... 351 SAi2, TSi, TSr} ---> 352 <--- HDR, SK{IDr, [CERTr1, CERTr2, ...] 353 AUTHr1, AUTHr2, ... 354 SAr2, TSi, TSr} 356 4. Operational Considerations 358 The IKE fragmentation 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 373 [I-D.ietf-ipsecme-rfc8229bis]. If TCP is used as IKE transport, then 374 using mixed transport mode is RECOMMENDED to allow better ESP 375 performance. 377 5. Denial of Service Considerations 379 Malicious peers may send a large number of fragments, but incomplete, 380 to the legitimate peer causing memory exhaustion. It is RECOMMENDED 381 that the strategies and recommendations described in [RFC8019] be 382 implemented to counter possible DoS attacks. 384 An alternative arrangement, if peers do not support [RFC8019], is to 385 allow the transfer of large block of data only after peers are 386 authenticated. In other words, key-establishment using large public- 387 key should not be done to establish an IKE SA, but it should only be 388 used to establish a Child SA or rekeying an IKE SA. In order to 389 protect IKE messages from quantum threats, multiple key-exchanges 390 using a combination of classical and post-quantum ciphers, as 391 described in [I-D.ietf-ipsecme-ikev2-multiple-ke] can be used. 392 Nonetheless, this approach has a limitation whereby if a digital 393 signature scheme with large public-key or signature payload is used, 394 it is still susceptible to DoS attacks. 396 *** More to be populated in the next version *** 398 6. Security Considerations 400 If TCP encapsulation is used, refer to the security considerations in 401 [I-D.ietf-ipsecme-rfc8229bis]. 403 Downloading or transferring large amounts of data is an expensive 404 operation, bandwidth and memory wise. Consequently, implementations 405 should consider using a longer rekeying interval or SHOULD consider 406 relaxing forward secrecy requirements but using CCA-secure key- 407 establishment algorithms only. With chosen-ciphertext attack (CCA)- 408 secure schemes, there is no loss in security if the public-key is 409 reused. 411 7. IANA Considerations 413 This document defines a new Notify Message Type in the "Notify 414 Message Types - Status Types" registry: 416 IKE_OVER_TCP 418 8. References 420 8.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-06 (work 425 in progress), March 2021. 427 [I-D.ietf-ipsecme-ikev2-multiple-ke] 428 Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S., 429 Geest, D. V., Garcia-Morchon, O., and V. Smyslov, 430 "Multiple Key Exchanges in IKEv2", draft-ietf-ipsecme- 431 ikev2-multiple-ke-02 (work in progress), January 2021. 433 [I-D.ietf-ipsecme-rfc8229bis] 434 Smyslov, V. and T. Pauly, "TCP Encapsulation of IKE and 435 IPsec Packets", draft-ietf-ipsecme-rfc8229bis-00 (work in 436 progress), April 2021. 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, 440 DOI 10.17487/RFC2119, March 1997, 441 . 443 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 444 Kivinen, "Internet Key Exchange Protocol Version 2 445 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 446 2014, . 448 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 449 (IKEv2) Message Fragmentation", RFC 7383, 450 DOI 10.17487/RFC7383, November 2014, 451 . 453 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 454 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 455 May 2017, . 457 8.2. Informative References 459 [BSI] Federal Office for Information Security, "Cryptographic 460 Mechanisms: Recommendations and Key Lengths", 2020, . 464 [CM] Classic McEliece submission team, "Classic McEliece: NIST 465 post-quantum cryptography standardization finalist", 2020, 466 . 468 [FIPS-202] 469 National Institute of Standards and Technology, "SHA-3 470 Standard: Permutation-Based Hash and Extendable-Output 471 Functions", 2015, . 473 [McEliece] 474 McEliece, R., "A Public-key Cryptosystem based on 475 Algebraic Coding Theory", DSN Progress Report 42-44, 476 1978. 478 [NIST] National Institute of Standards and Technology, "Post- 479 Quantum Cryptography Standardization", 480 . 483 [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange 484 Protocol Version 2 (IKEv2) Implementations from 485 Distributed Denial-of-Service Attacks", RFC 8019, 486 DOI 10.17487/RFC8019, November 2016, 487 . 489 Appendix A. Alternative Approaches 491 A.1. Hash and URL 493 [RFC7296] defines a mechanism whereby an authentication payload such 494 as a certificate can be encoded using a hash value and a URL. A peer 495 utilizes HTTP_CERT_LOOKUP_SUPPORTED Notify payload to indicate that 496 X.509 certificates are not transported in-band, instead the other 497 peer shall fetch the certificates from the given URL and verify its 498 integrity from the hash value. In this way, the peer needs to send 499 20 octets plus a variable length URL only over the wire, instead of a 500 few kilobytes of payload, which is useful in the event IKEv2 message 501 fragmentation is not available. 503 Large public keys can be transported by reusing the same technique 504 and this can be done in two ways, as described below. 506 A.1.1. Key Exchange Payload 508 The Key Exchange Data field of IKEv2 Key Exchange Payload contains a 509 single format, which is a blob that is only meaningful to the 510 specified key exchange method. In order to support hash and URL 511 data, an encoding format needs to be specified on the header. 513 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Next Payload |C|F| RESERVED | Payload Length | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Key Exchange Method | RESERVED | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | | 521 ~ Key Exchange Data ~ 522 | | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 The reserved bit-field F above specifies the encoding format. If it 526 is 0, the Key Exchange Data is a blob as specified in RFC7296. On 527 the other hand if it is 1, the Key Exchange Data is in the form of 528 hash and URL format, whereby the hash value is the SHA3-256 digest 529 [FIPS-202] of the replaced value truncated to 20 octets and the URL 530 value is a variable length URL (in either http or https schema) that 531 resolves to the DER-encoded of the replaced value itself. 533 Because the hash and URL value is transported in a Key Exchange 534 Payload, it is possible to support the use-case of a single post- 535 quantum key-establishment with large public-key. This payload will 536 be sent as part of IKE_SA_INIT exchange and it will not require 537 IKE_INTERMEDIATE exchanges. 539 While using hash and URL method to transport large key-establishment 540 data requires minimal modification to IKEv2 protocol, there are 541 disadvantages from deployment point of view that may make this method 542 impractical. Firstly, an IKE peer that originates a hash and URL 543 value will also need to implement additional infrastructure so that 544 it can serve HTTP requests in order to allow the actual key- 545 establishment data to be fetched. While this may not be an issue for 546 Internet facing peers, in the context of road-warrior or remote- 547 access cases, the hash and URL value is initiated by an IKE peer that 548 is usually a device sitting behind a network address translation 549 (NAT) device and as such, it may not be able to run a publicly 550 reachable HTTP server infrastructure on the same device. An possible 551 solution for these cases is to publish the key-establishment data to 552 a separate server, which is not practical as one cannot expect an IKE 553 initiator to always have deployed an HTTP server. Lastly, IKE peers 554 are predominantly deployed at the network edge where strict firewall 555 rules are generally enforced. The need to open up another port to 556 serve HTTP requests may cause either technical or policy complication 557 that render this approach unacceptable. 559 The hash and URL approach is vulnerable to (distributed) denial of 560 service attacks as an unauthenticated rogue peer may trick a 561 legitimate peer to fetch a large amount of random meaningless data 562 from a remote server. Implementations SHOULD NOT blindly download 563 all of the data in the given URL. Because a legitimate key- 564 establishment payload should be DER-encoded, they SHOULD download the 565 first few octets to determine the length of the ASN.1 structure 566 representing these octets, then only continue to download the 567 remaining decoded number of octets if the length is expected for the 568 chosen key-establishment algorithm. It should be noted that the 569 content of the data to be downloaded may be under attacker's control 570 and therefore even if the length is as expected, the content may be 571 meaningless bit that is of no use for key-establishment. 573 A.1.2. Certificate Payload 575 An alternative is to re-purpose Certificate Payload to carry the hash 576 and URL value of the post-quantum key-establishment data. At the 577 time of writing, the IANA registry defines two hash and URL encoding 578 values, namely X.509 certificate and X.509 certificate bundle. In 579 order to use this payload, a new encoding value for key establishment 580 data will be required. 582 Because a Certificate Payload is part of IKE_AUTH message, unlike the 583 previous approach, the hash and URL value of the key-establishment 584 data shall be transported via IKE_INTERMEDIATE message. As such, it 585 will not be able to support a single post-quantum key-establishment 586 with a large public-key case. Furthermore, it is semantically 587 incorrect to re-purpose Certificate Payload, which is intended to 588 carry authentication data, to transport key-establishment data. 590 A.2. Incremental Transfer and Confirmation 592 As stated in Section 4 of [RFC7383], if any single fragment is lost, 593 the receiving peer will not be able to reassemble the original large 594 key-establishment payload. The above bulk transfer is susceptible to 595 this issue. There is another way to transfer these payload chunks 596 that is less susceptible to this, but at the cost of higher latency. 597 Instead of transferring in a bulk, each Key Exchange payload chunk 598 must be acknowledged prior to sending the subsequent chunk. As 599 before, the large key-establishment payload is split over several Key 600 Exchange payload chunks where each of them share the same Key 601 Exchange Method value. Each chunk is then sent to the peer using the 602 IKE_INTERMEDIATE message, and each one must be acknowledged by the 603 receiving peer before the subsequent chunk can be sent. 605 Initiator Responder 606 ------------------------------------------------------------------- 607 HDR, SAi1, KEi1, Ni, 608 N(IKEV2_FRAGMENTATION_SUPPORTED)*, 609 N(INTERMEDIATE_EXCHANGE_SUPPORTED) ---> 611 HDR, SAr1, KEr1, Nr, 612 N(IKEV2_FRAGMENTATION_SUPPORTED)*, 613 <--- N(INTERMEDIATE_EXCHANGE_SUPPORTED) 615 HDR, SK{KEi2.1, ...} ---> 617 <--- HDR, SK{} 619 HDR, SK{KEi2.2, ...} ---> 621 <--- HDR, SK{} 623 HDR, SK{KEi2.3, ...} ---> 625 <--- HDR, SK{KEr2, ...} 627 HDR, SK{} ---> 629 *: optional 631 In order to support key-encapsulation mechanism, the receiving peer 632 has to wait until the entire chunks are received before it can 633 respond with its own Key Exchange payload, which may not be large. 635 Authors' Addresses 637 CJ Tjhai 638 Post-Quantum 639 UK 641 Email: cjt@post-quantum.com 643 Tobias Heider 644 genua GmbH 645 DE 647 Email: me@tobhe.de 648 Valery Smyslov 649 ELVIS-PLUS 650 PO Box 81 651 Moscow (Zelenograd) 124460 652 RU 654 Phone: +7 495 276 0211 655 Email: svan@elvis.ru