idnits 2.17.00 (12 Aug 2021) /tmp/idnits23463/draft-tjhai-ipsecme-hybrid-qske-ikev2-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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 18, 2017) is 1768 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 244, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Tjhai 3 Internet-Draft M. Tomlinson 4 Intended Status: Informational A. Cheng 5 Expires: January 19, 2018 Post-Quantum 6 G. Bartlett 7 Cisco Systems 8 July 18, 2017 10 Hybrid Quantum-Safe Key Exchange for Internet 11 Key Exchange Protocol Version 2 (IKEv2) 12 draft-tjhai-ipsecme-hybrid-qske-ikev2-00 14 Abstract 16 This document describes the optional key-exchange payload of Internet 17 Key Exchange Protocol Version 2 (IKEv2) that carries quantum-safe key 18 exchange data. This optional payload is used in conjunction with the 19 existing Diffie-Hellman key exchange to establish a quantum-safe 20 shared secret between an initiator and a responder. The optional 21 payload supports a number of quantum-safe key exchange schemes. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 21, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 2 59 1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . . 3 60 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Hybrid Quantum-Safe Key Exchange . . . . . . . . . . . . . . . 4 62 2.1. Quantum-Safe Group Transform Type . . . . . . . . . . . . 4 63 2.2. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . . 5 64 2.3. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . . . . 6 65 2.3.1. New Child SAs from the CREATE_CHILD_SA Exchange . . . 7 66 2.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . . 8 67 2.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange . 8 68 2.4. QSKE Payload Format . . . . . . . . . . . . . . . . . . . 9 69 3. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 10 70 3.1. Threat Categories . . . . . . . . . . . . . . . . . . . . 10 71 3.2. Dealing with Fragmentation . . . . . . . . . . . . . . . . 11 72 3.3. Removal of the Diffie-Hellman exchange . . . . . . . . . . 12 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 Appendix A. Quantum-safe Ciphers . . . . . . . . . . . . . . . . 16 77 Appendix A.1. Ring Learning With Errors . . . . . . . . . . . . . 16 78 Appendix A.2. NTRU Lattices . . . . . . . . . . . . . . . . . . . 21 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 81 1. Introduction 83 1.1. Problem Description 85 Internet Key Exchange Protocol (IKEv2) as specified in RFC 7296 86 [RFC7296] uses the Diffie-Hellman algorithm [DH] to establish a 87 shared secret between an initiator and a responder. The security of 88 the Diffie-Hellman algorithm relies on the difficulty to solve a 89 discrete logarithm problem when the order of the group parameter is 90 large enough. While solving such a problem remains difficult with 91 current computing power, it is believed that general purpose quantum 92 computers can easily crack this problem, implying that the security 93 of IKEv2 is compromised. There are, however, a number of 94 cryptosystems that are conjectured to be resistant against quantum 95 computer attack. 97 1.2. Proposed Extension 99 This document describes a method to extend IKEv2, whilst maintaining 100 backwards compatibility, to perform key exchange that is robust 101 against quantum computers. The idea is to use an optional key 102 exchange payload using a quantum-safe key exchange algorithm, in 103 addition to the existing Diffie-Hellman key exchange. The secrets 104 established from each key exchange are combined in a way such that 105 should the quantum-safe secret not be present, the derived shared 106 secret is equivalent to that of the standard IKEv2; on the other 107 hand, a quantum-safe shared secret is obtained if both key exchange 108 payloads are present. This extension also applies to key exchanges 109 in IKE Security Associations (SAs) for Encapsulating Security Payload 110 (ESP) [ESP] or Authentication Header (AH) [AH], i.e. Child SAs, in 111 order to provide a stronger guarantee of forward security. 113 The goals of this extension are: 115 o to allow an additional key exchange using a quantum-safe 116 algorithm to be used alongside the existing key exchange 117 algorithm while we are transitioning to a post-quantum era; 119 o to keep the modifications to IKEv2 to a minimum whilst 120 maintaining compatibility with IKEv2; and 122 o to provide a path to phase out the existing Diffie-Hellman key 123 exchange in the future. 125 It is expected that implementers of this specification are familiar 126 with IKEv2 [RFC7296], and are knowledgeable about quantum-safe 127 cryptosystems, in particular key exchange mechanisms and key 128 encapsulation mechanisms instantiated with public-key encryption. 130 The remainder of this document is organized as follows. Subsection 131 1.3 provides an overview of the terminology and the abbreviations 132 used in this document. Section 2 specifies how quantum-safe key 133 exchange is performed between two IKE peers and how keying materials 134 are derived in both IKE and Child SAs. The rationale behind the 135 approach of this extension is described in Section 3. Section 4 136 discusses security considerations. Section 5 describes IANA 137 considerations for the name spaces introduced in this document. This 138 is followed by a list of cited references and the authors' contact 139 information. 141 1.3. Terminology 142 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 143 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 144 document, are to be interpreted as described in RFC 2119 [RFC2119]. 145 In addition to using the terms defined in IKEv2 [RFC7296], this 146 document uses the following list of abbreviations: 148 KEM: It stands for key encapsulation mechanism whereby key 149 material is transported using a public-key algorithm. 151 QSKE: Denotes a quantum-safe key exchange payload, which is 152 similar to Key Exchange (KE) payload. 154 QSSS: Denotes a quantum-safe shared secret (QSSS) established from 155 QSKEi and QSKEr payloads. This entity is similar to the 156 Diffie-Hellman shared secret g^ir as defined in RFC 7296. 158 Q-S Group: 159 It stands for Quantum-Safe Group and it represents a 160 quantum-safe cryptography algorithm for key exchange. Each 161 group corresponds to an algorithm with a specific set of 162 parameters. 164 2. Hybrid Quantum-Safe Key Exchange 166 IKEv2 key exchange occurs in IKE_SA_INIT or CREATE_CHILD_SA message 167 pair which contains various payloads for negotiating cryptographic 168 algorithms, exchanging nonces, and performing a Diffie-Hellman shared 169 secret exchange for an IKE SA or a Child SA. These payloads are 170 chained together forming a linked-list and this flexible structure 171 allows an additional key exchange payload, denoted QSKE, to be 172 introduced. The additional key exchange uses algorithms that are 173 currently considered to be resistant to quantum computer attacks. 174 These algorithms are collectively referred to as quantum-safe 175 algorithms in this document. 177 2.1. Quantum-Safe Group Transform Type 179 In generating keying materials within IKEv2, both initiator and 180 responder negotiate up to four cryptographic algorithms in the SA 181 payload of an IKE_SA_INIT or a CREATE_CHILD_SA exchange. One of the 182 negotiated algorithms is an ephemeral Diffie-Hellman algorithm, which 183 is used for key-exchange. This negotiation is facilitated by the 184 Transform Type 4 (Diffie-Hellman Group) where each Diffie-Hellman 185 group is assigned a unique Transform ID. 187 In order to enable a quantum-safe key exchange in IKEv2, the various 188 quantum-safe algorithms MUST be negotiated between two IKEv2 peers. 189 Transform Type #tba (Quantum-Safe Group) is used to facilitate this 190 negotiation. It is identical to Transform Type 4, except that the 191 latter deals with various Diffie-Hellman groups only whereas the 192 former handles quantum-safe algorithms only. Each quantum-safe 193 algorithm is assigned a unique Transform ID. 195 Whilst all the key exchange algorithms in Transform Type 4 are based 196 on Diffie-Hellman, some of the algorithms in Transform Type #tba are 197 Diffie-Hellman-like, and the rest of the algorithms use key- 198 encapsulation-mechanism (KEM). In the case of KEM, the initiator 199 randomly generates a random, ephemeral public and private key pair, 200 and sends the public key to the responder in QSKEi payload. The 201 responder generates a random entity, encrypts it using the received 202 public key, and sends the encrypted quantity to the initiator in 203 QSKEr payload. The initiator decrypts the encrypted payload using 204 the private key. After this point of the exchange, both initiator 205 and responder have the same random entity from which the quantum-safe 206 shared secret (QSSS) is derived. 208 The Transform Type #tba (Quantum-Safe Group) is defined as an 209 optional type in IKE, AH and ESP protocols. This transform type MUST 210 NOT exist if there is no Transform Type 4 in a proposal. 212 For Transform Type #tba, the defined list of quantum-safe Transform 213 IDs are listed below. Note that the values below are only current as 214 of the publication date of this document. Readers should refer to 215 [IKEV2IANA] for the latest values. 217 Name Number Key exchange 218 ------------------------------------------------------ 219 RLWE 128 1 Diffie-Hellman-like 220 NewHope 128 2 Diffie-Hellman-like 221 NTRU EES743EP1 3 KEM 222 NTRU-Prime 216 4 KEM 224 2.2. IKE_SA_INIT Exchange 226 The IKE_SA_INIT request and response pairs negotiate cryptographic 227 algorithms, exchange nonces and perform a key exchange for an IKE SA. 229 Initiator Responder 230 -------------------------------------------------------------- 231 HDR, SAi1, KEi, [QSKEi,] 232 Ni --> 234 The initiator sends a QSKEi payload which contains parameters needed 235 to established a quantum-safe shared secret. The QSKEi payload is 236 marked as OPTIONAL so that it will be ignored by a responder who does 237 not understand it. In this particular case, the responder will 238 respond with a set of payloads as defined in IKEv2 [RFC7296], and 239 therefore maintaining compatibility with existing implementation. On 240 the other hand, if the responder implements this specification, it 241 will respond as follows: 243 <-- HDR, SAr1, KEr, [QSKEr,] 244 Nr, [CERTREQ] 246 The QSKEr payload completes the quantum-safe shared secret between 247 the initiator and responder. 249 At this point in the negotiation, both initiator and responder is 250 able to compute: 252 o a shared Diffie-Hellman secret from KEi and KEr pair, and 254 o a quantum-safe shared secret from QSKEi and QSKEr pair. 256 Using these two shared secrets, each peer generates SKEYSEED, from 257 which all keying materials for protection of the IKE SA are derived. 258 The quantity SKEYSEED is computed as follows: 260 SKEYSEED = prf(Ni | Nr, g^ir | QSSS) 262 where prf, Ni, Nr, and g^ir are defined as in IKEv2 [RFC7296]. QSSS 263 is represented as an octet string. The seven secrets derived from 264 SKEYSEED, namely SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr, 265 are generated as defined in IKEv2 [RFC7296]. 267 Because the initiator sends a QSKE payload, which contains quantum- 268 safe data, in the IKE_SA_INIT, it must guess a Q-S group that the 269 responder will select from its list of proposed groups. If the 270 initiator guesses incorrectly, the responder will respond with a 271 Notify payload of type INVALID_QSKE_PAYLOAD indicating the selected 272 Q-S group and the initiator MUST retry the IKE_SA_INIT with the 273 corrected Q-S group. There are two octets of data associated with 274 this notification, which contains the accepted Quantum-Safe Group 275 Transform Type number in big endian order. As in the case of 276 INVALID_KE_PAYLOAD, the initiator MUST again propose its full set of 277 acceptable cryptographic suites because the rejection message was not 278 authenticated, which may lead to any potential vulnerabilities 279 exploitation. 281 2.3. CREATE_CHILD_SA Exchange 283 The CREATE_CHILD_SA exchange is used to create new Child SAs and to 284 rekey both IKE SAs and Child SAs. If the CREATE_CHILD_SA request 285 contains a KE payload, it MAY also contain an optional QSKE payload 286 to enable quantum-safe forward secrecy for the Child SA. The keying 287 material for the Child SA is a function of Sk_d established during 288 the establishment of the IKE SA, the nonces exchanged during the 289 CREATE_CHILD_SA exchange, the Diffie-Hellman value, and the quantum- 290 safe data (if QSKE payload is included in the CREATE_CHILD_SA 291 exchange). 293 If a CREATE_CHILD_SA request includes a QSKEi payload, at least one 294 of the SA offers MUST include a Q-S group in one of its transform 295 structures. The Q-S group MUST be an element of the group that the 296 initiator expects the responder to accept. If the responder selects 297 a different Q-S group, the responder MUST reject the request by 298 sending INVALID_QSKE_PAYLOAD Notify payload. The responder's 299 preferred Q-S group is indicated in this notify payload. In the case 300 of a rejection, the initiator should retry with another 301 CREATE_CHILD_SA request containing a Q-S group that was indicated in 302 the INVALID_QSKE_PAYLOAD Notify payload. 304 2.3.1. New Child SAs from the CREATE_CHILD_SA Exchange 306 The CREATED_CHILD_SA request and response pair to create a new Child 307 SA is shown below: 309 Initiator Responder 310 -------------------------------------------------------------- 311 HDR, SK {SA, Ni, 312 [KEi,] [QSKEi,] TSi, TSr} --> 314 <-- HDR, SK {SA, Nr, 315 [KEr,] [QSKEr,] TSi, TSr} 317 The initiator sends an encrypted request containing SA offer(s), a 318 nonce, optional Diffie-Hellman and quantum-safe key exchange data and 319 the proposed Traffic Selectors. 321 The responder replies with an encrypted response containing the 322 accepted SA offer, a nonce, a Diffie-Hellman value if KEi was 323 included in the request and the expected Diffie-Hellman group was 324 selected, a quantum-safe data if QSKEi was included in the request 325 and the expected Q-S group was selected, and the accepted Traffic 326 Selectors. 328 The keying material of these CREATE_CHILD_SA exchanges that have both 329 KE and QSKE payloads is defined as: 331 KEYMAT = prf+(SK_d, QSSS (new) | g^ir (new) | Ni | Nr) 333 where prf+, Sk_d, g^ir (new), Ni and Nr are defined in IKEv2 335 [RFC7296], and QSSS (new) is the shared secret from the ephemeral 336 quantum-safe key exchange. The QSSS quantity is represented as an 337 octet string. 339 2.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 341 The CREATE_CHILD_SA request and response pair for rekeying an IKE SA 342 is shown below: 344 Initiator Responder 345 -------------------------------------------------------------- 346 HDR, SK{SA, Ni, 347 KEi[, QSKEi]} --> 348 <-- HDR, SK {SA, Nr, 349 KEr[, QSKEr]} 351 The initiator sends an encrypted request containing amongst other 352 payloads, a KEi payload which carries a Diffie-Hellman value, and an 353 OPTIONAL QSKEi payload which carries a quantum-safe data. 355 The responder replies with an encrypted response containing a number 356 of payloads. If the responder selects a Diffie-Hellman group that 357 matches one of the proposed group(s), a KEr payload containing a 358 Diffie-Hellman public value is replied in the encrypted response. If 359 the request contains a QSKEr payload and the responder selects a Q-S 360 group that matches one of the proposed group(s), a QSKEr payload 361 containing quantum-safe data is sent in the reply. 363 The quantity SKEYSEED for the new IKE SA is computed as follows: 365 SKEYSEED = prf(SK_d (old), QSSS (new) | g^ir (new) | Ni | Nr) 367 where prf, SK_d (old), g^ir (new), Ni and Nr are defined in IKEv2 368 [RFC7296], QSSS (new) is the shared secret from the ephemeral 369 quantum-safe key exchange. The QSSS quantity is represented as an 370 octet string. 372 2.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange 374 The CREATE_CHILD_SA request and response pair for rekeying a Child SA 375 is shown below: 377 Initiator Responder 378 -------------------------------------------------------------- 379 HDR, SK {N(REKEY_SA), SA, 380 Ni, [KEi,] [QSKEi,] 381 TSi, TSr} --> 382 <-- HDR, SK {SA, Nr, 383 [KEr,] [QSKEr,] TSi, TSr} 385 Both KEi and QSKEi payloads are OPTIONAL. The KEi and QSKEi 386 payloads, which are sent encrypted by the initiator, carry a Diffie- 387 Hellman value and quantum-safe data respectively. 389 If the CREATE_CHILD_SA request includes KEi and QSKEi payloads, 390 provided that a Diffie-Hellman group and a Q-S group are present in 391 the SA offers, the responder replies with an encrypted response 392 containing both KEr and QSKEr payloads. 394 The keying material computation of this exchange is the same as that 395 defined in [Section 2.3.1]. 397 2.4. QSKE Payload Format 399 The quantum-safe key exchange payload, denoted QSKE in this document, 400 is used to exchange a quantum-safe shared secret between two IKE 401 peers. The QSKE payload consists of the IKE generic payload header, 402 a two-octet value denoting the Quantum-Safe Group number, and 403 followed by the quantum-safe data itself. The format of the QSKE 404 payload is shown below. 406 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Next Payload |C| RESERVED | Payload Length | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Quantum-Safe Group Num | RESERVED | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | | 414 ~ Quantum-Safe Data ~ 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 The length of the quantum-safe data varies depending on the type of 419 quantum-safe cipher. The content type of quantum-safe data is also 420 dependent on the type of quantum-safe cipher. For quantum-safe 421 ciphers that use Diffie-Hellman-like key exchange, the content of the 422 quantum-safe data is the proposed/accepted cipher's public value. 423 For ciphers that use KEM, the content is either a random public-key 424 of the proposed quantum-safe cipher in the case of QSKEi payload, or 425 the content is a ciphertext produced using the received public-key in 426 the case of QSKEr payload. 428 The Quantum-Safe Group Num identifies the quantum-safe cipher with 429 which the quantum-safe data was computed. The Quantum-Safe Group Num 430 MUST match the Q-S group specified in a proposal in the SA payload 431 sent in the same message. If the proposal in the SA payload does not 432 specify a quantum-safe cipher, the QSKE payload MUST NOT be present. 433 If the responder selects a Q-S group that does not match the proposed 434 group, the quantum-safe key exchange MUST be rejected with a Notify 435 payload of type INVALID_QSKE_PAYLOAD. The chosen Q-S group is 436 indicated in the INVALID_QSKE_PAYLOAD Notify payload and the 437 initiator can restart the exchange with that group. 439 The payload type for the QSKE payload is TBA (TBA). 441 3. Design Rationale 443 In general, the size of QSKE payload is larger than that of the KE 444 counterpart and sending it in the IKE_SA_INIT may prevent peers from 445 establishing IPSec Security Association (SA) due to fragmentation. 446 While the fragmentation issue may be addressed by sending QSKE in the 447 IKE_AUTH exchange, it is decided that QSKE should still be exchanged 448 in the IKE_SA_INIT. The rationale behind this decision is discussed 449 below. 451 3.1. Threat Categories 453 The treats to the IKE exchange can be broken into two categories: 455 1. From current day until general purpose quantum computers are 456 available. 458 The addition of the QSKE allows the IKEv2 exchange to be 459 secured against an adversary who captures all control plane 460 (IKE) and data plane (ESP) traffic, with the intention of 461 breaking the IKE exchange (when quantum computers become 462 available) and subsequently being able to view the data plane 463 traffic. The use of the QSKE in the IKE_SA_INIT results in 464 the IKE SA becoming quantum secure against future attacks. 466 2. After general purpose quantum computers are available. 468 Once general purpose quantum computers are available there are 469 two types of attack: 471 o Active attack 473 Assuming that a general purpose quantum computer is 474 available and an adversary can manipulate the IKE exchange 475 in real time. The attacker can break Diffie-Hellman in 476 real time, but not the QSKE. This results in the IKE_AUTH 477 exchange being secure as the QSKE is included in the 478 derivation of key material used to secure the IKE_AUTH 479 exchange. 481 However, an active attacker who can sit between two hosts 482 and impersonate each host can perform a man-in-the-middle 483 (MitM) attack when the authentication method is not quantum 484 secure. This includes any asymmetric authentication method 485 and non-quantum computer resistant Extensible 486 Authentication Protocol (EAP) authentication. For 487 authentication methods which are quantum secure, such as 488 using shared key message integrity code comprising a 489 shared-secret with sufficient entropy (256 bits), this 490 allows for the IKEv2 exchange to be secured against an 491 active adversary when including the QSKE. 493 o Passive attack 495 As per the first category, the addition of the QSKE allows 496 the IKEv2 exchange to be secured against an adversary who 497 captures all control plane (IKE) and data plane (ESP) 498 traffic, with the intention of breaking the IKE exchange. 500 3.2. Dealing with Fragmentation 502 In some instances, the QSKE public value will be large enough to 503 cause fragmentation to occur at the IP layer. In practice, there 504 will be cases where IKE traffic fragmented at the IP layer will be 505 dropped by network devices such as NAT/PAT gateways, Intrusion 506 Prevention System (IPS), firewalls and proxies, that cannot handle IP 507 fragments or are configured to block IP fragments. This blocked 508 traffic will prevent the IKE session from being established. The 509 issue with fragmentation can easily be avoided by moving the QSKE to 510 the IKE_AUTH exchange and by employing IKEv2 Message Fragmentation 511 [RFC7383]. The implication of this is that while all the Child SAs, 512 which carry the data traffic, would be quantum secure, the IKE SA 513 itself would not be, resulting in the disclosure of IKE identities 514 and IPsec proxies. Furthermore by sending the QSKE in IKE_AUTH and 515 not IKE_SA_INIT would allow an active attacker with a quantum 516 computer to perform attacks against IKE such as forging an identity 517 used for authentication, abuse of attributes sent in the CFG 518 exchange, MitM attack, DoS, etc. It is believed that the trade off 519 to deliver a quantum resistant IKE SA is of greater security benefit 520 than the issues that could be encountered due to fragmentation at the 521 IP layer. It is worth noting that encapsulating IKE traffic within 522 TCP [IKETCPENCAP] is a simple method to prevent IKE_SA_INIT traffic 523 being fragmented at the IP layer. 525 The following table gives an idea of the common size of the QSKE 526 payload in the proposed schemes. 528 Scheme QSKE size (octets) 529 ------------------------------------- 530 RLWE 128 4096 531 NewHope 128 1792 532 NTRU EES743EP1 1030 533 NTRU-Prime 216 1200 535 It is evident that both NewHope 128 and RLWE 128 will naturally 536 increase an IP Maximum Transmission Unit (MTU) to be larger than 1500 537 octets which is common for most Internet traffic, resulting in the 538 IKE_SA_INIT being fragmented at the IP layer. 540 3.3. Removal of the Diffie-Hellman exchange 542 The IKE_SA_INIT exchange currently mandates the use of the Diffie- 543 Hellman. As the Diffie-Hellman exchange is not quantum secure and 544 the QSKE exchange is quantum secure, the addition of the QSKE can be 545 thought of making the Diffie-Hellman redundant. This draft does not 546 advise removing the use of Diffie-Hellman, though future 547 implementations that have migrated to using QSKE could remove the 548 requirement to send the Diffie-Hellman exchange with the QSKE 549 providing the same functionality. Sending the QSKE in the 550 IKE_SA_INIT allows for a simple transition to only using QSKE should 551 the need to remove the Diffie-Hellman exchange occur. 553 4. Security Considerations 555 The key length of the Encryption Algorithm (Transform Type 1), the 556 Pseudorandom Function (Transform Type 2) and the Integrity Algorithm 557 (Transform Type 3), all have to be of sufficient length to prevent 558 attacks using Grover's algorithm [GROVER]. In order to use the 559 extension proposed in this document, the key lengths of these 560 transforms SHALL be at least 256 bits long in order to prevent any 561 quantum attacks from succeeding. Accordingly the post-quantum 562 security level achieved is at least 128 bits. 564 The quantities SKEYSEED and KEYMAT are calculated from shared 565 secrets, g^ir and QSSS, using an algorithm defined in Transform Type 566 2. While a quantum attacker may learn the value of g^ir, the 567 quantity QSSS ensures that neither SKEYSEED nor KEYMAT is 568 compromised. This assumes that the algorithm defined in the 569 Transform Type 2 is quantum-safe. 571 Because some quantum-safe public values are in the order of several 572 KB, a IKEv2 message that contains such a QSKE payload will exceed the 573 path Maximum Transmission Unit (MTU) and the message may be 574 fragmented at the IP level. This presents the possibility of an 575 attack vector that relies on IP fragmentation. One such attack 576 vector is to mount a denial of service by swamping a receiver with IP 577 fragments [DOSUDPPROT]. This issue could be mitigated by employing 578 TCP encapsulation [IKETCPENCAP]. 580 The authenticity of the SAs established under IKEv2 is protected 581 using a pre-shared key, RSA, DSS, or ECDSA algorithms. Whilst the 582 pre-shared key option, provided the key is long enough, is quantum- 583 safe, the other algorithms are not. Moreover, in implementations 584 where scalability is a requirement, the pre-shared key method may not 585 be suitable. Quantum-safe authenticity may be provided by using a 586 quantum-safe digital signature and several quantum-safe digital 587 signature methods are being explored by IETF. For example the hash 588 based method, XMSS has the status of an Internet Draft, see [XMSS]. 589 Currently, quantum-safe authentication methods are not specified in 590 this document, but are planned to be incorporated in due course. 592 It should be noted that the purpose of quantum-safe algorithms is to 593 prevent attacks, mounted in the future, from succeeding. The current 594 threat is that encrypted sessions may be subject to eavesdropping and 595 archived with decryption by quantum computers taking place at some 596 point in the future. Until quantum computers become available there 597 is no point in attacking the authenticity of a connection because 598 there are no possibilities for exploitation. These only occur at the 599 time of the connection, for example by mounting a MitM attack. 600 Consequently there is not such a pressing need for quantum-safe 601 authenticity. 603 The use of the QSKE provides an method for malicious parties to send 604 IKE_SA_INIT initiator messages containing QSKE of type KEM and with 605 random values. As the standard behavior is for the responder to 606 generate a random entity, encrypt it using the received public key 607 (which would be a random value), and sends the encrypted quantity to 608 the initiator in QSKEr payload. This allows for a simply method for 609 malicious parties to cause a VPN gateway to perform excessive 610 processing. To mitigate against this threat, implementations can 611 make use of the COOKIE notification as defined in [RFC7296], to 612 mitigate spoofed traffic and [RFC8019] to minimize the impact from 613 hosts who use their own IP address. 615 5. IANA Considerations 617 This document defines a new IANA registry for IKEv2 Transform Types. 619 Trans. 620 Description Type Used In 621 ----------------------------------------------------------- 622 Quantum-Safe Group (Q-S) tba Optional in IKE, AH & ESP 624 A number of Transform IDs of the Q-S group Transform Type are also 625 defined. The initial values are listed below: 627 Name Value 628 ------------------------------ 629 RLWE 128 1 630 NewHope 128 2 631 NTRU EES743EP1 3 632 NTRU-Prime 216 4 634 In order to transport quantum-safe data to establish a quantum-safe 635 SA, this extension registers a new key exchange payload in the IKEv2 636 Payload Types of the IANA registry: 638 Description Notation Value 639 --------------------------------- 640 QSKE Payload QSKE tba 642 This extension also specifies a new error type in the IKEv2 Notify 643 Message Types - Error Types of the IANA registry: 645 Error Type Value 646 ------------------------------ 647 INVALID_QSKE_PAYLOAD tba 649 6. References 651 [ADPS] Alkim, E., Ducas, L., Poppelmann, T., and Schwabe, P., 652 "Post-quantum Key Exchange - a New Hope", 25th USENIX 653 Security Symposium, pp. 327-343, 2016. 655 [AH] Kent, S., "IP Authentication Header", RFC 4302, December 656 2005, . 658 [BCNS15] Bos, J., Costello, C., Naehrig, M., and Stebila, D., 659 "Post-quantum Key Exchange for the TLS Protocol from the 660 Ring Learning with Errors Problem", IEEE Symposium on 661 Security and Privacy, pp. 553-570, 2015. 663 [DH] Diffie, W., and Hellman, M., "New Directions in 664 Cryptography", IEEE Transactions on Information Theory, 665 V.IT-22 n. 6, June 1977. 667 [DOSUDPPROT] 668 Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS 669 protection for UDP-based protocols", ACM Conference on 670 Computer and Communications Security, October 2003. 672 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 673 4303, December 2005, . 676 [GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for 677 Database Search", Proc. of the Twenty-Eighth Annual ACM 678 Symposium on the Theory of Computing (STOC 1996), 1996 680 [IKETCPENCAP] 681 Pauly, T., Touati, S., and Mantha, R., "TCP Encapsulation 682 of IKE and IPsec Packets", draft RFC, May 2017, 683 . 686 [IKEV2IANA] 687 IANA, "Internet Key Exchange Version 2 (IKEv2) 688 Parameters", . 691 [LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., 692 Green, M., Halderman, J., Heninger, N., Springall, D., 693 Thome, E., Valenta, L., VanderSloot, B., Wustrow, E., 694 Beguelin, S., and Zimmermann, P., "Imperfect forward 695 secrecy: How Diffie-Hellman fails in practice", Proc. 22rd 696 ACM SIGSAC Conference on Computer and Communications 697 Security, pp. 5-17, 2015. 699 [NTRU] Hoffstein, J., Pipher, J., and Silverman, J., "NTRU: A 700 Ring-Based Public Key Cryptosystem", Lecture Notes in 701 Computer Science, pp. 267-288, 1998. 703 [NTRUPRIME] 704 Bernstein, D., Chuengsatiansup, C., Lange, T., and van 705 Vredendaal, C., "NTRU Prime", IACR Cryptology ePrint 706 Archive: Report 2016/461, 2016. 708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 709 Requirement Levels", RFC 2119, March 1997. 711 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and 712 Kivinen, T., "Internet Key Exchange Protocol Version 2 713 (IKEv2)", RFC 7296, October 2014. 715 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 716 (IKEv2) Message Fragmentation", RFC 7383, November 2014. 718 [RFC8019] Nir, Y., Smyslov, V., "Protecting Internet Key Exchange 719 Protocol Version 2 (IKEv2) Implementations from 720 Distributed Denial-of-Service Attacks", RFC 8019, November 721 2016. 723 [XMSS] Huelsing, A., Butin, D., Gazdag, S., and Mohaisen, A., 724 "XMSS: Extended Hash-Based Signatures", Crypto Forum 725 Research Group Internet Draft, 2017 727 Appendix A. Quantum-safe Ciphers 729 Each of the specific quantum-safe ciphers is assigned a unique 730 Transform ID. All of the selected quantum-safe ciphers are based on 731 lattice construction. Specifically the ciphers fall into the 732 categories of Ring Learning With Errors, NTRU and Streamlined NTRU 733 Prime. In each case the selected parameters are chosen so as to 734 achieve at least 128 bits of post-quantum security. 736 Appendix A.1. Ring Learning With Errors 738 Ring Learning with Errors is a cryptographic primitive that relies on 739 the worst-case hardness of a shortest vector problem in ideal 740 lattices. It is commonly abbreviated as RLWE. The security 741 parameters are given by an integer n which is a power of 2, a prime 742 integer q, an array of n coefficients denoted by {a} and a standard 743 deviation sigma along with the type of error distribution X. Note 744 that each coefficient of {a} is less than the prime q and is sampled 745 from distribution X. Let a(x) be a polynomial, whose coefficients 746 are given by {a}, the RLWE problem can be stated as follows: given 747 polynomials a(x), b(x) and a small polynomial e(x), find the secret 748 s(x) from the relationship a(x) * s(x) + b(x) = e(x) modulo q. 750 RLWE 128 751 -------- 752 This set of parameters follows the system described by Bos et al 753 [BCNS15]. Using a fixed coefficient array {a} in this way may result 754 in security vulnerabilities such as "all-for-the-price-of-one" 755 precomputation attacks such as the Logjam attack on the classical 756 Diffie-Hellman key exchange [LOGJAM]. As has been pointed out since, 757 this is straightforwardly solved by the coefficient array {a} being 758 generated on-the-fly for each key exchange from a seed value shared 759 by the initiator and responder. The fixed coefficient array {a} is 760 also avoided in similar fashion in NewHope 128 (see below). 762 The set of parameters that is proposed by Bos et al is given as 763 follows: 765 n = 1024 766 q = 2^32 -1 767 sigma = 8/sqrt(2 * PI) 768 X = discrete Gaussian 769 {a} = 29FE0191, DD1A457D, 3534EE4B, 6450ED74, BBFE9F64, 92BF0F31, 770 8DCF8995, 4C5E30D0, 9E2ED04D, 8C18FE0B, 1A70F2E7, 2625CD93, 771 0065DA14, 6E009722, E6A70E8B, AEF6EF56, 8C6C06AF, 9E59E953, 772 4995F67B, E918EE9D, 8B4F41A7, 0D811041, F5FE6458, 3C02B584, 773 CBCFC8FD, 5A01F116, 73408361, 44D3A098, BBDEECF6, 90E09082, 774 F8538BA4, F9600091, D8D30FEF, 56201487, ACB2159D, 38F47F77, 775 ED7A864F, 8FC785CA, 7CBD6108, 3CA577DE, FF44CCC2, A1385A79, 776 5C88E3AD, 177C46A9, DA4A4DD8, 2AA3594F, A4A5E629, 47CA6F6E, 777 B2DF1BC6, 6841B78E, 0823F5A8, A18C7D52, 7634A0D1, DA1751BA, 778 18B9D25D, 5B2643BC, ACC6975D, 48E786F4, 05E3ED4E, 4DC86568, 779 3F5C5F99, 585DBFD7, EF6E0715, 7D36B823, 12D872CD, D7B78F27, 780 DD672BF5, 2DC7C7EB, A3033801, 50E48348, 9162A260, 0BE8F15B, 781 ABB563EC, 06624C5A, 812BF7BC, 8637AC35, F44504F3, FF8577AB, 782 4A0161B0, 000AEB0E, 311204AF, 2A76831B, 4D903F3A, 97204FA9, 783 9EB524E3, 1757AFAC, BA369FEC, CD8F198D, 6B33C246, 51C13FCE, 784 B58ACC4E, 39ACF8DA, 7BB7EBF7, EDC1449D, C7B47FDB, 9C39148D, 785 4E688D7B, FAD0C2C2, 296CE85C, 6045C89C, 6441C0C6, 50C7C83A, 786 C11764DD, 58D7EEA2, E57B9D0E, 4E142770, B8BFBB59, E143EBAA, 787 FF60C855, 238727F0, E35B4A5B, 8F96940B, 4498A6BA, 5911093A, 788 394DD002, 521B00D2, 140BDAF9, EAB67207, 21E631A6, A04AADA9, 789 A96A9843, 4B44CC9B, E4D24C33, C7E7AE78, E45A6C72, CBE61D3C, 790 CE5A4869, 10442A52, DB11F194, 39FC415D, 7E7BDB76, AE9EFA22, 791 25F4F262, 472DD0A7, 42EBD7A0, E8038ECE, D3DB002A, 8416D2EC, 792 DF88C989, 7FEA22D5, C7A3F6FE, 37409982, F45B75E2, 9A4AC289, 793 90406FD6, EA1C74A5, 5777B39F, D07F1FA3, CE6EDA0D, D150ECFB, 794 BEFF71BA, 50129EFC, 51CE65B9, B9FB0AB8, 770C59CB, 11F2354F, 795 8623D4BB, D6FCAFD6, B2B1697C, 0D7067E2, 2BA5AFB9, D369C585, 796 5B5E156C, D8C81E6E, 80CFDF16, F6F441EB, C173BAF5, 78099E3A, 797 D38F027B, 4AC8D518, 8D0108A1, E442B0F1, 56F9EA3C, D0D6BBCA, 798 4E17DCB4, 69BF743B, 0CCE779F, D5E59851, 63861EA2, B1CB22C1, 799 BBFD2ACE, DDA390D1, EDF1059F, 04F80F89, B13AF849, 58C66009, 800 E0D781C0, 588DC348, A305669D, 0D7AF67F, 32BC3C38, D725EFBA, 801 DC3D9434, 22BD7ED8, 2DFD2926, 4BDEAD3A, B2D5ECE6, 16B05C99, 802 FEEC7104, F6CAC918, 0944C774, CE00633B, C59DA01A, 41E8E924, 803 335DF501, 3049E8EE, 5B4B8AAC, C962FC91, D6BB22B3, 0AC870EB, 804 C3D99400, A0CEAC28, AF07DE1E, 831C2824, 258C5DDC, 779417E6, 805 41CB33D0, 4E51076A, D1DB6038, 9E0B1C41, A9A1F90D, F27E7705, 806 75892711, 5D9F1175, 85CC508B, 5CA415BE, 1858C792, FB18632F, 807 C94111EB, 937C0D28, C2A09970, 386209D9, BBDD9787, 2473F53A, 808 EF7E7637, CFC8630B, 2BA3B7F8, 3C0047AD, 10D76FF7, B1D9414D, 809 CEB7B902, A5B543F5, 2E484905, E0233C10, D061A1F8, CED0A901, 810 AC373CAC, 04281F37, 3609797F, DB80964D, 7B49A74F, 7699656F, 811 0DCEC4BC, 0EC49C2D, F1573A4E, A3708464, 9A1E89F0, 6B26DEB6, 812 2329FA10, CA4F2BFF, 9E012C8E, 788C1DFD, 2C758156, 2774C544, 813 150A1F7D, 50156D6E, 7B675DE1, 5D634703, A7CEB801, 92733DAB, 814 B213C00B, 304A65B1, 8856CF8E, 7FF7DD67, D0912293, 30064297, 815 663D051D, 01BC31B4, 2B1700BD, 39D7D18F, 1EAD5C95, 6FB9CD8B, 816 A09993A6, B42071C0, 3C1F2195, 7FDF4CF8, C7565A7E, 64703D34, 817 14B250EF, 2FA338D2, AEE576DC, 6CCED41D, 612D0913, D0680733, 818 8B4DBE8A, 6FFEA3D0, 46197CA2, A77F916F, FA5D7BD6, 01E22AEB, 819 18E462DD, 4EC9B937, DE753212, 05113C94, 7786FBD4, FB379F71, 820 756CF595, EAADCFAB, BBD74C2E, 1F234AC9, 85E28AEB, 329F7878, 821 D48FDE09, 47A60D0A, AE95163F, 72E70995, 27F9FCBF, BDCFCC41, 822 334BC498, EE7931A1, DFA6AEF4, 1EC5E1BF, 6221870F, CD54AE13, 823 7B56EF58, 4847B490, 31640CD3, 10940E14, 556CC334, C9E9B521, 824 499611FF, BEC8D592, 44A7DCB7, 4AC2EABD, 7D387357, 1B76D4B6, 825 2EACE8C9, 52B2D2A4, 0C1F2A64, 50EF2B9A, 3B23F4F4, 8DDE415E, 826 F6B92D2D, 9DB0F840, E18F309D, 737B7733, F9F563C5, 3C5D4AEE, 827 8136B0AF, C5AC5550, 6E93DEF9, 946BCCEC, 5163A273, B5C72175, 828 4919EFBD, 222E9B68, 6E43D8EE, AA039B23, 913FD80D, 42206F18, 829 5552C01F, 35B1136D, FDC18279, 5946202B, FAAE3A37, 4C764C88, 830 78075D9B, 844C8BA0, CC33419E, 4B0832F6, 10D15E89, EE0DD05A, 831 27432AF3, E12CECA6, 60A231B3, F81F258E, E0BA44D7, 144F471B, 832 B4C8451E, 3705395C, E8A69794, 3C23F27E, 186D2FBA, 3DAED36B, 833 F04DEFF1, 0CFA7BDD, FEE45A4F, 5E9A4684, 98438C69, 5F1D921B, 834 7E43FD86, BD0CF049, 28F47D38, 7DF38246, 8EED8923, E524E7FC, 835 089BEC03, 15E3DE77, 78E8AE28, CB79A298, 9F604E2B, 3C6428F7, 836 DCDEABF3, 33BAF60A, BF801273, 247B0C3E, E74A8192, B45AC81D, 837 FC0D2ABE, F17E99F5, 412BD1C1, 75DF4247, A90FC3C0, B2A99C0E, 838 0D3999D7, D04543BA, 0FBC28A1, EF68C7EF, 64327F30, F11ECDBE, 839 4DBD312C, D71CE03A, AEFDAD34, E1CC7315, 797A865C, B9F1B1EB, 840 F7E68DFA, 816685B4, 9F38D44B, 366911C8, 756A7336, 696B8261, 841 C2FA21D2, 75085BF3, 2E5402B4, 75E6E744, EAD80B0C, 4E689F68, 842 7A9452C6, A5E1958A, 4B2B0A24, 97E0165E, A4539B68, F87A3096, 843 6543CA9D, 92A8D398, A7D7FDB4, 1EA966B3, 75B50372, 4C63A778, 844 34E8E033, 87C60F82, FC47303B, 8469AB86, 2DAADA50, CFBB663F, 845 711C9C41, E6C1C423, 8751BAA9, 861EC777, 31BCCCE1, C1333271, 846 06864BEE, 41B50595, D2267D30, 878BA5C5, 65267F56, 2118FB18, 847 A6DDD3DE, 8D309B98, 68928CB2, FAE967DC, 3CEC52D0, 9CA8404B, 848 AADD68A8, 3AC6B1DF, D53D67EA, 95C8D163, B5F03F1D, 3A4C28A7, 849 E3C4B709, B8EB7C65, E76B42A3, 25E5A217, 6B6DD2B4, BEFC5DF4, 850 9ACA5758, C17F14D3, B224A9D3, DE1A7C8F, 1382911B, 627A2FB9, 851 C66AE36E, 02CC60EF, C6800B20, 7A583C77, E1CECEE8, CA0001B4, 852 6A14CF16, EF45DD21, 64CAA7D5, FF3F1D95, D328C67E, C85868B1, 853 7FBF3FEB, 13D68388, 25373DD9, 8DE47EFB, 47912F26, 65515942, 854 C5ED711D, 6A368929, A2405C50, FFA9D6EB, ED39A0D4, E456B8B5, 855 53283330, 7837FD52, 6EE46629, CAFC9D63, B781B08F, DD61D834, 856 FB9ACF09, EDA4444A, BB6AA57F, AED2385C, 22C9474D, 36E90167, 857 E6DF6150, F1B0DA3B, C3F6800E, 966302E0, 7DB1F627, F9632186, 858 B4933075, 81C5C817, 878CA140, 4EDE8FED, 1AF347C1, FDEB72BA, 859 2DA7FF9A, B9BA3638, 2BB883F1, 474D1417, C2F474A4, 1E2CF9F3, 860 231CB6B0, 7E574B53, EDA8E1DA, E1ACB7BB, D1E354A6, 7C32B431, 861 8189991B, 25F9376A, 3FFA8782, CD9038F1, 119EDBD1, 5C571840, 862 3DCA350F, 83923909, 9DC3CF55, 94D79DD0, D683DE2B, ECF4316A, 863 0FFF48D4, 5D8076ED, 12B42C97, 2284CDB4, CB245554, 3025B4D9, 864 B0075F35, 43A3802E, 18332B4D, 056C4467, C597E3F7, 3F0EAF9D, 865 F48EBB9F, 92F62731, BDB76296, 516D4466, 226102B3, 15E38046, 866 A683C4E0, 6C0D1962, E20CB6CA, C90C1D70, D0FF8692, D1419690, 867 2D6F1081, 34782E5E, AE092CD5, 90C99193, E97C0405, EAE201DA, 868 631FB5AC, 279A2821, DF47BA5B, FBE587E2, 6810AD2D, C63E94BD, 869 9AF36B42, F14F0855, 946CE350, 7E3320E0, 34130DFF, 8C57C413, 870 AB0723B2, F514C743, 63694BA3, 5665D23D, 6292C0B5, 9D768323, 871 2F8E447C, B99A00FB, 6F8E5970, 69B3BB45, 59253E02, 1C518A02, 872 DD7C1232, C6416C38, 77E10340, CF6BEB9A, 006F9239, 0E99B50F, 873 863AD247, 75F0451A, 096E9094, E0C2B357, 7CC81E15, 222759D4, 874 EE5BCFD0, 050F829B, 723B8FA9, 76143C55, 3B455EAF, C2683EFD, 875 EE7874B4, 9BCE92F7, 6EED7461, 8E93898F, A4EBE1D0, FA4F019F, 876 1B0AD6DA, A39CDE2F, 27002B33, 830D478D, 3EEA937E, 572E7DA3, 877 4BFFA4D1, 5E53DB0B, 708D21EE, B003E23B, 12ED0756, 53CA0412, 878 73237D35, 438EC16B, 295177B8, C85F4EE6, B67FD3B4, 5221BC81, 879 D84E3094, 18C84200, 855E0795, 37BEC004, DF9FAFC9, 60BEB6CD, 880 8645F0C5, B1D2F1C3, ECDC4AE3, 424D17F1, 8429238C, 6155EAAB, 881 A17BEE21, 218D3637, 88A462CC, 8A1A031E, 3F671EA5, 9FA08639, 882 FF4A0F8E, 34167A7D, 1A817F54, 3215F21E, 412DD498, 57B633E7, 883 E8A2431F, 397BD699, 5A155288, BB3538E8, A49806D2, 49438A07, 884 24963568, 40414C26, E45C08D4, 61D2435B, 2F36AEDE, 6580370C, 885 02A56A5E, 53B18017, AF2C83FC, F4C83871, D9E5DDC3, 17B90B01, 886 ED4A0904, FA6DA26B, 35D9840D, A0C505E4, 3396D0B5, EC66B509, 887 C190E41C, 2F0CE5CF, 419C3E94, 220D42CA, 2F611F4F, 47906734, 888 8C2CDB17, D8658F1C, 2F6745CD, 543D0D4F, 818F0469, 380FFDAE, 889 F5DD91E2, AD25E46A, E7039205, A9F47165, B2114C12, CF7F626F, 890 54D2C9FF, E4736A36, 16DB09FC, E2B787BB, 9631709A, 72629F66, 891 819EBA08, 7F5D73F3, A0B0B91C, FEDFBA71, 252F14EE, F26F8FA2, 892 92805F94, 43650F7F, 3051124F, 72CA8EAD, 21973E34, A5B70509, 893 B36A41CC, C52EDE5F, F706A24E, 8AAF9F92, ADF6D99A, 23746D73, 894 1DA39F70, 9660FC8F, A0A8CFEB, 83D5EFCA, 0AA4A72F, EEF1B2DE, 895 00CFCC66, 8A145369, 6376CEDA, A3262E2E, 3367BBA8, 01488C32, 896 5561A2AD, 40821BF2, F0C89F61, C4FAA6B3, D843377A, 67A76555, 897 E8D9F1CE, 943034FF, 2BD468BD, A514D935, 50CDB19D, A09C7E9E, 898 6FEBEC30, B1B36CF7, CD7A30BC, 36C6FE0A, 2DF52C45, 45C9957F, 899 65076A79, BF783DEE, 718D37F0, 098F9117, 9A70C430, 80EB1A53, 900 9F2505B1, 48D10D98, B8D781E9, F2376133, ECF25B98, 5A3B0E18, 901 2F623537, 9F0E34A4, F1027EB6, F9B16022, BA3FEC59, EF7226FD, 902 9F3058AA, BB51DE0E, D5435EA0, 8A6479D5, 077708B8, 9634876A, 903 069A260A, 168D9E6A, 9FD18E94, 8A7ACD53, 8E5A5869, 1B6F35FD, 904 A968913B, C72F076B, 7DDA354C, 25B0297C, D07219D5, A66862BA, 905 87E8EE67, FA28809B, 55762443, 31EF4956, F4F4A511, 9A9378CB, 906 42ABDBDE, 7AA484B7, E8EC22ED, CADDEF61, 9D18538A, A81B923E, 907 9C32F92A, 6D278E58, 4CDFC716, AB64814F, F832BF1A, E2C1A36B, 908 20675610, E78D855A, 38332C3D, 5AE0EAD9, 2E23F22D, 3C8683C5, 909 A351AF89, 54720D3B, ABC6E51F, 89330C8E, 600D5650, 197EA0C6, 910 7D502A5D, 3A536EA7, 7DF71F32, 456FE645, 3EF5E7A2, 6664BCAF, 911 A9D074C2, E9D9E478, 1AE9AB77, FECE7160, C618EEEC, 771B0026, 912 2B54F43C, 145DA102, 1B3D7949, BB6E2D9D, DB8FDC4A, 25397EBA, 913 9228A6E9, 56B4C69D, 337B943C, E35B716C, F7FE89A1, 023AC20D, 914 033165C8, 9F13B130, C1BAFB1D, A2C42C8C, 58E4D431, E10741E6, 915 2547589A, 8D9EF7BD, 7E322280, F49FDDC2, BE21A094, A061178A, 916 34D9F13B, 694D652F, 05084A2A, 2767B991, E8536AB4, EBFADF6F, 917 F4C8DFAC, D9967CCA, E04BCF3F, 232B3460, 9FF6E88A, 6DF3A2B0, 918 0FE10E99, 7B059283, 067BFB57, 8DDA26B0, B7D6652F, 85705248, 919 0826240C, 5DF7F52E, 47973463, B9C22D37, 9BEB265D, 493AB6FD, 920 10C0FB07, 947C102A, 5FEC0608, 140E07AE, 8B330F43, 9364A649, 921 C9AD63EF, BE4B2475, 1A09AC77, 9E40A4B0, BA9C23E7, 7F4A798D, 922 E2C52D66, A26EE9E0, 8C79DCE7, DD7F1C3D, 6AE83B20, 073DBA03, 923 B1844D97, 16D7ED6E, 5E0DE0B1, A497D717, FA507AA2, C332649B, 924 21419E15, 384D9CCC, 8B915A8B, BA328FD5, F99E8016, 545725EC, 925 ED9840ED, 71E5D78A, 21862496, 6F858B6C, F3736AE2, 8979FC2B, 926 5C8122D0, 0A20EB5A, 2278AA6E, 55275E74, 22D57650, E5FFDC96, 927 6BA86E10, 4EC5BFCC, 05AFA305, FB7FD007, 726EA097, F6A349C4, 928 CB2F71E4, 08DD80BA, 892D0E23, BD2E0A55, 40AC0CD3, BFAF5688, 929 6E40A6A5, 6DA1BBE0, 969557A9, FB88629B, 11F845C4, 5FC91C6F, 930 1B0C7E79, D6946953, 27A164A0, 55D20869, 29A2182D, 406AA963, 931 74F40C59, 56A90570, 535AC9C6, 9521EF76, BA38759B, CD6EF76E, 932 F2181DB9, 7BE78DA6, F88E4115, ABA7E166, F60DC9B3, FECA1EF3, 933 43DF196A, CC4FC9DD, 428A8961, CF6B4560, 87B30B57, 20E7BAC5, 934 BFBDCCDF, F7D3F6BB, 7FC311C8, 2C7835B5, A24F6821, 6A38454C, 935 460E42FD, 2B6BA832, C7068C72, 28CDCE59, AE82A0B4, 25F39572, 936 9B6C7758, E0FE9EBA, A8F03EE1, D70B928E, 95E529D7, DD91DB86, 937 F912BA8C, 7F478A6A, 1F017850, 5A717E10, DAC243F9, D235F314, 938 4F80AAE6, A46364D8, A1E3A9E9, 495FEFB1, B9058508, 23A20999, 939 73D18118, CA3EEE2A, 34E1C7E2, AADBADBD. 941 The public key size of RLWE 128 is 4096 octets and it provides 128- 942 bit post-quantum security, although it does not provide forward 943 secrecy due to the way coefficient array {a} is generated. A set of 944 open source ciphersuites has been implemented and included in OpenSSL 945 v1.0.1f and may be found within the libcrypto module. The authors 946 anticipate RLWE being incorporated into TLS with the RLWE 128 947 ciphersuites being compatible with TLS 1.3. Moreover, the 948 ciphersuites are constant time, and therefore are not vulnerable to 949 possible side channel attacks. 951 NewHope 128 952 ----------- 953 This is a variation on the ring learning with errors cipher by Alkim 954 et al [ADPS] who set out in their solution to make improvements to 955 RLWE 128. Their main improvements are to use a random coefficient 956 array {a} for each key exchange and to reduce the size of key 957 exchanges by using a 14-bit modulus instead of a 32-bit modulus. 958 Additionally they relax the requirement for the error distribution to 959 be discrete Gaussian and substitute the easier to generate Binomial 960 distribution and provide a security justification. The set of 961 parameters proposed by Alkim et al is given as follows: 963 n = 1024 964 q = 12289 965 sigma = sqrt(8) 966 X = Binomial 968 This cipher provides 128-bit post-quantum security and has a public 969 key size of 1792 octets. It features forward secrecy. Open source, 970 constant time, side-channel-proof, ciphersuites are publically 971 available. 973 Appendix A.2. NTRU Lattices 975 NTRU lattices are another variant of cryptosystems based on integer 976 lattices. The lattices have a cyclic structure as in the case of 977 RLWE, however the NTRU problem can be stated as follows: given a 978 polynomial a(x), a small secret polynomial e(x) and ciphertext c(x) 979 find the secret e(x) from the ciphertext c(x) = a(x) * s(x) + e(x), 980 modulo some integer q, where s(x) is a small secret polynomial. In 981 the case of NTRU-Prime 216, the transmitted secret is the small 982 polynomial s(x) and e(x) is generated incidentally as a result of 983 streamlined data packing of the ciphertext. 985 NTRU EES743EP1 986 -------------- 987 The inventors of the first lattice cryptosystem by Silverman et al in 988 1996 have been developing their system ever since. Adoption by the 989 crypto community has been hampered by patents and a lack of security 990 proof. Whilst the polynomial ring of RLWE is truncated modulo (x^n + 991 1) where n is an integer power of 2, the operations of NTRU EES743EP1 992 [NTRU] are defined over the polynomial ring modulo (x^n - 1) where n 993 is 743, a prime integer. The integer modulus q is a power of 2, and 994 it is 2048 in NTRU EES743EP1. The QSKE public value is 1030 octets. 996 NTRU-Prime 216 997 -------------- 998 The authors, Bernstein et al [NTRUPRIME], of this recent variant of 999 NTRU set out to provide increased security in the light of possible 1000 vulnerabilities in the mathematical structure of rings used in NTRU 1001 and RLWE. Accordingly a Galois field, not a ring, is used in NTRU- 1002 Prime 216 with polynomials reduced modulo (x^p - x - 1), where p is a 1003 prime integer. Specifically, while the operations of NTRU EES743EP1 1004 are defined over the polynomial modulo (x^743 - 1), the operations of 1005 NTRU-Prime 216 [NTRUPRIME] are defined over polynomial modulo (x^743 1006 - x - 1). The integer modulus q is also chosen to be a prime to 1007 avoid any additional mathematical structure that may be potentially 1008 exploited. NTRU-Prime 216 has q = 7541. There is another parameter, 1009 an integer t, which defines the weight of one of the public key 1010 polynomials. The value of t is chosen to be 157 in this case so as 1011 to make cryptographic failure an impossibility. Cryptographic 1012 failure is theoretically possible in some ring based systems but 1013 usually these systems are designed so that this occurs with 1014 infinitesimal probability. 1016 NTRU-Prime 216 has been designed to minimize the public key size and 1017 key encapsulation data by using streamlined data packing and the 1018 resulting QSKE public value is 1200 octets long. The ciphertext 1019 includes a 256 bit key confirmation hash. The system achieves 1020 forward secrecy. It is a very conservative design achieving 216 bits 1021 pre-quantum security and at least 128 bits post-quantum security. 1022 Open source, constant time, side-channel-proof ciphersuites are 1023 publicly available. 1025 Authors' Addresses 1027 C. Tjhai 1028 Post-Quantum 1029 EMail: cjt@post-quantum.com 1031 M. Tomlinson 1032 Post-Quantum 1033 EMail: mt@post-quantum.com 1035 A. Cheng 1036 Post-Quantum 1037 EMail: ac@post-quantum.com 1038 G. Bartlett 1039 Cisco Systems 1040 EMail: grbartle@cisco.com