idnits 2.17.00 (12 Aug 2021) /tmp/idnits28615/draft-tjhai-ikev2-beyond-64k-limit-02.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 document date (January 28, 2022) is 106 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-07 == Outdated reference: A later version (-05) exists of draft-ietf-ipsecme-ikev2-multiple-ke-04 == Outdated reference: A later version (-05) exists of draft-ietf-ipsecme-rfc8229bis-01 Summary: 0 errors (**), 0 flaws (~~), 3 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: August 1, 2022 genua GmbH 6 V. Smyslov 7 ELVIS-PLUS 8 January 28, 2022 10 Beyond 64KB Limit of IKEv2 Payloads 11 draft-tjhai-ikev2-beyond-64k-limit-02 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 August 1, 2022. 38 Copyright Notice 40 Copyright (c) 2022 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 . . . . . . . . . . . . . . 9 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 65 8.2. Informative References . . . . . . . . . . . . . . . . . 11 66 Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 11 67 A.1. Hash and URL . . . . . . . . . . . . . . . . . . . . . . 11 68 A.1.1. Key Exchange Payload . . . . . . . . . . . . . . . . 12 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 While mandatory IKE Fragmentation makes it possible to transfer large 217 blocks of data using UDP transport, in practice it may be problematic 218 for the following reason. When fragmenting large messages the number 219 of fragments would be high and all of them are sent at once. If any 220 of these fragment were lost, all the fragments should be re-sent. In 221 congested network environments this would have a negative effect, 222 worsening the congestion. Moreover, the number of IKE message 223 fragments is limited to 2^16. With typical size of IKE message 224 fragment equal to PMTU or less, this would limit the size of a single 225 large block of data to ~30-100 MB. While this is enough for current 226 applications of this specification, it may be a limitation in the 227 future. 229 TCP transport has built-in acknowledgement and congestion control 230 mechanisms and does not suffer from these problems. In addition, 231 since the size of IKE message fragments in case of TCP may be up to 232 64 KB, the size of a single large block of data can in theory reach 4 233 GB. However, [I-D.ietf-ipsecme-rfc8229bis] implies that if TCP is 234 used as transport for IKE, it is also used for ESP. Encapsulation 235 ESP in TCP has a lot of negative effects on performance and on ESP 236 functionality (see Section 10 of [I-D.ietf-ipsecme-rfc8229bis]. 238 This specifications proposes a mixed transport mode as a solution to 239 the problem. In this mode, IKE uses TCP as its transport, while ESP 240 packets are still sent over IP or are encapsulated in UDP. The use 241 of mixed transport mode is optional and is negotiated in the 242 IKE_SA_INIT exchange. 244 3. Protocol Details 246 The initiator starts creating an IKEv2 SA by sending the IKE_SA_INIT 247 request message. If the initiator is going to transfer large blocks 248 of data (e.g. large public keys), then it should make some 249 preparations: 251 o IKEV2_FRAGMENTATION_SUPPORTED notification MUST be included to 252 negotiate support for IKE Fragmentation 254 o INTERMEDIATE_EXCHANGE_SUPPORTED notification MUST be included if 255 the initiator proposes key exchange methods with public keys 256 greater than 64 KB 258 o If the initiator is going to use mixed transport mode then it 259 starts the IKE_SA_INIT request using UDP port 4500 and includes a 260 new status type notification IKE_OVER_TCP (), which 261 has protocol 0, SPI size 0 and contains no data; if the initiator 262 starts the IKE_SA_INIT over TCP, then the mixed transport mode 263 cannot be used and this notification SHOULD NOT be included, it 264 MUST be ignored by the responder if it is still included in the 265 message 267 Note that UDP port 4500 (and not port 500) is used for the 268 IKE_SA_INIT messages, which is allowed by [RFC7296]. Using port 4500 269 allows return routability check for UDP messages to be carried out 270 and ensures ESP packets can get through if they are UDP encapsulated. 272 The responder supporting this specification MUST agree on using IKE 273 Fragmentation by sending back IKEV2_FRAGMENTATION_SUPPORTED 274 notification. If it selects proposal with key exchange method having 275 public key greater than 64 KB, then it MUST agree on using the 276 IKE_INTERMEDIATE exchange by sending back 277 INTERMEDIATE_EXCHANGE_SUPPORTED notification. 279 If the initiator proposed using mixed transport mode by initiating 280 the IKE_SA_INIT exchange over UDP port 4500 and including 281 IKE_OVER_TCP notification and the responder supports this mode and is 282 willing to use it, then it sends this notification back in the 283 IKE_SA_INIT response. In this case the initiator MUST switch to TCP 284 using destination port 4500 in the next exchange (IKE_INTERMEDIATE or 285 IKE_AUTH) and the responder MUST be prepared to receive the next 286 exchange request message on TCP port 4500. Once switched all 287 subsequent IKE exchanges MUST use TCP transport as described in 288 [I-D.ietf-ipsecme-rfc8229bis], but ESP packets MUST NOT be sent using 289 TCP, instead they are sent either over IP or using UDP encapsulation, 290 depending on the presence of NAT, which is determined in the 291 IKE_SA_INIT exchange. Note, that if NAT is detected and UDP 292 encapsulation of ESP is used, then NAT keepalive messages MUST be 293 sent by the peer that is behind NAT over UDP using ports from the 294 IKE_SA_INIT exchange, as defined in [RFC3948]. 296 If the responder does not support mixed transport mode, then it 297 ignores the IKE_OVER_TCP notification and all subsequent IKE 298 exchanges will use UDP transport. Note, that in case the initiator 299 started the IKE_SA_INIT over TCP then the IKE_OVER_TCP notification 300 would not be included in the request message and there would be no 301 option for mixed transport mode. 303 Initiator Responder 304 ------------------------------------------------------------------- 305 HDR, SAi1, KEi1, Ni, 306 N(NAT_DETECTION_SOURCE_IP), 307 N(NAT_DETECTION_DESTINATION_IP), 308 N(IKEV2_FRAGMENTATION_SUPPORTED), 309 [N(INTERMEDIATE_EXCHANGE_SUPPORTED),] 310 [N(IKE_OVER_TCP)] ---> 311 HDR, SAr1, KEr1, Nr, 312 N(NAT_DETECTION_SOURCE_IP), 313 N(NAT_DETECTION_DESTINATION_IP), 314 N(IKEV2_FRAGMENTATION_SUPPORTED), 315 [N(INTERMEDIATE_EXCHANGE_SUPPORTED),] 316 <--- [N(IKE_OVER_TCP)] 318 Once the IKE_SA_INIT exchange is completed, the peers continue with 319 the following exchanges: one or more IKE_INTERMEDITE exchanges in 320 case multiple key exchanges are negotiated or the IKE_AUTH exchange, 321 as shown below. Note that all messages containing large blocks of 322 data are sent fragmented using IKE Fragmentation mechanism, but they 323 are not shown here for the sake of simplicity. 325 Initiator Responder 326 ------------------------------------------------------------------- 327 HDR, SK{KEi2.1, KEi2.2, KEi2.3, ...} ---> 328 <--- HDR, SK{KEr2.1, KEr2.2, ...} 330 HDR, SK{KEi3.1, KEi3.2, ...} ---> 331 <--- HDR, SK{KEr3.1, KEr3.2, ...} 333 ... 335 HDR, SK{IDi, [IDr,] [CERTi1, CERTi2, ...] 336 [CERTREQ,] [IDr,] AUTHi1, AUTHi2, ... 337 SAi2, TSi, TSr} ---> 338 <--- HDR, SK{IDr, [CERTr1, CERTr2, ...] 339 AUTHr1, AUTHr2, ... 340 SAr2, TSi, TSr} 342 Since the Payload Length field in the generic IKE payload header has 343 a size of 16 bits, it is impossible to set a proper value for it in 344 the Encrypted Payload header when it contains inner payloads with 345 total length greater than 64 KB. However, using IKE Fragmentation is 346 mandatory when transferring large blocks of data (even in case of TCP 347 transport) and with IKE Fragmentation, the Payload Length field in 348 the Encrypted payload is never transmitted. Instead, the IKE message 349 fragments that appear on the wire are limited to 64 KB in size, so 350 there is no problem with setting a proper value in the Length field 351 of Encrypted Fragment payloads. However, when IKE_INTERMEDIATE 352 exchanges are being authenticated, the content of the Encrypted 353 Payload before encryption and fragmentation is fed to the prf. In 354 this case if the size of the Encrypted payload content exceeds 64 KB 355 then the Payload Length field in the Encrypted Payload header MUST be 356 set to zero when fedding into the prf. On receipt it MUST be checked 357 that the total size of unencrypted payloads the Encrypted Payload 358 contains matches the size of the Encrypted payload calculated from 359 the size of the received message. 361 4. Operational Considerations 363 The IKE fragmentation does not require additional infrastructure, 364 however, there is non-zero probability of lost packets when sending a 365 large number of fragments over a UDP connection. Given a set of 366 fragments, when transmitted, each one of them is not individually 367 acknowledged and if any one of them is lost, the entire set will have 368 to be retransmitted. As a consequence, given the size of the payload 369 and also the potential of multiple retransmissions, there may be a 370 noticeable delay in establishing an security association (SA), in 371 particular in lossy network conditions. Therefore, implementations 372 MAY use a longer timeout value for the purpose of dead-peer 373 detection, but a balance needs to be struck as too large of a value 374 will open up security vulnerabilities as discussed in the following 375 section. In the unlikely event where there is a frequent 376 retransmission due to loss of fragments, implementations MAY send the 377 IKE messages over a TCP connection as specified in 378 [I-D.ietf-ipsecme-rfc8229bis]. If TCP is used as IKE transport, then 379 using mixed transport mode is RECOMMENDED to allow better ESP 380 performance. 382 5. Denial of Service Considerations 384 Malicious peers may send a large number of fragments, but incomplete, 385 to the legitimate peer causing memory exhaustion. It is RECOMMENDED 386 that the strategies and recommendations described in [RFC8019] be 387 implemented to counter possible DoS attacks. 389 An alternative arrangement, if peers do not support [RFC8019], is to 390 allow the transfer of large block of data only after peers are 391 authenticated. In other words, key-establishment using large public- 392 key should not be done to establish an IKE SA, but it should only be 393 used to establish a Child SA or rekeying an IKE SA. In order to 394 protect IKE messages from quantum threats, multiple key-exchanges 395 using a combination of classical and post-quantum ciphers, as 396 described in [I-D.ietf-ipsecme-ikev2-multiple-ke] can be used. 397 Nonetheless, this approach has a limitation whereby if a digital 398 signature scheme with large public-key or signature payload is used, 399 it is still susceptible to DoS attacks. 401 *** More to be populated in the next version *** 403 6. Security Considerations 405 If TCP encapsulation is used, refer to the security considerations in 406 [I-D.ietf-ipsecme-rfc8229bis]. 408 Downloading or transferring large amounts of data is an expensive 409 operation, bandwidth and memory wise. Consequently, implementations 410 should consider using a longer rekeying interval or SHOULD consider 411 relaxing forward secrecy requirements but using CCA-secure key- 412 establishment algorithms only. With chosen-ciphertext attack (CCA)- 413 secure schemes, there is no loss in security if the public-key is 414 reused. 416 7. IANA Considerations 418 This document defines a new Notify Message Type in the "Notify 419 Message Types - Status Types" registry: 421 IKE_OVER_TCP 423 8. References 425 8.1. Normative References 427 [I-D.ietf-ipsecme-ikev2-intermediate] 428 Smyslov, V., "Intermediate Exchange in the IKEv2 429 Protocol", draft-ietf-ipsecme-ikev2-intermediate-07 (work 430 in progress), August 2021. 432 [I-D.ietf-ipsecme-ikev2-multiple-ke] 433 Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S., 434 Geest, D. V., Garcia-Morchon, O., and V. Smyslov, 435 "Multiple Key Exchanges in IKEv2", draft-ietf-ipsecme- 436 ikev2-multiple-ke-04 (work in progress), September 2021. 438 [I-D.ietf-ipsecme-rfc8229bis] 439 Smyslov, V. and T. Pauly, "TCP Encapsulation of IKE and 440 IPsec Packets", draft-ietf-ipsecme-rfc8229bis-01 (work in 441 progress), October 2021. 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, 445 DOI 10.17487/RFC2119, March 1997, 446 . 448 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 449 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 450 RFC 3948, DOI 10.17487/RFC3948, January 2005, 451 . 453 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 454 Kivinen, "Internet Key Exchange Protocol Version 2 455 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 456 2014, . 458 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 459 (IKEv2) Message Fragmentation", RFC 7383, 460 DOI 10.17487/RFC7383, November 2014, 461 . 463 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 464 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 465 May 2017, . 467 8.2. Informative References 469 [BSI] Federal Office for Information Security, "Cryptographic 470 Mechanisms: Recommendations and Key Lengths", 2020, . 474 [CM] Classic McEliece submission team, "Classic McEliece: NIST 475 post-quantum cryptography standardization finalist", 2020, 476 . 478 [FIPS-202] 479 National Institute of Standards and Technology, "SHA-3 480 Standard: Permutation-Based Hash and Extendable-Output 481 Functions", 2015, . 483 [McEliece] 484 McEliece, R., "A Public-key Cryptosystem based on 485 Algebraic Coding Theory", DSN Progress Report 42-44, 486 1978. 488 [NIST] National Institute of Standards and Technology, "Post- 489 Quantum Cryptography Standardization", 490 . 493 [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange 494 Protocol Version 2 (IKEv2) Implementations from 495 Distributed Denial-of-Service Attacks", RFC 8019, 496 DOI 10.17487/RFC8019, November 2016, 497 . 499 Appendix A. Alternative Approaches 501 A.1. Hash and URL 503 [RFC7296] defines a mechanism whereby an authentication payload such 504 as a certificate can be encoded using a hash value and a URL. A peer 505 utilizes HTTP_CERT_LOOKUP_SUPPORTED Notify payload to indicate that 506 X.509 certificates are not transported in-band, instead the other 507 peer shall fetch the certificates from the given URL and verify its 508 integrity from the hash value. In this way, the peer needs to send 509 20 octets plus a variable length URL only over the wire, instead of a 510 few kilobytes of payload, which is useful in the event IKEv2 message 511 fragmentation is not available. 513 Large public keys can be transported by reusing the same technique 514 and this can be done in two ways, as described below. 516 A.1.1. Key Exchange Payload 518 The Key Exchange Data field of IKEv2 Key Exchange Payload contains a 519 single format, which is a blob that is only meaningful to the 520 specified key exchange method. In order to support hash and URL 521 data, an encoding format needs to be specified on the header. 523 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Next Payload |C|F| RESERVED | Payload Length | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Key Exchange Method | RESERVED | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | | 531 ~ Key Exchange Data ~ 532 | | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 The reserved bit-field F above specifies the encoding format. If it 536 is 0, the Key Exchange Data is a blob as specified in RFC7296. On 537 the other hand if it is 1, the Key Exchange Data is in the form of 538 hash and URL format, whereby the hash value is the SHA3-256 digest 539 [FIPS-202] of the replaced value truncated to 20 octets and the URL 540 value is a variable length URL (in either http or https schema) that 541 resolves to the DER-encoded of the replaced value itself. 543 Because the hash and URL value is transported in a Key Exchange 544 Payload, it is possible to support the use-case of a single post- 545 quantum key-establishment with large public-key. This payload will 546 be sent as part of IKE_SA_INIT exchange and it will not require 547 IKE_INTERMEDIATE exchanges. 549 While using hash and URL method to transport large key-establishment 550 data requires minimal modification to IKEv2 protocol, there are 551 disadvantages from deployment point of view that may make this method 552 impractical. Firstly, an IKE peer that originates a hash and URL 553 value will also need to implement additional infrastructure so that 554 it can serve HTTP requests in order to allow the actual key- 555 establishment data to be fetched. While this may not be an issue for 556 Internet facing peers, in the context of road-warrior or remote- 557 access cases, the hash and URL value is initiated by an IKE peer that 558 is usually a device sitting behind a network address translation 559 (NAT) device and as such, it may not be able to run a publicly 560 reachable HTTP server infrastructure on the same device. An possible 561 solution for these cases is to publish the key-establishment data to 562 a separate server, which is not practical as one cannot expect an IKE 563 initiator to always have deployed an HTTP server. Lastly, IKE peers 564 are predominantly deployed at the network edge where strict firewall 565 rules are generally enforced. The need to open up another port to 566 serve HTTP requests may cause either technical or policy complication 567 that render this approach unacceptable. 569 The hash and URL approach is vulnerable to (distributed) denial of 570 service attacks as an unauthenticated rogue peer may trick a 571 legitimate peer to fetch a large amount of random meaningless data 572 from a remote server. Implementations SHOULD NOT blindly download 573 all of the data in the given URL. Because a legitimate key- 574 establishment payload should be DER-encoded, they SHOULD download the 575 first few octets to determine the length of the ASN.1 structure 576 representing these octets, then only continue to download the 577 remaining decoded number of octets if the length is expected for the 578 chosen key-establishment algorithm. It should be noted that the 579 content of the data to be downloaded may be under attacker's control 580 and therefore even if the length is as expected, the content may be 581 meaningless bit that is of no use for key-establishment. 583 A.1.2. Certificate Payload 585 An alternative is to re-purpose Certificate Payload to carry the hash 586 and URL value of the post-quantum key-establishment data. At the 587 time of writing, the IANA registry defines two hash and URL encoding 588 values, namely X.509 certificate and X.509 certificate bundle. In 589 order to use this payload, a new encoding value for key establishment 590 data will be required. 592 Because a Certificate Payload is part of IKE_AUTH message, unlike the 593 previous approach, the hash and URL value of the key-establishment 594 data shall be transported via IKE_INTERMEDIATE message. As such, it 595 will not be able to support a single post-quantum key-establishment 596 with a large public-key case. Furthermore, it is semantically 597 incorrect to re-purpose Certificate Payload, which is intended to 598 carry authentication data, to transport key-establishment data. 600 A.2. Incremental Transfer and Confirmation 602 As stated in Section 4 of [RFC7383], if any single fragment is lost, 603 the receiving peer will not be able to reassemble the original large 604 key-establishment payload. The above bulk transfer is susceptible to 605 this issue. There is another way to transfer these payload chunks 606 that is less susceptible to this, but at the cost of higher latency. 607 Instead of transferring in a bulk, each Key Exchange payload chunk 608 must be acknowledged prior to sending the subsequent chunk. As 609 before, the large key-establishment payload is split over several Key 610 Exchange payload chunks where each of them share the same Key 611 Exchange Method value. Each chunk is then sent to the peer using the 612 IKE_INTERMEDIATE message, and each one must be acknowledged by the 613 receiving peer before the subsequent chunk can be sent. 615 Initiator Responder 616 ------------------------------------------------------------------- 617 HDR, SAi1, KEi1, Ni, 618 N(IKEV2_FRAGMENTATION_SUPPORTED)*, 619 N(INTERMEDIATE_EXCHANGE_SUPPORTED) ---> 621 HDR, SAr1, KEr1, Nr, 622 N(IKEV2_FRAGMENTATION_SUPPORTED)*, 623 <--- N(INTERMEDIATE_EXCHANGE_SUPPORTED) 625 HDR, SK{KEi2.1, ...} ---> 627 <--- HDR, SK{} 629 HDR, SK{KEi2.2, ...} ---> 631 <--- HDR, SK{} 633 HDR, SK{KEi2.3, ...} ---> 635 <--- HDR, SK{KEr2, ...} 637 HDR, SK{} ---> 639 *: optional 641 In order to support key-encapsulation mechanism, the receiving peer 642 has to wait until the entire chunks are received before it can 643 respond with its own Key Exchange payload, which may not be large. 645 Authors' Addresses 647 CJ Tjhai 648 Post-Quantum 649 UK 651 Email: cjt@post-quantum.com 652 Tobias Heider 653 genua GmbH 654 DE 656 Email: me@tobhe.de 658 Valery Smyslov 659 ELVIS-PLUS 660 PO Box 81 661 Moscow (Zelenograd) 124460 662 RU 664 Phone: +7 495 276 0211 665 Email: svan@elvis.ru