[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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)


   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

1.3.  Terminology

Tjhai et al.            Expires January 19, 2018                [Page 3]

Internet-Draft           Hybrid QSKE for IKEv2             July 18, 2017

   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

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

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

   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

   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

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

          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

             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

   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

      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

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, <http://www.rfc-editor.org/info/rfc4302>.

   [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.

              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, <http://www.rfc-

   [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

              Pauly, T., Touati, S., and Mantha, R., "TCP Encapsulation
              of IKE and IPsec Packets", draft RFC, May 2017,

              IANA, "Internet Key Exchange Version 2 (IKEv2)
              Parameters", <http://www.iana.org/assignments/ikev2-

   [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.

              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

   [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

      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

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.

   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
   EMail: cjt@post-quantum.com

   M. Tomlinson
   EMail: mt@post-quantum.com

   A. Cheng
   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]

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/