Internet Engineering Task Force C. Tjhai Internet-Draft M. Tomlinson Intended Status: Informational A. Cheng Expires: January 19, 2018 Post-Quantum G. Bartlett Cisco Systems July 18, 2017 Hybrid Quantum-Safe Key Exchange for Internet Key Exchange Protocol Version 2 (IKEv2) draft-tjhai-ipsecme-hybrid-qske-ikev2-00 Abstract This document describes the optional key-exchange payload of Internet Key Exchange Protocol Version 2 (IKEv2) that carries quantum-safe key exchange data. This optional payload is used in conjunction with the existing Diffie-Hellman key exchange to establish a quantum-safe shared secret between an initiator and a responder. The optional payload supports a number of quantum-safe key exchange schemes. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 21, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Tjhai et al. Expires January 19, 2018 [Page 1] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 2 1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Hybrid Quantum-Safe Key Exchange . . . . . . . . . . . . . . . 4 2.1. Quantum-Safe Group Transform Type . . . . . . . . . . . . 4 2.2. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . . 5 2.3. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . . . . 6 2.3.1. New Child SAs from the CREATE_CHILD_SA Exchange . . . 7 2.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . . 8 2.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange . 8 2.4. QSKE Payload Format . . . . . . . . . . . . . . . . . . . 9 3. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Threat Categories . . . . . . . . . . . . . . . . . . . . 10 3.2. Dealing with Fragmentation . . . . . . . . . . . . . . . . 11 3.3. Removal of the Diffie-Hellman exchange . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Quantum-safe Ciphers . . . . . . . . . . . . . . . . 16 Appendix A.1. Ring Learning With Errors . . . . . . . . . . . . . 16 Appendix A.2. NTRU Lattices . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction 1.1. Problem Description Internet Key Exchange Protocol (IKEv2) as specified in RFC 7296 [RFC7296] uses the Diffie-Hellman algorithm [DH] to establish a shared secret between an initiator and a responder. The security of the Diffie-Hellman algorithm relies on the difficulty to solve a discrete logarithm problem when the order of the group parameter is large enough. While solving such a problem remains difficult with current computing power, it is believed that general purpose quantum computers can easily crack this problem, implying that the security of IKEv2 is compromised. There are, however, a number of Tjhai et al. Expires January 19, 2018 [Page 2] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 cryptosystems that are conjectured to be resistant against quantum computer attack. 1.2. Proposed Extension This document describes a method to extend IKEv2, whilst maintaining backwards compatibility, to perform key exchange that is robust against quantum computers. The idea is to use an optional key exchange payload using a quantum-safe key exchange algorithm, in addition to the existing Diffie-Hellman key exchange. The secrets established from each key exchange are combined in a way such that should the quantum-safe secret not be present, the derived shared secret is equivalent to that of the standard IKEv2; on the other hand, a quantum-safe shared secret is obtained if both key exchange payloads are present. This extension also applies to key exchanges in IKE Security Associations (SAs) for Encapsulating Security Payload (ESP) [ESP] or Authentication Header (AH) [AH], i.e. Child SAs, in order to provide a stronger guarantee of forward security. The goals of this extension are: o to allow an additional key exchange using a quantum-safe algorithm to be used alongside the existing key exchange algorithm while we are transitioning to a post-quantum era; o to keep the modifications to IKEv2 to a minimum whilst maintaining compatibility with IKEv2; and o to provide a path to phase out the existing Diffie-Hellman key exchange in the future. It is expected that implementers of this specification are familiar with IKEv2 [RFC7296], and are knowledgeable about quantum-safe cryptosystems, in particular key exchange mechanisms and key encapsulation mechanisms instantiated with public-key encryption. The remainder of this document is organized as follows. Subsection 1.3 provides an overview of the terminology and the abbreviations used in this document. Section 2 specifies how quantum-safe key exchange is performed between two IKE peers and how keying materials are derived in both IKE and Child SAs. The rationale behind the approach of this extension is described in Section 3. Section 4 discusses security considerations. Section 5 describes IANA considerations for the name spaces introduced in this document. This is followed by a list of cited references and the authors' contact information. 1.3. Terminology Tjhai et al. Expires January 19, 2018 [Page 3] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [RFC2119]. In addition to using the terms defined in IKEv2 [RFC7296], this document uses the following list of abbreviations: KEM: It stands for key encapsulation mechanism whereby key material is transported using a public-key algorithm. QSKE: Denotes a quantum-safe key exchange payload, which is similar to Key Exchange (KE) payload. QSSS: Denotes a quantum-safe shared secret (QSSS) established from QSKEi and QSKEr payloads. This entity is similar to the Diffie-Hellman shared secret g^ir as defined in RFC 7296. Q-S Group: It stands for Quantum-Safe Group and it represents a quantum-safe cryptography algorithm for key exchange. Each group corresponds to an algorithm with a specific set of parameters. 2. Hybrid Quantum-Safe Key Exchange IKEv2 key exchange occurs in IKE_SA_INIT or CREATE_CHILD_SA message pair which contains various payloads for negotiating cryptographic algorithms, exchanging nonces, and performing a Diffie-Hellman shared secret exchange for an IKE SA or a Child SA. These payloads are chained together forming a linked-list and this flexible structure allows an additional key exchange payload, denoted QSKE, to be introduced. The additional key exchange uses algorithms that are currently considered to be resistant to quantum computer attacks. These algorithms are collectively referred to as quantum-safe algorithms in this document. 2.1. Quantum-Safe Group Transform Type In generating keying materials within IKEv2, both initiator and responder negotiate up to four cryptographic algorithms in the SA payload of an IKE_SA_INIT or a CREATE_CHILD_SA exchange. One of the negotiated algorithms is an ephemeral Diffie-Hellman algorithm, which is used for key-exchange. This negotiation is facilitated by the Transform Type 4 (Diffie-Hellman Group) where each Diffie-Hellman group is assigned a unique Transform ID. In order to enable a quantum-safe key exchange in IKEv2, the various quantum-safe algorithms MUST be negotiated between two IKEv2 peers. Transform Type #tba (Quantum-Safe Group) is used to facilitate this Tjhai et al. Expires January 19, 2018 [Page 4] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 negotiation. It is identical to Transform Type 4, except that the latter deals with various Diffie-Hellman groups only whereas the former handles quantum-safe algorithms only. Each quantum-safe algorithm is assigned a unique Transform ID. Whilst all the key exchange algorithms in Transform Type 4 are based on Diffie-Hellman, some of the algorithms in Transform Type #tba are Diffie-Hellman-like, and the rest of the algorithms use key- encapsulation-mechanism (KEM). In the case of KEM, the initiator randomly generates a random, ephemeral public and private key pair, and sends the public key to the responder in QSKEi payload. The responder generates a random entity, encrypts it using the received public key, and sends the encrypted quantity to the initiator in QSKEr payload. The initiator decrypts the encrypted payload using the private key. After this point of the exchange, both initiator and responder have the same random entity from which the quantum-safe shared secret (QSSS) is derived. The Transform Type #tba (Quantum-Safe Group) is defined as an optional type in IKE, AH and ESP protocols. This transform type MUST NOT exist if there is no Transform Type 4 in a proposal. For Transform Type #tba, the defined list of quantum-safe Transform IDs are listed below. Note that the values below are only current as of the publication date of this document. Readers should refer to [IKEV2IANA] for the latest values. Name Number Key exchange ------------------------------------------------------ RLWE 128 1 Diffie-Hellman-like NewHope 128 2 Diffie-Hellman-like NTRU EES743EP1 3 KEM NTRU-Prime 216 4 KEM 2.2. IKE_SA_INIT Exchange The IKE_SA_INIT request and response pairs negotiate cryptographic algorithms, exchange nonces and perform a key exchange for an IKE SA. Initiator Responder -------------------------------------------------------------- HDR, SAi1, KEi, [QSKEi,] Ni --> The initiator sends a QSKEi payload which contains parameters needed to established a quantum-safe shared secret. The QSKEi payload is marked as OPTIONAL so that it will be ignored by a responder who does not understand it. In this particular case, the responder will Tjhai et al. Expires January 19, 2018 [Page 5] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 respond with a set of payloads as defined in IKEv2 [RFC7296], and therefore maintaining compatibility with existing implementation. On the other hand, if the responder implements this specification, it will respond as follows: <-- HDR, SAr1, KEr, [QSKEr,] Nr, [CERTREQ] The QSKEr payload completes the quantum-safe shared secret between the initiator and responder. At this point in the negotiation, both initiator and responder is able to compute: o a shared Diffie-Hellman secret from KEi and KEr pair, and o a quantum-safe shared secret from QSKEi and QSKEr pair. Using these two shared secrets, each peer generates SKEYSEED, from which all keying materials for protection of the IKE SA are derived. The quantity SKEYSEED is computed as follows: SKEYSEED = prf(Ni | Nr, g^ir | QSSS) where prf, Ni, Nr, and g^ir are defined as in IKEv2 [RFC7296]. QSSS is represented as an octet string. The seven secrets derived from SKEYSEED, namely SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr, are generated as defined in IKEv2 [RFC7296]. Because the initiator sends a QSKE payload, which contains quantum- safe data, in the IKE_SA_INIT, it must guess a Q-S group that the responder will select from its list of proposed groups. If the initiator guesses incorrectly, the responder will respond with a Notify payload of type INVALID_QSKE_PAYLOAD indicating the selected Q-S group and the initiator MUST retry the IKE_SA_INIT with the corrected Q-S group. There are two octets of data associated with this notification, which contains the accepted Quantum-Safe Group Transform Type number in big endian order. As in the case of INVALID_KE_PAYLOAD, the initiator MUST again propose its full set of acceptable cryptographic suites because the rejection message was not authenticated, which may lead to any potential vulnerabilities exploitation. 2.3. CREATE_CHILD_SA Exchange The CREATE_CHILD_SA exchange is used to create new Child SAs and to rekey both IKE SAs and Child SAs. If the CREATE_CHILD_SA request contains a KE payload, it MAY also contain an optional QSKE payload Tjhai et al. Expires January 19, 2018 [Page 6] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 to enable quantum-safe forward secrecy for the Child SA. The keying material for the Child SA is a function of Sk_d established during the establishment of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA exchange, the Diffie-Hellman value, and the quantum- safe data (if QSKE payload is included in the CREATE_CHILD_SA exchange). If a CREATE_CHILD_SA request includes a QSKEi payload, at least one of the SA offers MUST include a Q-S group in one of its transform structures. The Q-S group MUST be an element of the group that the initiator expects the responder to accept. If the responder selects a different Q-S group, the responder MUST reject the request by sending INVALID_QSKE_PAYLOAD Notify payload. The responder's preferred Q-S group is indicated in this notify payload. In the case of a rejection, the initiator should retry with another CREATE_CHILD_SA request containing a Q-S group that was indicated in the INVALID_QSKE_PAYLOAD Notify payload. 2.3.1. New Child SAs from the CREATE_CHILD_SA Exchange The CREATED_CHILD_SA request and response pair to create a new Child SA is shown below: Initiator Responder -------------------------------------------------------------- HDR, SK {SA, Ni, [KEi,] [QSKEi,] TSi, TSr} --> <-- HDR, SK {SA, Nr, [KEr,] [QSKEr,] TSi, TSr} The initiator sends an encrypted request containing SA offer(s), a nonce, optional Diffie-Hellman and quantum-safe key exchange data and the proposed Traffic Selectors. The responder replies with an encrypted response containing the accepted SA offer, a nonce, a Diffie-Hellman value if KEi was included in the request and the expected Diffie-Hellman group was selected, a quantum-safe data if QSKEi was included in the request and the expected Q-S group was selected, and the accepted Traffic Selectors. The keying material of these CREATE_CHILD_SA exchanges that have both KE and QSKE payloads is defined as: KEYMAT = prf+(SK_d, QSSS (new) | g^ir (new) | Ni | Nr) where prf+, Sk_d, g^ir (new), Ni and Nr are defined in IKEv2 Tjhai et al. Expires January 19, 2018 [Page 7] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 [RFC7296], and QSSS (new) is the shared secret from the ephemeral quantum-safe key exchange. The QSSS quantity is represented as an octet string. 2.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange The CREATE_CHILD_SA request and response pair for rekeying an IKE SA is shown below: Initiator Responder -------------------------------------------------------------- HDR, SK{SA, Ni, KEi[, QSKEi]} --> <-- HDR, SK {SA, Nr, KEr[, QSKEr]} The initiator sends an encrypted request containing amongst other payloads, a KEi payload which carries a Diffie-Hellman value, and an OPTIONAL QSKEi payload which carries a quantum-safe data. The responder replies with an encrypted response containing a number of payloads. If the responder selects a Diffie-Hellman group that matches one of the proposed group(s), a KEr payload containing a Diffie-Hellman public value is replied in the encrypted response. If the request contains a QSKEr payload and the responder selects a Q-S group that matches one of the proposed group(s), a QSKEr payload containing quantum-safe data is sent in the reply. The quantity SKEYSEED for the new IKE SA is computed as follows: SKEYSEED = prf(SK_d (old), QSSS (new) | g^ir (new) | Ni | Nr) where prf, SK_d (old), g^ir (new), Ni and Nr are defined in IKEv2 [RFC7296], QSSS (new) is the shared secret from the ephemeral quantum-safe key exchange. The QSSS quantity is represented as an octet string. 2.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange The CREATE_CHILD_SA request and response pair for rekeying a Child SA is shown below: Initiator Responder -------------------------------------------------------------- HDR, SK {N(REKEY_SA), SA, Ni, [KEi,] [QSKEi,] TSi, TSr} --> Tjhai et al. Expires January 19, 2018 [Page 8] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 <-- HDR, SK {SA, Nr, [KEr,] [QSKEr,] TSi, TSr} Both KEi and QSKEi payloads are OPTIONAL. The KEi and QSKEi payloads, which are sent encrypted by the initiator, carry a Diffie- Hellman value and quantum-safe data respectively. If the CREATE_CHILD_SA request includes KEi and QSKEi payloads, provided that a Diffie-Hellman group and a Q-S group are present in the SA offers, the responder replies with an encrypted response containing both KEr and QSKEr payloads. The keying material computation of this exchange is the same as that defined in [Section 2.3.1]. 2.4. QSKE Payload Format The quantum-safe key exchange payload, denoted QSKE in this document, is used to exchange a quantum-safe shared secret between two IKE peers. The QSKE payload consists of the IKE generic payload header, a two-octet value denoting the Quantum-Safe Group number, and followed by the quantum-safe data itself. The format of the QSKE payload is shown below. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Quantum-Safe Group Num | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Quantum-Safe Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length of the quantum-safe data varies depending on the type of quantum-safe cipher. The content type of quantum-safe data is also dependent on the type of quantum-safe cipher. For quantum-safe ciphers that use Diffie-Hellman-like key exchange, the content of the quantum-safe data is the proposed/accepted cipher's public value. For ciphers that use KEM, the content is either a random public-key of the proposed quantum-safe cipher in the case of QSKEi payload, or the content is a ciphertext produced using the received public-key in the case of QSKEr payload. The Quantum-Safe Group Num identifies the quantum-safe cipher with which the quantum-safe data was computed. The Quantum-Safe Group Num Tjhai et al. Expires January 19, 2018 [Page 9] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 MUST match the Q-S group specified in a proposal in the SA payload sent in the same message. If the proposal in the SA payload does not specify a quantum-safe cipher, the QSKE payload MUST NOT be present. If the responder selects a Q-S group that does not match the proposed group, the quantum-safe key exchange MUST be rejected with a Notify payload of type INVALID_QSKE_PAYLOAD. The chosen Q-S group is indicated in the INVALID_QSKE_PAYLOAD Notify payload and the initiator can restart the exchange with that group. The payload type for the QSKE payload is TBA (TBA). 3. Design Rationale In general, the size of QSKE payload is larger than that of the KE counterpart and sending it in the IKE_SA_INIT may prevent peers from establishing IPSec Security Association (SA) due to fragmentation. While the fragmentation issue may be addressed by sending QSKE in the IKE_AUTH exchange, it is decided that QSKE should still be exchanged in the IKE_SA_INIT. The rationale behind this decision is discussed below. 3.1. Threat Categories The treats to the IKE exchange can be broken into two categories: 1. From current day until general purpose quantum computers are available. The addition of the QSKE allows the IKEv2 exchange to be secured against an adversary who captures all control plane (IKE) and data plane (ESP) traffic, with the intention of breaking the IKE exchange (when quantum computers become available) and subsequently being able to view the data plane traffic. The use of the QSKE in the IKE_SA_INIT results in the IKE SA becoming quantum secure against future attacks. 2. After general purpose quantum computers are available. Once general purpose quantum computers are available there are two types of attack: o Active attack Assuming that a general purpose quantum computer is available and an adversary can manipulate the IKE exchange in real time. The attacker can break Diffie-Hellman in real time, but not the QSKE. This results in the IKE_AUTH exchange being secure as the QSKE is included in the Tjhai et al. Expires January 19, 2018 [Page 10] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 derivation of key material used to secure the IKE_AUTH exchange. However, an active attacker who can sit between two hosts and impersonate each host can perform a man-in-the-middle (MitM) attack when the authentication method is not quantum secure. This includes any asymmetric authentication method and non-quantum computer resistant Extensible Authentication Protocol (EAP) authentication. For authentication methods which are quantum secure, such as using shared key message integrity code comprising a shared-secret with sufficient entropy (256 bits), this allows for the IKEv2 exchange to be secured against an active adversary when including the QSKE. o Passive attack As per the first category, the addition of the QSKE allows the IKEv2 exchange to be secured against an adversary who captures all control plane (IKE) and data plane (ESP) traffic, with the intention of breaking the IKE exchange. 3.2. Dealing with Fragmentation In some instances, the QSKE public value will be large enough to cause fragmentation to occur at the IP layer. In practice, there will be cases where IKE traffic fragmented at the IP layer will be dropped by network devices such as NAT/PAT gateways, Intrusion Prevention System (IPS), firewalls and proxies, that cannot handle IP fragments or are configured to block IP fragments. This blocked traffic will prevent the IKE session from being established. The issue with fragmentation can easily be avoided by moving the QSKE to the IKE_AUTH exchange and by employing IKEv2 Message Fragmentation [RFC7383]. The implication of this is that while all the Child SAs, which carry the data traffic, would be quantum secure, the IKE SA itself would not be, resulting in the disclosure of IKE identities and IPsec proxies. Furthermore by sending the QSKE in IKE_AUTH and not IKE_SA_INIT would allow an active attacker with a quantum computer to perform attacks against IKE such as forging an identity used for authentication, abuse of attributes sent in the CFG exchange, MitM attack, DoS, etc. It is believed that the trade off to deliver a quantum resistant IKE SA is of greater security benefit than the issues that could be encountered due to fragmentation at the IP layer. It is worth noting that encapsulating IKE traffic within TCP [IKETCPENCAP] is a simple method to prevent IKE_SA_INIT traffic being fragmented at the IP layer. Tjhai et al. Expires January 19, 2018 [Page 11] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 The following table gives an idea of the common size of the QSKE payload in the proposed schemes. Scheme QSKE size (octets) ------------------------------------- RLWE 128 4096 NewHope 128 1792 NTRU EES743EP1 1030 NTRU-Prime 216 1200 It is evident that both NewHope 128 and RLWE 128 will naturally increase an IP Maximum Transmission Unit (MTU) to be larger than 1500 octets which is common for most Internet traffic, resulting in the IKE_SA_INIT being fragmented at the IP layer. 3.3. Removal of the Diffie-Hellman exchange The IKE_SA_INIT exchange currently mandates the use of the Diffie- Hellman. As the Diffie-Hellman exchange is not quantum secure and the QSKE exchange is quantum secure, the addition of the QSKE can be thought of making the Diffie-Hellman redundant. This draft does not advise removing the use of Diffie-Hellman, though future implementations that have migrated to using QSKE could remove the requirement to send the Diffie-Hellman exchange with the QSKE providing the same functionality. Sending the QSKE in the IKE_SA_INIT allows for a simple transition to only using QSKE should the need to remove the Diffie-Hellman exchange occur. 4. Security Considerations The key length of the Encryption Algorithm (Transform Type 1), the Pseudorandom Function (Transform Type 2) and the Integrity Algorithm (Transform Type 3), all have to be of sufficient length to prevent attacks using Grover's algorithm [GROVER]. In order to use the extension proposed in this document, the key lengths of these transforms SHALL be at least 256 bits long in order to prevent any quantum attacks from succeeding. Accordingly the post-quantum security level achieved is at least 128 bits. The quantities SKEYSEED and KEYMAT are calculated from shared secrets, g^ir and QSSS, using an algorithm defined in Transform Type 2. While a quantum attacker may learn the value of g^ir, the quantity QSSS ensures that neither SKEYSEED nor KEYMAT is compromised. This assumes that the algorithm defined in the Transform Type 2 is quantum-safe. Because some quantum-safe public values are in the order of several Tjhai et al. Expires January 19, 2018 [Page 12] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 KB, a IKEv2 message that contains such a QSKE payload will exceed the path Maximum Transmission Unit (MTU) and the message may be fragmented at the IP level. This presents the possibility of an attack vector that relies on IP fragmentation. One such attack vector is to mount a denial of service by swamping a receiver with IP fragments [DOSUDPPROT]. This issue could be mitigated by employing TCP encapsulation [IKETCPENCAP]. The authenticity of the SAs established under IKEv2 is protected using a pre-shared key, RSA, DSS, or ECDSA algorithms. Whilst the pre-shared key option, provided the key is long enough, is quantum- safe, the other algorithms are not. Moreover, in implementations where scalability is a requirement, the pre-shared key method may not be suitable. Quantum-safe authenticity may be provided by using a quantum-safe digital signature and several quantum-safe digital signature methods are being explored by IETF. For example the hash based method, XMSS has the status of an Internet Draft, see [XMSS]. Currently, quantum-safe authentication methods are not specified in this document, but are planned to be incorporated in due course. It should be noted that the purpose of quantum-safe algorithms is to prevent attacks, mounted in the future, from succeeding. The current threat is that encrypted sessions may be subject to eavesdropping and archived with decryption by quantum computers taking place at some point in the future. Until quantum computers become available there is no point in attacking the authenticity of a connection because there are no possibilities for exploitation. These only occur at the time of the connection, for example by mounting a MitM attack. Consequently there is not such a pressing need for quantum-safe authenticity. The use of the QSKE provides an method for malicious parties to send IKE_SA_INIT initiator messages containing QSKE of type KEM and with random values. As the standard behavior is for the responder to generate a random entity, encrypt it using the received public key (which would be a random value), and sends the encrypted quantity to the initiator in QSKEr payload. This allows for a simply method for malicious parties to cause a VPN gateway to perform excessive processing. To mitigate against this threat, implementations can make use of the COOKIE notification as defined in [RFC7296], to mitigate spoofed traffic and [RFC8019] to minimize the impact from hosts who use their own IP address. 5. IANA Considerations This document defines a new IANA registry for IKEv2 Transform Types. Tjhai et al. Expires January 19, 2018 [Page 13] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 Trans. Description Type Used In ----------------------------------------------------------- Quantum-Safe Group (Q-S) tba Optional in IKE, AH & ESP A number of Transform IDs of the Q-S group Transform Type are also defined. The initial values are listed below: Name Value ------------------------------ RLWE 128 1 NewHope 128 2 NTRU EES743EP1 3 NTRU-Prime 216 4 In order to transport quantum-safe data to establish a quantum-safe SA, this extension registers a new key exchange payload in the IKEv2 Payload Types of the IANA registry: Description Notation Value --------------------------------- QSKE Payload QSKE tba This extension also specifies a new error type in the IKEv2 Notify Message Types - Error Types of the IANA registry: Error Type Value ------------------------------ INVALID_QSKE_PAYLOAD tba 6. References [ADPS] Alkim, E., Ducas, L., Poppelmann, T., and Schwabe, P., "Post-quantum Key Exchange - a New Hope", 25th USENIX Security Symposium, pp. 327-343, 2016. [AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005, . [BCNS15] Bos, J., Costello, C., Naehrig, M., and Stebila, D., "Post-quantum Key Exchange for the TLS Protocol from the Ring Learning with Errors Problem", IEEE Symposium on Security and Privacy, pp. 553-570, 2015. [DH] Diffie, W., and Hellman, M., "New Directions in Cryptography", IEEE Transactions on Information Theory, Tjhai et al. Expires January 19, 2018 [Page 14] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 V.IT-22 n. 6, June 1977. [DOSUDPPROT] Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS protection for UDP-based protocols", ACM Conference on Computer and Communications Security, October 2003. [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005, . [GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for Database Search", Proc. of the Twenty-Eighth Annual ACM Symposium on the Theory of Computing (STOC 1996), 1996 [IKETCPENCAP] Pauly, T., Touati, S., and Mantha, R., "TCP Encapsulation of IKE and IPsec Packets", draft RFC, May 2017, . [IKEV2IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", . [LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., Green, M., Halderman, J., Heninger, N., Springall, D., Thome, E., Valenta, L., VanderSloot, B., Wustrow, E., Beguelin, S., and Zimmermann, P., "Imperfect forward secrecy: How Diffie-Hellman fails in practice", Proc. 22rd ACM SIGSAC Conference on Computer and Communications Security, pp. 5-17, 2015. [NTRU] Hoffstein, J., Pipher, J., and Silverman, J., "NTRU: A Ring-Based Public Key Cryptosystem", Lecture Notes in Computer Science, pp. 267-288, 1998. [NTRUPRIME] Bernstein, D., Chuengsatiansup, C., Lange, T., and van Vredendaal, C., "NTRU Prime", IACR Cryptology ePrint Archive: Report 2016/461, 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and Kivinen, T., "Internet Key Exchange Protocol Version 2 Tjhai et al. Expires January 19, 2018 [Page 15] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 (IKEv2)", RFC 7296, October 2014. [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, November 2014. [RFC8019] Nir, Y., Smyslov, V., "Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks", RFC 8019, November 2016. [XMSS] Huelsing, A., Butin, D., Gazdag, S., and Mohaisen, A., "XMSS: Extended Hash-Based Signatures", Crypto Forum Research Group Internet Draft, 2017 Appendix A. Quantum-safe Ciphers Each of the specific quantum-safe ciphers is assigned a unique Transform ID. All of the selected quantum-safe ciphers are based on lattice construction. Specifically the ciphers fall into the categories of Ring Learning With Errors, NTRU and Streamlined NTRU Prime. In each case the selected parameters are chosen so as to achieve at least 128 bits of post-quantum security. Appendix A.1. Ring Learning With Errors Ring Learning with Errors is a cryptographic primitive that relies on the worst-case hardness of a shortest vector problem in ideal lattices. It is commonly abbreviated as RLWE. The security parameters are given by an integer n which is a power of 2, a prime integer q, an array of n coefficients denoted by {a} and a standard deviation sigma along with the type of error distribution X. Note that each coefficient of {a} is less than the prime q and is sampled from distribution X. Let a(x) be a polynomial, whose coefficients are given by {a}, the RLWE problem can be stated as follows: given polynomials a(x), b(x) and a small polynomial e(x), find the secret s(x) from the relationship a(x) * s(x) + b(x) = e(x) modulo q. RLWE 128 -------- This set of parameters follows the system described by Bos et al [BCNS15]. Using a fixed coefficient array {a} in this way may result in security vulnerabilities such as "all-for-the-price-of-one" precomputation attacks such as the Logjam attack on the classical Diffie-Hellman key exchange [LOGJAM]. As has been pointed out since, this is straightforwardly solved by the coefficient array {a} being generated on-the-fly for each key exchange from a seed value shared Tjhai et al. Expires January 19, 2018 [Page 16] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 by the initiator and responder. The fixed coefficient array {a} is also avoided in similar fashion in NewHope 128 (see below). The set of parameters that is proposed by Bos et al is given as follows: n = 1024 q = 2^32 -1 sigma = 8/sqrt(2 * PI) X = discrete Gaussian {a} = 29FE0191, DD1A457D, 3534EE4B, 6450ED74, BBFE9F64, 92BF0F31, 8DCF8995, 4C5E30D0, 9E2ED04D, 8C18FE0B, 1A70F2E7, 2625CD93, 0065DA14, 6E009722, E6A70E8B, AEF6EF56, 8C6C06AF, 9E59E953, 4995F67B, E918EE9D, 8B4F41A7, 0D811041, F5FE6458, 3C02B584, CBCFC8FD, 5A01F116, 73408361, 44D3A098, BBDEECF6, 90E09082, F8538BA4, F9600091, D8D30FEF, 56201487, ACB2159D, 38F47F77, ED7A864F, 8FC785CA, 7CBD6108, 3CA577DE, FF44CCC2, A1385A79, 5C88E3AD, 177C46A9, DA4A4DD8, 2AA3594F, A4A5E629, 47CA6F6E, B2DF1BC6, 6841B78E, 0823F5A8, A18C7D52, 7634A0D1, DA1751BA, 18B9D25D, 5B2643BC, ACC6975D, 48E786F4, 05E3ED4E, 4DC86568, 3F5C5F99, 585DBFD7, EF6E0715, 7D36B823, 12D872CD, D7B78F27, DD672BF5, 2DC7C7EB, A3033801, 50E48348, 9162A260, 0BE8F15B, ABB563EC, 06624C5A, 812BF7BC, 8637AC35, F44504F3, FF8577AB, 4A0161B0, 000AEB0E, 311204AF, 2A76831B, 4D903F3A, 97204FA9, 9EB524E3, 1757AFAC, BA369FEC, CD8F198D, 6B33C246, 51C13FCE, B58ACC4E, 39ACF8DA, 7BB7EBF7, EDC1449D, C7B47FDB, 9C39148D, 4E688D7B, FAD0C2C2, 296CE85C, 6045C89C, 6441C0C6, 50C7C83A, C11764DD, 58D7EEA2, E57B9D0E, 4E142770, B8BFBB59, E143EBAA, FF60C855, 238727F0, E35B4A5B, 8F96940B, 4498A6BA, 5911093A, 394DD002, 521B00D2, 140BDAF9, EAB67207, 21E631A6, A04AADA9, A96A9843, 4B44CC9B, E4D24C33, C7E7AE78, E45A6C72, CBE61D3C, CE5A4869, 10442A52, DB11F194, 39FC415D, 7E7BDB76, AE9EFA22, 25F4F262, 472DD0A7, 42EBD7A0, E8038ECE, D3DB002A, 8416D2EC, DF88C989, 7FEA22D5, C7A3F6FE, 37409982, F45B75E2, 9A4AC289, 90406FD6, EA1C74A5, 5777B39F, D07F1FA3, CE6EDA0D, D150ECFB, BEFF71BA, 50129EFC, 51CE65B9, B9FB0AB8, 770C59CB, 11F2354F, 8623D4BB, D6FCAFD6, B2B1697C, 0D7067E2, 2BA5AFB9, D369C585, 5B5E156C, D8C81E6E, 80CFDF16, F6F441EB, C173BAF5, 78099E3A, D38F027B, 4AC8D518, 8D0108A1, E442B0F1, 56F9EA3C, D0D6BBCA, 4E17DCB4, 69BF743B, 0CCE779F, D5E59851, 63861EA2, B1CB22C1, BBFD2ACE, DDA390D1, EDF1059F, 04F80F89, B13AF849, 58C66009, E0D781C0, 588DC348, A305669D, 0D7AF67F, 32BC3C38, D725EFBA, DC3D9434, 22BD7ED8, 2DFD2926, 4BDEAD3A, B2D5ECE6, 16B05C99, FEEC7104, F6CAC918, 0944C774, CE00633B, C59DA01A, 41E8E924, 335DF501, 3049E8EE, 5B4B8AAC, C962FC91, D6BB22B3, 0AC870EB, C3D99400, A0CEAC28, AF07DE1E, 831C2824, 258C5DDC, 779417E6, 41CB33D0, 4E51076A, D1DB6038, 9E0B1C41, A9A1F90D, F27E7705, 75892711, 5D9F1175, 85CC508B, 5CA415BE, 1858C792, FB18632F, Tjhai et al. Expires January 19, 2018 [Page 17] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 C94111EB, 937C0D28, C2A09970, 386209D9, BBDD9787, 2473F53A, EF7E7637, CFC8630B, 2BA3B7F8, 3C0047AD, 10D76FF7, B1D9414D, CEB7B902, A5B543F5, 2E484905, E0233C10, D061A1F8, CED0A901, AC373CAC, 04281F37, 3609797F, DB80964D, 7B49A74F, 7699656F, 0DCEC4BC, 0EC49C2D, F1573A4E, A3708464, 9A1E89F0, 6B26DEB6, 2329FA10, CA4F2BFF, 9E012C8E, 788C1DFD, 2C758156, 2774C544, 150A1F7D, 50156D6E, 7B675DE1, 5D634703, A7CEB801, 92733DAB, B213C00B, 304A65B1, 8856CF8E, 7FF7DD67, D0912293, 30064297, 663D051D, 01BC31B4, 2B1700BD, 39D7D18F, 1EAD5C95, 6FB9CD8B, A09993A6, B42071C0, 3C1F2195, 7FDF4CF8, C7565A7E, 64703D34, 14B250EF, 2FA338D2, AEE576DC, 6CCED41D, 612D0913, D0680733, 8B4DBE8A, 6FFEA3D0, 46197CA2, A77F916F, FA5D7BD6, 01E22AEB, 18E462DD, 4EC9B937, DE753212, 05113C94, 7786FBD4, FB379F71, 756CF595, EAADCFAB, BBD74C2E, 1F234AC9, 85E28AEB, 329F7878, D48FDE09, 47A60D0A, AE95163F, 72E70995, 27F9FCBF, BDCFCC41, 334BC498, EE7931A1, DFA6AEF4, 1EC5E1BF, 6221870F, CD54AE13, 7B56EF58, 4847B490, 31640CD3, 10940E14, 556CC334, C9E9B521, 499611FF, BEC8D592, 44A7DCB7, 4AC2EABD, 7D387357, 1B76D4B6, 2EACE8C9, 52B2D2A4, 0C1F2A64, 50EF2B9A, 3B23F4F4, 8DDE415E, F6B92D2D, 9DB0F840, E18F309D, 737B7733, F9F563C5, 3C5D4AEE, 8136B0AF, C5AC5550, 6E93DEF9, 946BCCEC, 5163A273, B5C72175, 4919EFBD, 222E9B68, 6E43D8EE, AA039B23, 913FD80D, 42206F18, 5552C01F, 35B1136D, FDC18279, 5946202B, FAAE3A37, 4C764C88, 78075D9B, 844C8BA0, CC33419E, 4B0832F6, 10D15E89, EE0DD05A, 27432AF3, E12CECA6, 60A231B3, F81F258E, E0BA44D7, 144F471B, B4C8451E, 3705395C, E8A69794, 3C23F27E, 186D2FBA, 3DAED36B, F04DEFF1, 0CFA7BDD, FEE45A4F, 5E9A4684, 98438C69, 5F1D921B, 7E43FD86, BD0CF049, 28F47D38, 7DF38246, 8EED8923, E524E7FC, 089BEC03, 15E3DE77, 78E8AE28, CB79A298, 9F604E2B, 3C6428F7, DCDEABF3, 33BAF60A, BF801273, 247B0C3E, E74A8192, B45AC81D, FC0D2ABE, F17E99F5, 412BD1C1, 75DF4247, A90FC3C0, B2A99C0E, 0D3999D7, D04543BA, 0FBC28A1, EF68C7EF, 64327F30, F11ECDBE, 4DBD312C, D71CE03A, AEFDAD34, E1CC7315, 797A865C, B9F1B1EB, F7E68DFA, 816685B4, 9F38D44B, 366911C8, 756A7336, 696B8261, C2FA21D2, 75085BF3, 2E5402B4, 75E6E744, EAD80B0C, 4E689F68, 7A9452C6, A5E1958A, 4B2B0A24, 97E0165E, A4539B68, F87A3096, 6543CA9D, 92A8D398, A7D7FDB4, 1EA966B3, 75B50372, 4C63A778, 34E8E033, 87C60F82, FC47303B, 8469AB86, 2DAADA50, CFBB663F, 711C9C41, E6C1C423, 8751BAA9, 861EC777, 31BCCCE1, C1333271, 06864BEE, 41B50595, D2267D30, 878BA5C5, 65267F56, 2118FB18, A6DDD3DE, 8D309B98, 68928CB2, FAE967DC, 3CEC52D0, 9CA8404B, AADD68A8, 3AC6B1DF, D53D67EA, 95C8D163, B5F03F1D, 3A4C28A7, E3C4B709, B8EB7C65, E76B42A3, 25E5A217, 6B6DD2B4, BEFC5DF4, 9ACA5758, C17F14D3, B224A9D3, DE1A7C8F, 1382911B, 627A2FB9, C66AE36E, 02CC60EF, C6800B20, 7A583C77, E1CECEE8, CA0001B4, 6A14CF16, EF45DD21, 64CAA7D5, FF3F1D95, D328C67E, C85868B1, 7FBF3FEB, 13D68388, 25373DD9, 8DE47EFB, 47912F26, 65515942, C5ED711D, 6A368929, A2405C50, FFA9D6EB, ED39A0D4, E456B8B5, Tjhai et al. Expires January 19, 2018 [Page 18] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 53283330, 7837FD52, 6EE46629, CAFC9D63, B781B08F, DD61D834, FB9ACF09, EDA4444A, BB6AA57F, AED2385C, 22C9474D, 36E90167, E6DF6150, F1B0DA3B, C3F6800E, 966302E0, 7DB1F627, F9632186, B4933075, 81C5C817, 878CA140, 4EDE8FED, 1AF347C1, FDEB72BA, 2DA7FF9A, B9BA3638, 2BB883F1, 474D1417, C2F474A4, 1E2CF9F3, 231CB6B0, 7E574B53, EDA8E1DA, E1ACB7BB, D1E354A6, 7C32B431, 8189991B, 25F9376A, 3FFA8782, CD9038F1, 119EDBD1, 5C571840, 3DCA350F, 83923909, 9DC3CF55, 94D79DD0, D683DE2B, ECF4316A, 0FFF48D4, 5D8076ED, 12B42C97, 2284CDB4, CB245554, 3025B4D9, B0075F35, 43A3802E, 18332B4D, 056C4467, C597E3F7, 3F0EAF9D, F48EBB9F, 92F62731, BDB76296, 516D4466, 226102B3, 15E38046, A683C4E0, 6C0D1962, E20CB6CA, C90C1D70, D0FF8692, D1419690, 2D6F1081, 34782E5E, AE092CD5, 90C99193, E97C0405, EAE201DA, 631FB5AC, 279A2821, DF47BA5B, FBE587E2, 6810AD2D, C63E94BD, 9AF36B42, F14F0855, 946CE350, 7E3320E0, 34130DFF, 8C57C413, AB0723B2, F514C743, 63694BA3, 5665D23D, 6292C0B5, 9D768323, 2F8E447C, B99A00FB, 6F8E5970, 69B3BB45, 59253E02, 1C518A02, DD7C1232, C6416C38, 77E10340, CF6BEB9A, 006F9239, 0E99B50F, 863AD247, 75F0451A, 096E9094, E0C2B357, 7CC81E15, 222759D4, EE5BCFD0, 050F829B, 723B8FA9, 76143C55, 3B455EAF, C2683EFD, EE7874B4, 9BCE92F7, 6EED7461, 8E93898F, A4EBE1D0, FA4F019F, 1B0AD6DA, A39CDE2F, 27002B33, 830D478D, 3EEA937E, 572E7DA3, 4BFFA4D1, 5E53DB0B, 708D21EE, B003E23B, 12ED0756, 53CA0412, 73237D35, 438EC16B, 295177B8, C85F4EE6, B67FD3B4, 5221BC81, D84E3094, 18C84200, 855E0795, 37BEC004, DF9FAFC9, 60BEB6CD, 8645F0C5, B1D2F1C3, ECDC4AE3, 424D17F1, 8429238C, 6155EAAB, A17BEE21, 218D3637, 88A462CC, 8A1A031E, 3F671EA5, 9FA08639, FF4A0F8E, 34167A7D, 1A817F54, 3215F21E, 412DD498, 57B633E7, E8A2431F, 397BD699, 5A155288, BB3538E8, A49806D2, 49438A07, 24963568, 40414C26, E45C08D4, 61D2435B, 2F36AEDE, 6580370C, 02A56A5E, 53B18017, AF2C83FC, F4C83871, D9E5DDC3, 17B90B01, ED4A0904, FA6DA26B, 35D9840D, A0C505E4, 3396D0B5, EC66B509, C190E41C, 2F0CE5CF, 419C3E94, 220D42CA, 2F611F4F, 47906734, 8C2CDB17, D8658F1C, 2F6745CD, 543D0D4F, 818F0469, 380FFDAE, F5DD91E2, AD25E46A, E7039205, A9F47165, B2114C12, CF7F626F, 54D2C9FF, E4736A36, 16DB09FC, E2B787BB, 9631709A, 72629F66, 819EBA08, 7F5D73F3, A0B0B91C, FEDFBA71, 252F14EE, F26F8FA2, 92805F94, 43650F7F, 3051124F, 72CA8EAD, 21973E34, A5B70509, B36A41CC, C52EDE5F, F706A24E, 8AAF9F92, ADF6D99A, 23746D73, 1DA39F70, 9660FC8F, A0A8CFEB, 83D5EFCA, 0AA4A72F, EEF1B2DE, 00CFCC66, 8A145369, 6376CEDA, A3262E2E, 3367BBA8, 01488C32, 5561A2AD, 40821BF2, F0C89F61, C4FAA6B3, D843377A, 67A76555, E8D9F1CE, 943034FF, 2BD468BD, A514D935, 50CDB19D, A09C7E9E, 6FEBEC30, B1B36CF7, CD7A30BC, 36C6FE0A, 2DF52C45, 45C9957F, 65076A79, BF783DEE, 718D37F0, 098F9117, 9A70C430, 80EB1A53, 9F2505B1, 48D10D98, B8D781E9, F2376133, ECF25B98, 5A3B0E18, 2F623537, 9F0E34A4, F1027EB6, F9B16022, BA3FEC59, EF7226FD, 9F3058AA, BB51DE0E, D5435EA0, 8A6479D5, 077708B8, 9634876A, Tjhai et al. Expires January 19, 2018 [Page 19] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 069A260A, 168D9E6A, 9FD18E94, 8A7ACD53, 8E5A5869, 1B6F35FD, A968913B, C72F076B, 7DDA354C, 25B0297C, D07219D5, A66862BA, 87E8EE67, FA28809B, 55762443, 31EF4956, F4F4A511, 9A9378CB, 42ABDBDE, 7AA484B7, E8EC22ED, CADDEF61, 9D18538A, A81B923E, 9C32F92A, 6D278E58, 4CDFC716, AB64814F, F832BF1A, E2C1A36B, 20675610, E78D855A, 38332C3D, 5AE0EAD9, 2E23F22D, 3C8683C5, A351AF89, 54720D3B, ABC6E51F, 89330C8E, 600D5650, 197EA0C6, 7D502A5D, 3A536EA7, 7DF71F32, 456FE645, 3EF5E7A2, 6664BCAF, A9D074C2, E9D9E478, 1AE9AB77, FECE7160, C618EEEC, 771B0026, 2B54F43C, 145DA102, 1B3D7949, BB6E2D9D, DB8FDC4A, 25397EBA, 9228A6E9, 56B4C69D, 337B943C, E35B716C, F7FE89A1, 023AC20D, 033165C8, 9F13B130, C1BAFB1D, A2C42C8C, 58E4D431, E10741E6, 2547589A, 8D9EF7BD, 7E322280, F49FDDC2, BE21A094, A061178A, 34D9F13B, 694D652F, 05084A2A, 2767B991, E8536AB4, EBFADF6F, F4C8DFAC, D9967CCA, E04BCF3F, 232B3460, 9FF6E88A, 6DF3A2B0, 0FE10E99, 7B059283, 067BFB57, 8DDA26B0, B7D6652F, 85705248, 0826240C, 5DF7F52E, 47973463, B9C22D37, 9BEB265D, 493AB6FD, 10C0FB07, 947C102A, 5FEC0608, 140E07AE, 8B330F43, 9364A649, C9AD63EF, BE4B2475, 1A09AC77, 9E40A4B0, BA9C23E7, 7F4A798D, E2C52D66, A26EE9E0, 8C79DCE7, DD7F1C3D, 6AE83B20, 073DBA03, B1844D97, 16D7ED6E, 5E0DE0B1, A497D717, FA507AA2, C332649B, 21419E15, 384D9CCC, 8B915A8B, BA328FD5, F99E8016, 545725EC, ED9840ED, 71E5D78A, 21862496, 6F858B6C, F3736AE2, 8979FC2B, 5C8122D0, 0A20EB5A, 2278AA6E, 55275E74, 22D57650, E5FFDC96, 6BA86E10, 4EC5BFCC, 05AFA305, FB7FD007, 726EA097, F6A349C4, CB2F71E4, 08DD80BA, 892D0E23, BD2E0A55, 40AC0CD3, BFAF5688, 6E40A6A5, 6DA1BBE0, 969557A9, FB88629B, 11F845C4, 5FC91C6F, 1B0C7E79, D6946953, 27A164A0, 55D20869, 29A2182D, 406AA963, 74F40C59, 56A90570, 535AC9C6, 9521EF76, BA38759B, CD6EF76E, F2181DB9, 7BE78DA6, F88E4115, ABA7E166, F60DC9B3, FECA1EF3, 43DF196A, CC4FC9DD, 428A8961, CF6B4560, 87B30B57, 20E7BAC5, BFBDCCDF, F7D3F6BB, 7FC311C8, 2C7835B5, A24F6821, 6A38454C, 460E42FD, 2B6BA832, C7068C72, 28CDCE59, AE82A0B4, 25F39572, 9B6C7758, E0FE9EBA, A8F03EE1, D70B928E, 95E529D7, DD91DB86, F912BA8C, 7F478A6A, 1F017850, 5A717E10, DAC243F9, D235F314, 4F80AAE6, A46364D8, A1E3A9E9, 495FEFB1, B9058508, 23A20999, 73D18118, CA3EEE2A, 34E1C7E2, AADBADBD. The public key size of RLWE 128 is 4096 octets and it provides 128- bit post-quantum security, although it does not provide forward secrecy due to the way coefficient array {a} is generated. A set of open source ciphersuites has been implemented and included in OpenSSL v1.0.1f and may be found within the libcrypto module. The authors anticipate RLWE being incorporated into TLS with the RLWE 128 ciphersuites being compatible with TLS 1.3. Moreover, the ciphersuites are constant time, and therefore are not vulnerable to possible side channel attacks. Tjhai et al. Expires January 19, 2018 [Page 20] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 NewHope 128 ----------- This is a variation on the ring learning with errors cipher by Alkim et al [ADPS] who set out in their solution to make improvements to RLWE 128. Their main improvements are to use a random coefficient array {a} for each key exchange and to reduce the size of key exchanges by using a 14-bit modulus instead of a 32-bit modulus. Additionally they relax the requirement for the error distribution to be discrete Gaussian and substitute the easier to generate Binomial distribution and provide a security justification. The set of parameters proposed by Alkim et al is given as follows: n = 1024 q = 12289 sigma = sqrt(8) X = Binomial This cipher provides 128-bit post-quantum security and has a public key size of 1792 octets. It features forward secrecy. Open source, constant time, side-channel-proof, ciphersuites are publically available. Appendix A.2. NTRU Lattices NTRU lattices are another variant of cryptosystems based on integer lattices. The lattices have a cyclic structure as in the case of RLWE, however the NTRU problem can be stated as follows: given a polynomial a(x), a small secret polynomial e(x) and ciphertext c(x) find the secret e(x) from the ciphertext c(x) = a(x) * s(x) + e(x), modulo some integer q, where s(x) is a small secret polynomial. In the case of NTRU-Prime 216, the transmitted secret is the small polynomial s(x) and e(x) is generated incidentally as a result of streamlined data packing of the ciphertext. NTRU EES743EP1 -------------- The inventors of the first lattice cryptosystem by Silverman et al in 1996 have been developing their system ever since. Adoption by the crypto community has been hampered by patents and a lack of security proof. Whilst the polynomial ring of RLWE is truncated modulo (x^n + 1) where n is an integer power of 2, the operations of NTRU EES743EP1 [NTRU] are defined over the polynomial ring modulo (x^n - 1) where n is 743, a prime integer. The integer modulus q is a power of 2, and it is 2048 in NTRU EES743EP1. The QSKE public value is 1030 octets. NTRU-Prime 216 -------------- The authors, Bernstein et al [NTRUPRIME], of this recent variant of Tjhai et al. Expires January 19, 2018 [Page 21] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 NTRU set out to provide increased security in the light of possible vulnerabilities in the mathematical structure of rings used in NTRU and RLWE. Accordingly a Galois field, not a ring, is used in NTRU- Prime 216 with polynomials reduced modulo (x^p - x - 1), where p is a prime integer. Specifically, while the operations of NTRU EES743EP1 are defined over the polynomial modulo (x^743 - 1), the operations of NTRU-Prime 216 [NTRUPRIME] are defined over polynomial modulo (x^743 - x - 1). The integer modulus q is also chosen to be a prime to avoid any additional mathematical structure that may be potentially exploited. NTRU-Prime 216 has q = 7541. There is another parameter, an integer t, which defines the weight of one of the public key polynomials. The value of t is chosen to be 157 in this case so as to make cryptographic failure an impossibility. Cryptographic failure is theoretically possible in some ring based systems but usually these systems are designed so that this occurs with infinitesimal probability. NTRU-Prime 216 has been designed to minimize the public key size and key encapsulation data by using streamlined data packing and the resulting QSKE public value is 1200 octets long. The ciphertext includes a 256 bit key confirmation hash. The system achieves forward secrecy. It is a very conservative design achieving 216 bits pre-quantum security and at least 128 bits post-quantum security. Open source, constant time, side-channel-proof ciphersuites are publicly available. Authors' Addresses C. Tjhai Post-Quantum EMail: cjt@post-quantum.com M. Tomlinson Post-Quantum EMail: mt@post-quantum.com A. Cheng Post-Quantum EMail: ac@post-quantum.com Tjhai et al. Expires January 19, 2018 [Page 22] Internet-Draft Hybrid QSKE for IKEv2 July 18, 2017 G. Bartlett Cisco Systems EMail: grbartle@cisco.com Tjhai et al. Expires January 19, 2018 [Page 23]