Subject: [IPsec] Proposed method to achieve quantum resistant IKEv2

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Thu, 3 Aug 2017 11:57:16 +0000

Hi

After listening to the Prague meeting Dan Harkins raised the point that the Quantum Resistant IKEv2 implementation should protect passive attacks, where traffic that traffic that is sent and is captured today should be resilient to an adversary with a quantum computer in the future. But the Quantum Resistant IKEv2 does not have to protect against an adversary with a quantum computer in the future who can perform an active attack.

Someone else (can’t remember who) suggested the quantum resistant ‘blob’ be sent in IKE_AUTH as it will be large and probably fragmentation. Obviously for this the natural choice is to use the IKEv2 Fragmentation mechanism defined in RFC7383.

A few weeks ago I developed a method to send the quantum resistant ‘blob’ in IKE_SA_INIT, this is to amend https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske-ikev2-00. After hearing the discussion described above I was going to park this idea and never speak of it again, however before I do this I’d like to share with the group for comments. 

I personally feel this is an elegant and simple method to achieve sending one or more quantum resistant ‘blobs’. The main benefits being;

1.      The IKE_AUTH exchange is protected using the quantum secure algorithms. So all attributes within the IKE exchange are protected against passive attacks, which wouldn’t be the case should the quantum resistant ‘blob’ be sent in IKE_AUTH.

2.      This allows for a quantum resistant authentication method to be introduced into IKE_AUTH in the future, therefore protecting against active attacks with a quantum computer should this occur.

3.      A simple method to fragment the quantum secure key exchange data in IKE_SA_INIT is included, however this is not mandatory. From personal experience I’ve seen a few cases where RFC 7383 fragmentation is required today, however the vast majority of customer implementations do not experience issues with IP fragments being denied and so do not require the functionality provided by RFC7383 (but for the cases where it’s needed, it’s a lifesaver).

4.      The large quantum resistant ‘blob’ of data is only sent when it is known that the peer will accept this. This minimises delays when establishing IKEv2 SAs and minimises the risk of DoS (see point 7). 

5.      Backwards compatibility is maintained, with minimal risk that the addition of a quantum resistant exchange could cause abnormal behaviour with devices that do not support the new attributes. The QSKE are advertised using a transform type 4 groups.

6.      This idea allows for algorithm agility, where multiple quantum resistant algorithms can be used in addition to a single classic DH (as per RFC7296). PQ algorithms with public data size larger than 65,536 octets are also supported.

7.      With regards to fragmentation attacks, the use of fragmentation in this idea has the same security as of RFC7383. Whereby an attacker that reveals her true IP address can send multiple fragments, but not the complex chain.

The following is the idea, any questions, please feel free to ask.

 

QSKE Notify

For devices that are operating in a mesh network, where many devices have multiple peers, where peers are using varying QSKE groups. In these instances the QSKE that is preferred by the Initiator might not be available or preferred on the Responder. To overcome scenarios where the Initiator will send a QSKE which is large in size and not supported by the Responder, (therefore wasting time and resource), the QSKE Notify payload can be used to query the responder to determine the supported security association attributes. The QSKE Notify payload is sent by the Initiator, which also excludes the QSKE payload (however a single KE payload should be included for backwards compatibility). If the Responder supports the QSKE notify payload it replies with the accepted security associations (which includes one classic DH group and >=1 QSKE group, these are sent as groups within transform type 4. Most of the time, we will be using one PQ algorithm, rather than multiple. The Responder will also includes the COOKIE notification, note the Responder does not send the KE or QSKE payload. The Initiator can now select the correct security association algorithms it intends to use, including the correct classic DH and QSKE and reply using the COOKIE. 

Although the COOKIE does not provide protection against DoS attacks, whereby an attacker sends many fragments but does not complete the fragment chain, it does ensure that the attacker reveals their own IP address. Note that RFC 7383 is also prone to this attack which is described within the security considerations.

Should an IKE gateway be under a fragmentation attack, dropping traffic from a peer that does not complete the fragment chain can be used as a simple protective mechanism to minimise the impact of future attacks.

For implementations that do not support the use of the QSKE, the QSKE Notify payload will be ignored and the IKEv2 exchange will continue as per RFC7296. The QSKE Notify payload can be used to minimise inter-op issues with QSKE and non QSKE implementations. 

The QSKE Notify payload can be marked as critical for devices that mandate the use of QSKE to protect IKE.

QSKE Notification Payload

                        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        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |  Protocol ID  |   SPI Size    |      Notify Message Type      |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                                                               |

   ~                       Notification Data                       ~

   |                                                               |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

————

A Quantum Safe Key Exchange Payload

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 Fragment bit, denoted F (below), specifies if the QSKE is fragmented. If this is set to '1', meaning the QSKE is fragmented the Fragment Number and Total Fragments fields will be populated. If the Fragment bit is not set (set to '0'), then the Fragment Number and Total Fragments fields will not exist. The Fragment Number is used should the Quantum-Safe Data be too large to fit within a single payload. The Fragment Number is the first fragment, increasing by one for every other fragment that is sent. The Total Fragments field denotes the maximum number of fragments that contain the Quantum-Safe Data.

The QSKE is nearly identical to the KE payload, however the Fragment bit identifies if the receiver should handle this in a different manner to the KE payload. The KE and QSKE are negotiated/advertised using the transform type 4 (Diffie Hellman groups).  By including the QSKE in the same transform type 4 as classic DH allows for minimal configuration changes for current implementations when configuring both DH and QSKE Groups.

                           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|F| Reserved  |            Payload Length     |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |    Quantum-Safe Group Num     |           RESERVED            |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      ~        Fragment Number            |     Total Fragments       ~

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                                                               |

      ~                       Quantum-Safe Data                       ~

      |                                                               |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The size of the Quantum-Safe Data can be the total fragments * payload length = ~ 4GB, which seems sufficient for the size of the QSKE payloads discussed so far.

The use of the Fragmentation bit is not mandatory. Implementations can attempt to send the IKE_SA_INIT payload containing the QSKE payload without fragmentation at the IKE layer, opting for fragmentation at the IP layer instead. Implementations can initially exclude the the use of fragmentation in the QSKE payload, however if connectivity fails when not using fragmentation of the QSKE, it is assumed that that traffic has been denied due to fragmentation at the IP layer and fragmentation of the QSKE should be used instead.

——

In the following example the Initiator will propose DH Groups 14,19,21 and 30,32 and 35 (fictitious QSKE groups). The Initiator sends the N(QSKE), which informs the responder to choose >=1 QSKE groups along with a classic DH group.

The responder will return the N(QSKE) payload, indicating it supports the QSKE, the security association includes DH Groups 14, 30 and 35 which informs the initiator of the QSKE groups it selects to use.

The Initiator then sends the QSKE's and KE for the groups it wishes to use, plus the identical security associations as was sent in the first exchange (to mitigate downgrade attacks). Note: The Responder should check that the received QSKE's in the security association match with its preferred secure QSKE's. This is to mitigate the following attack, Initiator sends SA contains certain QSKE in the security association Responder responds, but attacker modifies this response to remove the said QSKE. The Initiator then performs the IKE_SA_INIT excluding the QSKE that was removed by the attacker,  in the QSKE (but it's included in the security associations). Hence if the responder verifies that the received QSKE match the received security associations, it will mitigate this attack.

    Initiator                   Responder

   -----------                 -----------

   HDR, SAi1, Ni,KEi    -->                                 (DH Groups 14,19,21 and 30,32 and 35)

      N(QSKE)

                       <--   HDR, SAr1, N(COOKIE),[N(QSKE)]       (DH Groups 14, 30 and 35)

   HDR, N(COOKIE), SAi1,                                    (SA contains DH Groups 14,19,21 and 30,32 and 35)

    KEi, Ni, QSKEi-1/3  -->                                 (KE is Group 14, QSKE1 is Group 30, fragment 1 of 3)

   HDR, QSKEi-2/3       -->                                 (QSKE1 is Group 30, fragment 2 of 3)

   HDR, QSKEi-3/3       -->                                 (QSKE1 is Group 30, fragment 3 of 3)

   HDR, QSKEi2-1/4      -->                                 (QSKE2 is Group 35, fragment 1 of 4)

   HDR, QSKEi2-2/4      -->                                 (QSKE2 is Group 35, fragment 2 of 4)

   HDR, QSKEi2-3/4      -->                                 (QSKE2 is Group 35, fragment 3 of 4)

   HDR, QSKEi2-4/4      -->                                 (QSKE2 is Group 35, fragment 4 of 4)

                  <--  HDR, SAr1, Nr, KEr,                  (KE is Group 14, QSKE1 is Group 30, fragment 1 of 3)

                        QSKEi-1/3

                  <--  HDR,QSKEi-2/3                        (QSKE1 is Group 30, fragment 2 of 3)

                  <--  HDR,QSKEi-3/3                        (QSKE1 is Group 30, fragment 3 of 3)

                  <--  HDR,QSKEi2-1/4                       (QSKE2 is Group 35, fragment 1 of 4)

                  <--  HDR,QSKEi2-2/4                       (QSKE2 is Group 35, fragment 2 of 4)

                  <--  HDR,QSKEi2-3/4                       (QSKE2 is Group 35, fragment 3 of 4)

                  <--  HDR,QSKEi2-4/4                       (QSKE2 is Group 35, fragment 4 of 4)

As three groups were used, the keymat is generated with the combination of the output from the three public values.

KEYMAT = prf+(SK_d, QSSS2 (Group 35) | QSS1 (Group 30) | g^ir (Group 14) | Ni | Nr)

   HDR SK {IDi, [CERT,]

       [CERTREQ,] [IDr,] AUTH,

       SAi2, TSi, TSr}  -->

 

————

In the following the Initiator will propose DH Groups 14,19,21 and 30,32 and 35 (fictitious QSKE groups). The Initiator sends N(QSKE), which tells responder to choose a DH group and >=1 QSKE groups  .

The Responder in this case does not support QSKE and assuming the N(QSKE) was non critical, will ignore this Notify Payload.

The exchange will continue as per RFC7296.

    Initiator                   Responder

   -----------                 -----------

   HDR, SAi1, Ni,KEi    -->                           KE=Group 14 (SA: DH Groups 14,19,21 and 30,32 and 35)

      N(QSKE)                                         

                       <--   HDR, SAr1,Nr,KEr         (DH Groups 14)

  HDR SK {IDi, [CERT,]

       [CERTREQ,] [IDr,] AUTH,

       SAi2, TSi, TSr}  -->

———————

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 3 Aug 2017 13:09:02 +0000

It seems to me that, when talking about IKE authentication, it would make sense to start with what’s already defined in the protocol:

Currently, IKE defines three types of authentication mechanisms:

-          Preshared Keys

-          Certificates

-          EAP
Preshared keys are, for authentication purposes, already postquantum (assuming that the preshared keys are sufficiently long, and we use a postquantum prf); nothing needs to be done here

Certificates; people are already working on postquantum certificates (involving both conventional and postquantum signatures in parallel); it would appear to make sense to try to reuse their work, rather than coming up with something specific to IKE

EAP; frankly, I’m not that familiar with EAP, however, if EAP isn’t currently postquantum secure, it may make sense for that protocol to be updated.

The other question about your proposed mechanism is how does it work; you just outline a way to exchange ‘quantum resistant’ blobs, and don’t say how those blobs actually work.  I’m not talking about the cryptography, I’m talking about the authentication.  For an authentication mechanism to work (for Alice to authenticate to Bob), we must have:

-          Alice can generate the Blob

-          Eve cannot generate the Blob

-          Bob can verify that the Blob was generated properly
Saying “postquantum” doesn’t change the underlying problem.  You don’t specify how this works (e.g. what Alice and Bob knows), and why the current authentication mechanisms already in IKE aren’t sufficient

From: IPsec [mailto:[email-masked]] On Behalf Of Graham Bartlett (grbartle)
Sent: Thursday, August 03, 2017 7:57 AM
To: [email-masked]
Subject: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi

QSKE Notify

                        1                   2                   3

————

                           1                   2                   3

——

    Initiator                   Responder
   -----------                 -----------

   HDR SK {IDi, [CERT,]
       [CERTREQ,] [IDr,] AUTH,
       SAi2, TSi, TSr}  -->

————

    Initiator                   Responder
   -----------                 -----------

  HDR SK {IDi, [CERT,]
       [CERTREQ,] [IDr,] AUTH,
       SAi2, TSi, TSr}  -->

———————

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Aug 2017 10:13:10 -0400

Scott Fluhrer (sfluhrer) <[email-masked]> wrote:
    > EAP; frankly, I’m not that familiar with EAP, however, if EAP isn’t currently
    > postquantum secure, it may make sense for that protocol to be updated.

EAP is a framework for a set of algorithms, some of which are are as stupid
as "send the cleartext password", to CHAP-methods, to run some variation
of TLS and do something else inside the TLS. (Yes, you can run EAP inside
the TLS, and recursive...)

Key generating EAP methods (of which passwords are not an example), deliver
the same key to both ends securely, which in some situations is used to
authenticate something else.  In WPA/1x, it becomes your WEP key.

In IKEv2, we can use EAP in addition to other methods; the gateway machine
will often authenticate with a certificate.  So if the certificate is
post-quantum, is it enough to have half-duplex resistance?  I suspect not.

(I didn't read the rest of your message yet)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Wouters <[email-masked]>
Date: Thu, 3 Aug 2017 12:06:35 -0400 (EDT)

On Thu, 3 Aug 2017, Graham Bartlett (grbartle) wrote:

> 1.      The IKE_AUTH exchange is protected using the quantum secure algorithms. So all attributes within the IKE
> exchange are protected against passive attacks, which wouldn’t be the case should the quantum resistant ‘blob’ be
> sent in IKE_AUTH.

Depends on what you mean with "protected". Sure it could be seen in
plaintext, but still not broken. But sure, it would be nice to have
this message fully protected against passive eavesdroppers.

> 3.      A simple method to fragment the quantum secure key exchange data in IKE_SA_INIT is included

> 4.      The large quantum resistant ‘blob’ of data is only sent when it is known that the peer will accept this.

I don't understand this? You mean known by preconfiguration? That would
make migration really difficult and introduce a flag day. It would also
not be true for Opportunistic IPsec, where there is no preconfiguration
between peers.

> 7.      With regards to fragmentation attacks, the use of fragmentation in this idea has the same security as of
> RFC7383. Whereby an attacker that reveals her true IP address can send multiple fragments, but not the complex chain.

I'm not sure how that can be, if it is the IKE_INIT that is getting
fragmented.

> For devices that are operating in a mesh network, where many devices have multiple peers, where peers are using
> varying QSKE groups. In these instances the QSKE that is preferred by the Initiator might not be available or
> preferred on the Responder. To overcome scenarios where the Initiator will send a QSKE which is large in size and not
> supported by the Responder, (therefore wasting time and resource), the QSKE Notify payload can be used to query the
> responder to determine the supported security association attributes. The QSKE Notify payload is sent by the
> Initiator, which also excludes the QSKE payload (however a single KE payload should be included for backwards
> compatibility). If the Responder supports the QSKE notify payload it replies with the accepted security associations

Isn't this all unsafe against downgrade attacks?

> For implementations that do not support the use of the QSKE, the QSKE Notify payload will be ignored and the IKEv2
> exchange will continue as per RFC7296.

What prevents an attacker from stripping out the QSKE Notify payload in
the IKE_INIT request?

> The QSKE is nearly identical to the KE payload, however the Fragment bit identifies if the receiver should handle
> this in a different manner to the KE payload. The KE and QSKE are negotiated/advertised using the transform type 4
> (Diffie Hellman groups).  By including the QSKE in the same transform type 4 as classic DH allows for minimal
> configuration changes for current implementations when configuring both DH and QSKE Groups.

Can this not be abused for an amplification attack by sending a really
small QSKE payload and causing the responder to send back a large QSKE
payload in multiple fragments?

> The use of the Fragmentation bit is not mandatory. Implementations can attempt to send the IKE_SA_INIT payload
> containing the QSKE payload without fragmentation at the IKE layer, opting for fragmentation at the IP layer instead.
> Implementations can initially exclude the the use of fragmentation in the QSKE payload, however if connectivity fails
> when not using fragmentation of the QSKE, it is assumed that that traffic has been denied due to fragmentation at the
> IP layer and fragmentation of the QSKE should be used instead.

How does that work on the responder side? In IKEv2, the responder never
retransmits. What if fragments from responder to initiator fail?

>                   <--  HDR,QSKEi2-3/4                       (QSKE2 is Group 35, fragment 3 of 4)

Why would the responder reply to two group suggestions with QSKE payloads?
Normally in IKEv2, the initiator sends a list of proposals/options, and
the responder picks one from it.

> As three groups were used, the keymat is generated with the combination of the output from the three public values.

How did the initiator signal support for all groups _and_ support for
combining them? What is gained by combining multiple groups?

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 4 Aug 2017 15:59:46 +0300

Hi Graham,

few comments.

It is not clear for me (and I raised this concern in Prague) why do you use QSKE as an additional

Key Exchange mechanism instead of replacing DH KE with it? We’ve been being told by cryptographers

that conventional public key cryptography won’t provide security in presence of QC, so why bother with it?

Using QSKE as an additional Key Exchange complicates protocol exchange, increases messages size

and resource consumption and  also modifies generation of SKEYSEED, that makes it non-uniform.

The only reason that comes to my mind is that you don’t fully trust QSKE. Are there any other reasons?

And as an additional point to the above concern – why do you allow several QSKE methods to be used

in one exchange? The same set of problems – protocol complexity, resource consumption, messages size.

And I think if the IKE_SA_INIT messages grow too large with QSKE, then it’s better to develop

generic fragmentation mechanism for IKE_SA_INIT, rather than making it specific for fragmenting

QSKE blobs. Generic mechanism would allow to reuse it in case we’ll have to include

other large payloads in initial messages.

Regards,

Valery.

From: IPsec [mailto:[email-masked]] On Behalf Of Graham Bartlett (grbartle)
Sent: Thursday, August 03, 2017 2:57 PM
To: [email-masked]
Subject: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi

A few weeks ago I developed a method to send the quantum resistant ‘blob’ in IKE_SA_INIT, this is to amend  <https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske-ikev2-00> https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske-ikev2-00. After hearing the discussion described above I was going to park this idea and never speak of it again, however before I do this I’d like to share with the group for comments. 

 

QSKE Notify

                        1                   2                   3

   |                                                               |

   ~                       Notification Data                       ~

   |                                                               |

————

                           1                   2                   3

      |                                                               |

      ~                       Quantum-Safe Data                       ~

      |                                                               |

 

——

 

    Initiator                   Responder

   -----------                 -----------

      N(QSKE)

 

 

                        QSKEi-1/3

 

 

   HDR SK {IDi, [CERT,]

       [CERTREQ,] [IDr,] AUTH,

       SAi2, TSi, TSr}  -->

 

————

 

    Initiator                   Responder

   -----------                 -----------

      N(QSKE)                                         

 

  HDR SK {IDi, [CERT,]

       [CERTREQ,] [IDr,] AUTH,

       SAi2, TSi, TSr}  -->

———————

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 4 Aug 2017 13:40:49 +0000

From: IPsec [mailto:[email-masked]] On Behalf Of Valery Smyslov
Sent: Friday, August 04, 2017 9:00 AM
To: Graham Bartlett (grbartle)
Cc: [email-masked]
Subject: Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi Graham,

few comments.

No, that’s pretty much it.  We’ve studied DH for something like 40 years, and ECDH for perhaps 30; we feel that we can have a measure of trust with them, at least against conventional computers.  For these newer quantum key exchanges, well, we’re not as certain if they’re secure even against a conventional computer.  By including an ECDH exchange, we know that we’re not making anything worse; we can be fairly confident that we haven’t made anything worse (at least, cryptographically speaking).

Same reason; known post quantum key exchange mechanisms haven’t been out there for that long (exceptions: McEliece and NTRU), and so we’re not as certain whether they’ll actually turn out to be quantum resistant.  It seems plausible that someone might not want to put all their postquantum eggs in one basket, and instead rely on two unrelated postquantum exchanges (e.g. LWE and SIDH)

The trick is trying to allow this, while minimizing the increase in the protocol complexity.  I don’t consider the resource consumption and message size (apart from the protocol complexity needed for fragmentation support) that critical; presumably, if someone was paranoid enough to think they required it, they ought to be willing to pay the additional resource cost.

Actually, I put together a paper design which tried to do exactly this.  I eventually put it aside, because of two concerns:

-          Backwards compatibility; an IKE initiator really can’t send fragmented packets before it hears whether the responder can understand them; this pretty much required an additional round trip

-          DoS concerns; the responder has to hold onto fragments from a random initiator who has done not much of anything
I also didn’t care that my specific proposal was tied too closely to how the postquantum KE payload was formatted.  I still have that design; if anyone was interested, I could slap it on the mailer for people to laugh at.

Regards,
Valery.

From: IPsec [mailto:[email-masked]] On Behalf Of Graham Bartlett (grbartle)
Sent: Thursday, August 03, 2017 2:57 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi

QSKE Notify

                        1                   2                   3

————

                           1                   2                   3

——

    Initiator                   Responder
   -----------                 -----------

   HDR SK {IDi, [CERT,]
       [CERTREQ,] [IDr,] AUTH,
       SAi2, TSi, TSr}  -->

————

    Initiator                   Responder
   -----------                 -----------

  HDR SK {IDi, [CERT,]
       [CERTREQ,] [IDr,] AUTH,
       SAi2, TSi, TSr}  -->

———————

---

From: Cen Jung Tjhai <[email-masked]>
Date: Sat, 5 Aug 2017 21:29:22 +0000

Hi Paul,

>>not be true for Opportunistic IPsec, where there is no preconfiguration

It's not pre-configuration, but negotiated via a notify payload (QSKE Notify) that is sent in IKE_SA_INIT. 

>>> RFC7383. Whereby an attacker that reveals her true IP address can send multiple fragments, but not the >>>complex chain.

>>I'm not sure how that can be, if it is the IKE_INIT that is getting

It's not entire IKE_SA_INIT message that is fragmented. The fragmentation only applies to post-quantum public data, where almost all of them has payload size larger than 1KB. Furthermore, there is a known type of post-quantum algorithm whose payload size is larger than 64KB and there could be more in the future. We think by fragmenting the payload in this way, it is possible to support this kind of algorithm.

>>Isn't this all unsafe against downgrade attacks?

If a peer declares support of post-quantum algorithm with QSKE Notify payload, but not sending the post-quantum blob, the other peer shall reject the connection. On the other hand, for backward compatibility, it is up to the initiator to set the fallback policy; does it allow standard SAs or only post-quantum SAs are supported. 

>>What prevents an attacker from stripping out the QSKE Notify payload in

If QSKE Notify payload is stripped, the peers won't be able to negotiate post-quantum algorithm for key-exchange, hence it depends on the configured fallback policy. 

In general, QSKE payloads sent by the initiator and responder are of pretty much of equal size. It is possible for an malicious initiator to send a small QSKE payload and expecting the responder to return large multiple fragments QSKE payload. In order to combat, the responder could employ existing mechanisms to minimise the impact of this attack, for example using COOKIE or for more sophisticated attacks, RFC8019. 

>>the responder picks one from it.

In order to support "crypto-agility", which allows peers to have flexibility in selecting cipher suites. In this way, peers are able to select a DH combined with multiple post-quantum algorithms. We are not sure how important this feature is, but it would be a great idea to get opinions from the group.

>>combining them? What is gained by combining multiple groups?

The signalling is done via QKSE notify. I appreciate that we have not yet described how this work on the text.

Best regards,
CJ

---

From: Cen Jung Tjhai <[email-masked]>
Date: Sat, 5 Aug 2017 21:29:26 +0000

​Hi Valery,
 
>>other large payloads in initial messages.
 
Yes, while a generic mechanism would allow it to be reused, it sounds like a different draft all together. It could result in a very complex change in the protocol. Furthermore, we would like to support QSKE blob that is larger than 64KB in size, hence we fragment it in that way.

Best regards,
CJ

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Sun, 6 Aug 2017 17:58:56 +0000

Hi

Sorry for the late reply. I’ve replied to where I feel I could add some more context to CJ’s reply.

GB>inline

On 05/08/2017, 14:29, "IPsec on behalf of Cen Jung Tjhai" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Paul,

    

GB> So the QSKE Notify basically tells the peer ‘I’ve got some PQ algorithms that are probably going to be large and these could be used’. I was chatting to Frederic Detienne last night who did raise the point that we didn’t have to use the QSKE Notify, we could just act on the fact that if we receive a IKE_SA_INIT with certain (QCR) groups in transform type 4 that are known to be large, we would naturally fragment these when they are sent in the next round.

    
    
GB> in RFC7383 an attack is described that can exhaust the receivers resource, where the attacker reveals their IP address;

The following attack is possible with IKE fragmentation.  An attacker

   can initiate an IKE_SA_INIT exchange, complete it, compute SK_a and

   SK_e, and then send a large but still incomplete set of IKE_AUTH

   fragments.  These fragments will pass the ICV check and will be

   stored in reassembly buffers, but since the set is incomplete, the

   reassembling will never succeed and eventually will time out.  If the

   set is large, this attack could potentially exhaust the receiver's

   memory resources.

To perform the same attack, as the quantum resistant ‘blob’ of data is sent after a negotiation, an attacker would need to reveal their IP address (they can not just perform a blond spoofing attack where they spoof another IP address). 

    

    

GB> If an attacker removed the QSKE Notify inline, the exchange would occur as per RFC7296. As we include the RestOfMessage1 in the authentication material check, this would not tally on both peers and authentication would fail. 

    
    
GB> That’s a great point and yes your right, I guess this could happen (but the attacker would reveal their IP address, which could then be blocked). However I would assume that for these quantum resistant ‘blobs’ there’s a check to ensure that the data is valid or structured. Something like RFC6989 but for the algorithms that are used by the quantum resistant ‘blobs’.

    

GB> I know Scott Fluhrer also thought about this. For simplicity I suggested that if Quantum Resistant groups are used we naturally allow the Responder to decide how many of the QCR algorithms it wishes to use. I personally think that signalling the use of certain groups of groups could get messy (unless someone develops a simple method to achieve this, which I haven’t seen so far). I personally really like the simplicity of the method that IKEv2 negotiates the transforms to use (just pick one of the following) and for the QC groups we could just extend this to ‘just pick >1 of the following..’.
    
    Best regards,
    CJ
    _______________________________________________
    IPsec mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 9 Aug 2017 12:42:23 +0300

Valery Smyslov writes:
> It is not clear for me (and I raised this concern in Prague) why do
> you use QSKE as an additional Key Exchange mechanism instead of
> replacing DH KE with it? We’ve been being told by cryptographers

For me the main reason is that we have been told that current protocol
used in IKE is safe, and if we do not break it (i.e., remove it), but
instead just add some more random data to SKEYSEED, I think it should
be quite easy to proove that this new construct is also safe. I.e., us
adding PPK/QSKE etc stuff to our calculations will not weaken the
security of the IKEv2. 

> QSKE. Are there any other reasons?

I think that is one of the main reasons. Especially as we do not know
which QSKE we are talking about.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 9 Aug 2017 13:08:13 +0300

Cen Jung Tjhai writes:
>>And I think if the IKE_SA_INIT messages grow too large with QSKE,
>>then it’s better to develop generic fragmentation mechanism for
>>IKE_SA_INIT, rather than making it specific for fragmenting QSKE
>>blobs. Generic mechanism would allow to reuse it in case we’ll have
>>to include other large payloads in initial messages.
>
> Yes, while a generic mechanism would allow it to be reused, it
> sounds like a different draft all together. It could result in a
> very complex change in the protocol. Furthermore, we would like to
> support QSKE blob that is larger than 64KB in size, hence we
> fragment it in that way. 

Actually I think it would be better NOT to change IKE_SA_INIT at all,
but instead add new exchange between the IKE_SA_INIT and IKE_AUTH.

I.e., lets have following exchange:

Initiator                         Responder
   -------------------------------------------------------------------
   HDR(IKE_SA_INIT, MID=0), SAi1, KEi,
       Ni, N(IKEV2_FRAGMENTATION_SUPPORTED),
       N(PRE_AUTH_SUPPORTED)  -->

                                <--  HDR(IKE_SA_INIT, MID=0), SAr1, KEr, Nr,
				         N(IKEV2_FRAGMENTATION_SUPPORTED)
                                     	 N(PRE_AUTH_NEEDED), [CERTREQ]

   HDR(PRE_AUTH, MID=1),
       SKF(NextPld=PLD1, Frag#=1, TotalFrags=m)
       {...} -->
   HDR(PRE_AUTH, MID=1),
       SKF(NextPld=0, Frag#=2, TotalFrags=m)
       {...} -->
   ...
   HDR(PRE_AUTH, MID=1),
       SKF(NextPld=0, Frag#=m, TotalFrags=m)
       {...} -->

				<-- HDR(PRE_AUTH, MID=1),
				        SKF(NextPld=PLD1, Frag#=1,
					    TotalFrags=m)
			                {...}
				<-- HDR(PRE_AUTH, MID=1),
				        SKF(NextPld=0, Frag#=2,
					    TotalFrags=m)
			                {...}
                            ...
				<-- HDR(PRE_AUTH, MID=1),
				        SKF(NextPld=0, Frag#=m,
					    TotalFrags=m)
			                {...}

   HDR(IKE_AUTH, MID=2),
       SK {IDi, [CERT,] [CERTREQ,]
           [IDr,] AUTH, SAi2,
           TSi, TSr}  -->

                                <--  HDR(IKE_AUTH, MID=2),
				         SK {IDr, [CERT,] AUTH,
                                             SAr2, TSi, TSr}

I.e., we run normal IKE_SA_INIT with message ID of 0. It negotiates
the fragmentation (IKEV2_FRAGMENTATION_SUPPORTED), so all further
exchanges after IKE_SA_INIT can use fragmentation.

Then we do another exchange before the IKE_AUTH, i.e. we do PRE_AUTH
exchange before IKE_AUTH using message id 1 (or even message ids 2, 3,
4, etc, as many as are needed). This step does the large blob exchange
neede for the IKE_AUTH. As these are normal fragmented IKEv2 message,
i.e. there is request and there is reply. What goes in there is
most likely using some new payload number to transfer the QSKE data in
both directions.

Note, that IKEv2 messages are limited to 4GB in size, and one payload
inside IKEv2 message is limited to 64kB in size, so if larger than 64k
objects need to be transmitted, it can be transmitted using exactly
one IKEv2 message, having multiple payloads in it. On the other hand
as fragments are not individually acknowledged, we do not want to
transfer too big messages using it, so it might be better to allow
multiple PRE_AUTH message exchanges before moving to the IKE_AUTH.
This means that the PRE_AUTH exchange most likely needs to have some
way of telling the other end when it is done, and when to move to
IKE_AUTH.

IKE_AUTH then would be just normal IKE_AUTH.

The fact whether we need the PRE_AUTH exchange can be negotiated in
the IKE_SA_INIT, either using transform types in SA payload, or using
the notify payloads.

Also if we split data to less than 64k chunks anyways, it might also
be better not to use IKEv2 fragmentation, but instead just send
several PRE_AUTH exchanges instead.

Note, that the PRE_AUTH happening between IKE_SA_INIT and IKE_AUTH
would be encrypted, and MACed, but it WILL NOT be authenticated, i.e.,
we have not yet authenticated the other peer, and we will not include
those octets to the AUTH payload calculations, so they will not be
authenticated in AUTH phase, like the IKE_SA_INIT contents will be
authenticated.

I think this kind of step between IKE_SA_INIT and IKE_AUTH might be
easiest and most generic way of transferring the QSKE data. We will be
transferring large amount of data anyways, so trying to put it part of
IKE_SA_INIT is not useful, and trying to play around with cookies, and
IKE_SA_INIT modifications is just adding complexity. 
-- 
[email-masked]

---

From: Daniel Van Geest <[email-masked]>
Date: Wed, 9 Aug 2017 13:56:06 +0000

Hi Graham and all,

I have a few comments/suggestions on Graham’s idea. They concern two components of this proposal: 1) QS SA negotiation; and 2) QS KE/fragmentation; and one item unaddressed by the proposal 3) Rekeying/Child Creation.

Apologies in advance for the length.

1) QS SA Negotiation

When negotiating a QS SA, it’s not enough to negotiate QS key agreement algorithm(s), one also has to ensure that the algorithms selected by the other transform types are also QS. For example ENCR_AES_CBC (KeyLength = 128) will only provide 64 bits of security against a quantum computer, which is insufficient. If we are only concerned about passive quantum attacks then the choice of integrity algorithm won’t matter as much, however PRF transforms with enough bits of security to be QS will also need to be chosen.

With that in mind, I have concerns about advertising/negotiating the QSKE algorithms along with the KE algorithms in transform type 4. In order to ensure that a QS SA is established, the initiator will have to ensure that the first advertised SA is the QS one. This is fine, as RFC7296 specifies that the proposals are listed in order of preference. However, I don’t see a requirement that the transforms within a proposal have to be listed according to preference, or that the responder has to chose the first or strongest supported transform in a list (the end of section 3.3.5 talks about picking stronger transform *attributes*, but not about transforms). My point here is that if a responder may chose any of the proposed transforms then for the first proposal to be QS it must not contain any quantum-insecure transforms, or the responder must be modified to understand which ENCR/PRF transforms are QS and to pick them when creating a QS connection (and to fail if no QS algorithms are proposed). Then if an initiator wants to create QS SAs, but also wants to interoperate with (very?) old responders who don’t support AES-256 or PRF_HMAC_SHA2_384+ then they will need a second non-QS proposal in their SA list. And if they want to allow non-QS-upgraded, but still recently updated, responders a choice to use non-QR ENCR/PRF transforms (for performance reasons perhaps), they won’t be able to because the responder will have to pick transforms from the first (fully QS) proposal since it supports all the algorithms in the transform.

Now, maybe those concerns above are minor and the WG can live with them. That’s fine, I just want to make sure they’re considered.

I don’t find the re-use of transform 4 in this proposal, and the implicit combination of QS + non-QS algorithms, to be the most elegant, though I can understand it in the context of not wanting to add a new transform type.

But I am curious how strong this opposition to a new transform type is (apologies, I wasn’t in Prague so I don’t know if any other discussions occurred outside the WG timeslot). I fully understand the opposition due to backwards compatibility issues, this is something I came across in my own investigation too. I recall some opposition due to the possibility of the new transform creating additional proposals in the SA list (as new proposals are already needed due to AEAD), though I would imagine this is a lesser issue than backwards  compatibility. If the main concern is backwards compatibility, would the WG be willing to consider an idea which includes the new transform type but avoids backwards compatibility issues? If so, I had a variant on the current proposals which I is more explicit in the separation of QS and non-QS SAs and uses a new transform type in a backwards compatible way.

The idea is to add the new transform type 6 (Q-S-Group) like CJ’s proposal, but don’t include it in the SA payload. Rather, introduce a new QS_SA payload which would be identical in structure to the SA payload except that it would also include the Q-S-Group transform type. An endpoint could configure the proposals in this payload to contain QS and only QS ENCR/PRF algorithms, plus QRKE algorithms in transform type 6 and existing DH algorithms in type 4. The SA payload would still exist, so non-upgraded responders would still be supported, but upgraded responders would give the QS_SA proposals higher priority than SA proposals.

A non-upgraded responder would not recognize the QS_SA payload and so would chose an SA from the SA payload. They would also never see the new transform type, so there would be no backward-compatibility issues. A responder who recognizes the QS_SA payload could respond using a QS_SA payload rather than a SA payload (or if you think there would be implementation problems with this we could say they respond with an SA payload which contains the selected proposal from the QS_SA payload).

With this idea a new notification type isn’t necessary, because the existence of the QS_SA payload lets the responder know this extension is supported, and a response SA containing a proposal from QS_SA (and containing transform type 6) lets the initiator know this extension is supported by the responder. An attacker couldn’t remove the QS_SA payload because it will be protected by the IDi/IDr payloads in IKE_AUTH.

2) QR KE / fragmentation

I wrote up this message yesterday to review and send in the morning, but Tero's message last night covered my suggestion for fragmentation, so I’ll just add a few notes to consider in this area.

As mentioned, this PRE_AUTH (I like IKE_QS_KE, but if we think it will be expanded later then PRE_AUTH is more generic) message is encrypted with the classical keys generated in IKE_SA_INIT. The shared secrets generated in PRE_AUTH can use the existing rekeying mechanism to update the SA to be QS:

KEYMAT = prf+(SK_d, QS_SECRET | Ni | Nr)

Something to keep in mind is that many QS key agreement algorithms don’t have exactly the same message flow as Diffie Hellman.  With DH, each endpoint’s public/private keys can be generated independently of each other. But many QS algorithms have an initiator-responder flow, so the responder can only generate its public key once it has processed the initiator’s public key. We just need to keep this in mind when designing the flow of the PRE_AUTH messages. An initiator can’t send the first chunk of a public key, and the responder reply with the first chunk of their public key, the responder would need to process all initiator chunks for that key first. This means the initiator would have to send a special acknowledgement response for chunks that don’t complete a public key rather than responding with a partial key when receiving a partial key.

Also note that StrongSwan’s code assumes that IKE_AUTH will always have a message ID of 1, but this won’t hold if there are one or more PRE_AUTH exchanges. I was able to update StrongSwan to remove that assumption and instead check against IKE_AUTH’s actual message ID. It’s not clear to me whether Graham’s IKE_SA_INIT fragmentation would also suffer from this issue, I suspect that the IKE_SA_INIT fragments would need incrementing message IDs so endpoints don’t discard them? Hopefully other implementations either don’t have this assumption or are equally easy to modify.

Tero says:

Couldn’t the IDi and IDr payloads in IKE_AUTH be modified to sign the PRE_AUTH message in addition to the IKE_SA_INIT message?

Tero says:

I think this kind of step between IKE_SA_INIT and IKE_AUTH might be
easiest and most generic way of transferring the QSKE data.

I definitely agree :-)

3) Rekeying/Child Creation

Graham’s suggestion works entirely in IKE_SA_INIT, so if new SA is created or one is rekeyed it’s not clear how the QS public keys would be exchanged. They could be included in a payload of CREATE_CHILD_SA, but this will run up against the 64K barrier. Similar fragmentation could be added to CREATE_CHILD_SA as would be added to IKE_SA_INIT, however that could make things less elegant and could result in duplication of logic between IKE_SA_INIT and CREATE_CHILD_SA.

As my investigations didn’t account for > 64K QR public keys, I haven’t considered this fully yet, but would adding a IKE_QS_KE exchange after CREATE_CHILD_SA simplify things here? Since CREATE_CHILD_SA already takes advantage of IKEv2’s fragmentation, CREATE_CHILD_SA could handle most QS_KE payloads without additional fragmentation so maybe it would be overkill to move child/rekey QS_KE payloads into a subsequent exchange. But it would still need some way to handle >64K keys.

Tero’s suggestion could probably be extended to cover additional PRE_AUTH (IKE_QS_KE :-) ) exchanges after CREATE_CHILD_SA,

For any solution with multiple exchanges there may be an implementation issue where the endpoints are trying to send application data after the classical rekey is done but before the QS rekey completes.

4) That was long

Hopefully this wasn’t too long-winded. I’d be interested in hearing if anyone thinks any of these ideas are worth further investigation and would be glad to provide any resources to develop these ideas further.

4.1) A note on "Quantum-Safe” (QS) vs “Quantum-Resistant” (QR)

I’ve tried to use QS in my response to be consistent with Graham & CJ’s initial messages and draft, however in my experience “Quantum-Safe” has been used to refer to anything that can’t be broken by a quantum computer, meaning both algorithms which aren’t vulnerable to Shor’s or Grover’s algorithms but are running on classical computers, as well as true quantum processes like quantum key distribution (QKD). “Quantum-Resistant” has been used to refer to QS without QKD, i.e. just algorithms running on classical computers which aren’t vulnerable to quantum attack. So in my opinion all of the work we are doing here should be labeled Quantum Resistant rather than Quantum Safe. YMMV.

—
Daniel Van Geest ([email-masked]<mailto:[email-masked]>)
https://www.isara.com/

On Aug 3, 2017, at 7:57 AM, Graham Bartlett (grbartle) <[email-masked]<mailto:[email-masked]>> wrote:

Hi

QSKE Notify

                        1                   2                   3

————

                           1                   2                   3

——

    Initiator                   Responder
   -----------                 -----------

   HDR SK {IDi, [CERT,]
       [CERTREQ,] [IDr,] AUTH,
       SAi2, TSi, TSr}  -->

————

    Initiator                   Responder
   -----------                 -----------

  HDR SK {IDi, [CERT,]
       [CERTREQ,] [IDr,] AUTH,
       SAi2, TSi, TSr}  -->

———————

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Aug 2017 14:00:32 -0400

> but instead add new exchange between the IKE_SA_INIT and IKE_AUTH.

I agree.  All of the DoS (cookie, etc.) defense and switch to TCP, and
detection of NAT-T, etc. is in the IKE_SA_INIT, and so doing any kind of
framentation in IKE_SA_INIT is a bad idea.

    > 4, etc, as many as are needed). This step does the large blob exchange

Agreed.

    > PRE_AUTH message exchanges before moving to the IKE_AUTH.  This means
    > that the PRE_AUTH exchange most likely needs to have some way of
    > telling the other end when it is done, and when to move to IKE_AUTH.

    > IKE_AUTH then would be just normal IKE_AUTH.

The initiator will know when it is done, won't it? Can't it just move to
IKE_AUTH when it knows it is done?

Is the size of QSKE blob that the responder has to return to initiator likely
to be either unknown to the initator or very different than the
initiator->responder direction?

    > The fact whether we need the PRE_AUTH exchange can be negotiated in the
    > IKE_SA_INIT, either using transform types in SA payload, or using the
    > notify payloads.

Agreed.  I think it needs to be a new transform type.

    > Also if we split data to less than 64k chunks anyways, it might also be
    > better not to use IKEv2 fragmentation, but instead just send several
    > PRE_AUTH exchanges instead.

How big are the blobs?  Your text seems to imply they might very big.

    > authenticated in AUTH phase, like the IKE_SA_INIT contents will be

Why couldn't we include those octets in the AUTH phase?

BTW, I don't like the name "PRE_AUTH", I think it should be something like
"AUTH_OBJECTS" or "AUTH_ARTIFACTS".

    > IKE_SA_INIT modifications is just adding complexity.

I agree strongly.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Aug 2017 14:12:14 -0400

Daniel Van Geest <[email-masked]> wrote:
    > transform *attributes*, but not about transforms). My point here is
    > that if a responder may chose any of the proposed transforms then for
    > the first proposal to be QS it must not contain any quantum-insecure
    > transforms, or the responder must be modified to understand which
    > ENCR/PRF transforms are QS and to pick them when creating a QS
    > connection (and to fail if no QS algorithms are proposed).

I don't see this an issue.  Perhaps it needs to be well explained, but
generally in IKEv2 we use (UI) suites to configure things.

    > Then if an
    > initiator wants to create QS SAs, but also wants to interoperate with
    > (very?) old responders who don’t support AES-256 or PRF_HMAC_SHA2_384+
    > then they will need a second non-QS proposal in their SA list.

Sure, that's exactly what they will do during the transition time (which may
be a few years... some entities stupidly refuse to even patch systems, preferring to
just replace them with new hardware every three years.)
They will propose a set of things that is compatible to the future and to the
past, and over time the old stuff gets removed from the policy.

    > I don’t find the re-use of transform 4 in this proposal, and the
    > implicit combination of QS + non-QS algorithms, to be the most elegant,
    > though I can understand it in the context of not wanting to add a new
    > transform type.

So you are suggesting that the QR mechanism be a new transform type then?
I could live with that actually since it make the combinatorics easier to manage.

    > The idea is to add the new transform type 6 (Q-S-Group) like CJ’s
    > proposal, but don’t include it in the SA payload. Rather, introduce a
    > new QS_SA payload which would be identical in structure to the SA
    > payload except that it would also include the Q-S-Group transform
    > type. An endpoint could configure the proposals in this payload to

I don't think we need to do this.
I think that unknown transform types will be ignored by compliant
implementations.

    > Something to keep in mind is that many QS key agreement algorithms
    > don’t have exactly the same message flow as Diffie Hellman. With DH,
    > each endpoint’s public/private keys can be generated independently of
    > each other. But many QS algorithms have an initiator-responder flow, so
    > the responder can only generate its public key once it has processed
    > the initiator’s public key. We just need to keep this in mind when
    > designing the flow of the PRE_AUTH messages. An initiator can’t send
    > the first chunk of a public key, and the responder reply with the first
    > chunk of their public key, the responder would need to process all
    > initiator chunks for that key first. This means the initiator would
    > have to send a special acknowledgement response for chunks that don’t
    > complete a public key rather than responding with a partial key when
    > receiving a partial key.

Would the initiator know how much data to expect from the responder?
If so, the initiator can just keep sending query messages to get new blocks
of data back.

    > Also note that StrongSwan’s code assumes that IKE_AUTH will always have
    > a message ID of 1, but this won’t hold if there are one or more

That's a bug, we both agree.

    > 4) That was long

:-)

---

From: Daniel Van Geest <[email-masked]>
Date: Wed, 9 Aug 2017 18:56:23 +0000

On Aug 9, 2017, at 2:12 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:
I don’t find the re-use of transform 4 in this proposal, and the
implicit combination of QS + non-QS algorithms, to be the most elegant,
though I can understand it in the context of not wanting to add a new
transform type.

Yes, I’m suggesting reconsidering putting the QR key agreement algorithms in a new transform type. This is part of CJ’s & co's suggestion from the original draft, but this was rejected in Prague. Their transform type was added to the proposals in the SA payload, while I’m suggesting only using it in a new QS_SA payload. (Perhaps eventually it could migrate to the SA payload in future drafts if non-QR connections ever need to be removed from IKEv2).

The reason why the original suggestion was rejected in Prague was because of backwards compatibility issues with non-compliant implementations. From experience, StrongSwan is non-compliant in this regard. If it receives a proposal with a transform type that it doesn’t understand it will pretend that the transform type isn’t there rather than rejecting the proposal and moving on to the next one. Thus it can end up responding with a proposal which the initiator didn’t suggest.

For example, if the initiator is configured to send:

ike=aes256-sha512-modp3072-newhope128,aes128-sha256-modp2048!

A non-upgraded StrongSwan will reply with:

aes256-sha512-modp3072

which from the initiator’s perspective is not one of its suggestions. The initiator will then error out and fail to establish the connection. We could define this new transform type as optional and hope that other implementations don’t behave even more poorly than this. But maybe an initiator doesn’t want to use aes256-sha512-modp3072 if it’s not talking to an upgraded responder, maybe for performance reasons it would prefer using weaker primitives with them.

Putting the QS proposals in a separate QS_SA payload would also allow an initiator to mark the payload as critical if it wants to require QS connections.

I’d answer that with a tentative yes. From the algorithms I’ve seen that’s the case, though one could imagine an algorithm where some (possibly non-deterministic amount of?) padding is added for some reason or other? Regardless, even if the initiator doesn’t know the amount of data to expect, it can keep querying and the responder payload could include a terminator flag indicating it is the last chunk of data.

If we decide that we want to be able break up the QR public key payloads across multiple message exchanges, then do we have to add some mechanism for the endpoints to agree on the maximum size of each message? Declaring a chunk size as part of the spec may not be a good idea because some QR public keys are ~1.5Kb while others are >64Kb. So picking a small chunk size to avoid IKEv2 fragmentation means many message exchanges when using large key sizes, but picking large chunk sizes increases the changes of dropping IKEv2 fragments and having to retransmit entire messages.

—

---

From: Cen Jung Tjhai <[email-masked]>
Date: Wed, 9 Aug 2017 18:59:37 +0000

>>which QSKE we are talking about.

Another reason for not removing KE is potentially due to FIPS requirement. According to NIST (http://csrc.nist.gov/groups/ST/post-quantum-crypto/faq.html#Q1), if we have a hybrid key exchange, i.e. KE + post-quantum KE, the KE part can still go through FIPS validation and can still be FIPS-certified (until FIPS covers post-quantum algorithms).

While draft-00 makes some references to a few post-quantum algorithms, we think one should think of the draft as providing a framework on how to exchange post-quantum blobs. We are currently updating the draft to remove references to these algorithms in the main text.

It’s best to let standardization bodies to come up with standards for post-quantum algorithms.

---

From: Cen Jung Tjhai <[email-masked]>
Date: Wed, 9 Aug 2017 19:30:46 +0000

>>> initiator->responder direction?

I believe Daniel has touched on this. But let me add more information on this specific query. There are two kinds key-exchange mechanism for post-quantum algorithms, namely Diffie-Hellman-like and KEM. For DH-like, from what we investigated so far, the public data is pretty much of equal size for both directions. On the hand, for KEM, this could be very asymmetric. The blob sent by the initiator to responder could be 1MB in size, and this is the public-key of the initiator. The responder then needs to sample some random data, encrypt it and send it back to the responder. The size of this ciphertext could well just be 1KB. Because the size of this ciphertext is dependent on the size of the random data, a KEM algorithm may need to specify the size of the random data. It could be similar to the case of ENCR where there is an attribute to specify the key size, or it could be fixed.

In both cases, once the parameters are agreed, the blob size is known in advance.

CJ

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 14 Aug 2017 16:03:09 +0300

Daniel Van Geest writes:
> 1) QS SA Negotiation
> 
> When negotiating a QS SA, it’s not enough to negotiate QS key
> agreement algorithm(s), one also has to ensure that the algorithms
> selected by the other transform types are also QS.

All of these kind of issues are really policy matters, thus outside
the PROTOCOL work. I.e., we can add security considerations section
text saying, that when using QS key agreement algorithm, other
algorithms needs to be considered too. I do not see any reason for
making any hard rules. 

> I don’t find the re-use of transform 4 in this proposal, and the implicit combination of QS +
> non-QS algorithms, to be the most elegant, though I can understand it in the context of not
> wanting to add a new transform type.

Adding new transform types is bit painfull, mostly because if you want
to allow old implementations to connect, you need to have two
proposals, one with new transform type and another without.

The responder MUST pick exactly one algorithm for each transform type
the initiator send, and if it does not understand transform type (thus
will not be able to pick any), it MUST ignore the specific proposal.
This means that for backwards compatibility there needs to be two
proposals, or 3/4 if AEAD algorithms are also needed. This will make
IKE_SA_INIT larger.

On the other hand this is ONLY needed if the initiator DOES NOT know
whether other end supports QS or not. Usually initiator can be
configured to assume either way, it is more important to configure the
responder so it will accept either QS or non-QS...

Anyways this is something we need to decided, and there are different
kind of tradeoffs with different proposals.

> proposal, but don’t include it in the SA payload. Rather, introduce
> a new QS_SA payload which would be identical in structure to the SA
> type.

I think creating QS_SA is bad idea. First of all, I assume there are
implementations which will break when there is unknown payload
included in the exchange. Secondly this will require even more space
than adding 2nd proposal in the SA payload, thus adding new transform
type and two proposals is more efficient encoding. Thirdly there might
be policy mismatch issues, i.e., cases where the SA and QS_SA
algorithms do not match, and that might cause issues also.

And lastly this will break the base IKE_SA_INit exchange payload
listing, i.e., currently we assume that we send one SA payload and
receive one SA payload back. Implementations quite often do sanity
check very early in the processing to verify that all needed payloads
are included, and this will break it. 

> Also note that StrongSwan’s code assumes that IKE_AUTH will always
> have a message ID of 1, but this won’t hold if there are one or more
> PRE_AUTH exchanges.

That also does not hold for cases where EAP is used, where IKE_AUTH is
message IDs 1, 2, ...., n. The text in section 2.2 talking about the
message IDs in IKE_AUTH is descriptive, i.e., it describes normal
behavior, it is not normative, and if any implementation assumes
IKE_AUTH will have message ID 1, it is broken.

> Couldn’t the IDi and IDr payloads in IKE_AUTH be modified to sign
> the PRE_AUTH message in addition to the IKE_SA_INIT message?

They could be, that that would again change the basic crypto
calculations done by the IKE library, and if we do not need to touch
it, it is better. I.e., if the result of the PRE_AUTH is authenticated
in some other ways (for example because the QS key exchange protocol
run there generates keys, which we use later), then we might not
need to add specific authentication step for them.

I was mostly just stating what the current text describes. I.e., the
RFC7296 text as written in section 2.15 will not authenticate those
messages unless we modify that. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 14 Aug 2017 16:05:21 +0300

> I think that unknown transform types will be ignored by compliant

Nope. It will ignore unknown transform IDs for each known transform
type, but it MUST understand each transform type, and if it does not
understand it cannot pick one value for it, thus it must ignore the
whole proposal, and try to use other proposals which might work
better. 
-- 
[email-masked]

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 14 Aug 2017 13:47:13 +0000

> -----Original Message-----
> From: IPsec [mailto:[email-masked]] On Behalf Of Tero Kivinen
> Sent: Monday, August 14, 2017 9:05 AM
> To: Michael Richardson
> Cc: [email-masked]; Daniel Van Geest; Graham Bartlett (grbartle)
> Nope. It will ignore unknown transform IDs for each known transform type,
> but it MUST understand each transform type, and if it does not understand it
> cannot pick one value for it, thus it must ignore the whole proposal, and try
> to use other proposals which might work better.

Actually, where in RFC5996 (or 4301) does it say that it must go on to the next proposal , rather than (say) silently rejecting the entire negotiation?  I searched through the text, and cannot find a MUST (or even a SHOULD) statement...

And, in the 11+ years since IKEv2 has been defined, we haven't added a single transform type.  I would suspect that most implementations have never tested out the scenario where they've seen an unexpected transform type (but which is followed by another proposal which is acceptable).  How certain are we that implementations will process the request as we hope?

After all, a large point of this exercise is backwards compability; if a QR IKEv2 initiator tries to talk to a nonupgraded IKEv2 responder, it works as we expect (that is, depends on the initiator's security policy, they either downgrade to a non-QR key exchange, or they abort the exchange as they had no mutually acceptable policy).  Hence, the actual behavior of real nonupgraded responders is important.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Aug 2017 17:20:44 -0400

> the PROTOCOL work. I.e., we can add security considerations section

I agree.

    > responder so it will accept either QS or non-QS...

I think that one goes around and enables the new QS policy in nodes as one
upgrades them to have QS.  An implementation could have a policy knob like:
         QS=forbid,accept,propose,insist
         (a bit like MUSTNOT,MAY,SHOULD,MUST)

which would add the extra proposals.  One starts with "QS=accept" or
"QS=propose", which so that one can interoperate with nodes which have not
yet been upgraded, and then perhaps moves to QS=insist.

I think we are in agreement here, just want to be clear I'm not disagreeing.
One only needs the huge SA_INIT during the transition period between
QS=propose to QS=insist.  Still that could be many months to even years.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 22 Aug 2017 11:35:03 +0300

Hi,

> Another reason for not removing KE is potentially due to FIPS requirement. According to NIST
> (http://csrc.nist.gov/groups/ST/post-quantum-crypto/faq.html#Q1), if we have a hybrid key exchange, i.e. KE
> + post-quantum KE, the KE part can still go through FIPS validation and can still be FIPS-certified (until FIPS
> covers post-quantum algorithms).

Well, that are valid reasons. However, what makes me uncomfortable is that this design looks like yet another
short-term (or medium-term) solution. We already have draft-fluhrer-qr-ikev2 that was declared as 
a temporary short-term approach to countermeasure immediate threat until cryptography science gives us 
new well-studied QC-proof primitives to replace classic public key cryptography. Now it turns out that we don't have 
primitives we are certain in (at least for key exchange), so we decide to combine several different primitives
(which we don't fully trust in) with classic DH. That's a valid approach for transition to PQ cryptography,
but it doesn't look like long-term standard solution.

What particularly makes me unhappy:
- the design looks like violation of the "gold rule" of cryptography - "don't combine several week primitives, it doesn't add 
   to security, instead use one strong primitive" (I understand that each rule has exceptions, so that's probably the case, but still)
- when (and if) workable QC appears, the classic DH exchange will provide zero security, but will still consume resources,
   that will just be wasted. And the proposed design doesn't allow to get rid of DH completely, so the resulting
   protocol will be inefficient. 

So we end up with yet another temporary solution. That's not good.

Regards,
Valery.

---

From: Cen Jung Tjhai <[email-masked]>
Date: Tue, 22 Aug 2017 10:42:58 +0000

Hi

>> Well, that are valid reasons. However, what makes me uncomfortable is that this design 
>> looks like yet another short-term (or medium-term) solution. We already have 
>> draft-fluhrer-qr-ikev2 that was declared as a temporary short-term approach to countermeasure
>> immediate threat until cryptography science gives us new well-studied QC-proof primitives to
>> replace classic public key cryptography. Now it turns out that we don't have primitives we 
>> are certain in (at least for key exchange), so we decide to combine several different 
>> primitives (which we don't fully trust in) with classic DH. That's a valid approach for 
>> transition to PQ cryptography, but it doesn't look like long-term standard solution.

On our draft-00, one of the objectives is to deprecate DH key exchange in the long-term future. Hence, we thought it would be neater to introduce a new transform type and a new PQ key exchange payload (QSKE). The idea is that when people are happy to drop KE payloads, they can use QSKE payloads instead. Obviously, there are concerns with backward compatibility by introducing a new transform type, which I agree.

However, the issue with large payload size of post-quantum key exchange needs to be resolved regardless. Hence, the discussion has been focused on this since.

Is KE payload mandatory? One thing that we thought about is to use keep KE payload and exchange post-quantum blobs in this payload and use a bit of the reserved field to indicate that this is a large payload that potentially needs to be treated differently. In this way, there is no need use another KE payload but there could be issue with multiple KEs in IKE_SA_INIT when both classic and PQ KE primitive are used.

>>    - the design looks like violation of the "gold rule" of cryptography - "don't combine 
>> several week primitives, it doesn't add to security, instead use one strong primitive" 
>> (I understand that each rule has exceptions, so that's probably the case, but still)

Before people are happy with PQ algorithms, it is acceptable to combine classic and PQ, as the security of IKE is not weaken. 

>>    - when (and if) workable QC appears, the classic DH exchange will provide zero security, 
>> but will still consume resources, that will just be wasted. And the proposed design doesn't 
>> allow to get rid of DH completely, so the resulting protocol will be inefficient. 
>>    

I totally agree with you on inefficiency issue here, but having DH may not decrease security. It would be great to hear from the WG whether we should look into the needs in dropping DH at this stage.

Best regards,
CJ

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 22 Aug 2017 14:31:04 +0000

> From: IPsec [mailto:[email-masked]] On Behalf Of Cen Jung Tjhai
> Sent: Tuesday, August 22, 2017 6:43 AM
> To: Valery Smyslov; 'Tero Kivinen'
> Cc: [email-masked]
> >> Well, that are valid reasons. However, what makes me uncomfortable is
> >> that this design looks like yet another short-term (or medium-term)
> >> solution. We already have
> >> draft-fluhrer-qr-ikev2 that was declared as a temporary short-term
> >> approach to countermeasure immediate threat until cryptography
> >> science gives us new well-studied QC-proof primitives to replace
> >> classic public key cryptography. Now it turns out that we don't have
> >> primitives we are certain in (at least for key exchange), so we
> >> decide to combine several different primitives (which we don't fully trust
> in) with classic DH. That's a valid approach for transition to PQ cryptography,
> On our draft-00, one of the objectives is to deprecate DH key exchange in
> the long-term future. Hence, we thought it would be neater to introduce a
> new transform type and a new PQ key exchange payload (QSKE). The idea is
> that when people are happy to drop KE payloads, they can use QSKE
> payloads instead. Obviously, there are concerns with backward compatibility
> by introducing a new transform type, which I agree.

If we look at the general problem, I see that there are three subproblems that we need to solve:

1. How to introduce a postquantum key exchange to IKE

2. How to have the postquantum key exchange in addition to the classical (EC)DH (so that we can't make security worse)

3. How to handle the greater-than-MTU payloads that are likely to result

(and, of course, how to handle this all in a backwards-compatible way, which minimizes additional complexity, and which allows us to deprecate traditional DH Keyexchanges eventually).

Much of our discussion has been on #3 (which is, indeed, the hardest of the three), however I would like to discuss #1 and #2.

Draft-00 solves #1 by adding a new payload type; one issue with this is, because of the new transform type to negotiate it, existing IKE responders may be confused by it.  They do solve #2 for free (because it's in parallel with the existing KE payloads).

I would suggest a different way; instead of assigning a key payload type, we just issue new group descriptions for the postquantum key exchanges; the traditional 2048 MODP group is 14; we might make NewHope number 32.

One objection to this may to say "but, NewHope isn't a group"; actually, that's just terminology.  As far as the protocol is concerned, all these key exchanges do fundamentally the same thing; the initiator creates a payload and sends it to the responder; the responder then generates a payload and sends it to the initiator; both sides do some computation and create a shared secret (that someone in the middle cannot derive just seeing the payloads).  There are distinctions between the key exchanges (sometimes the intiiator's and responder's keyshares are of different lengths; sometimes the responder's keyshare is a function of the initiator's), but those are distinctions that the protocol doesn't have to care about.

I would argue that this minimizes complexity (the protocol parts of IKE implementations wouldn't have to change at all), and we have good backwards compatibility (as existing IKE implementations already know how to deal with groups they haven't heard of).  However, as it stands, it doesn't address #2 at all.

To solve that, I would suggest adding a way to exchange multiple groups in parallel (and have the shared secret depend on all of them); that way, we can perform both an ECDH (so we're at least as secure as now) and a NewHope exchange (so we have a potential to be secure against a quantum computer).  Ideally, we would be able to allow more than 2 (as some users might not want to trust just one of these new-fangled PQ key exchanges; it would be good if we could give them the option, without adding much complexity on our side).

Here is one possible way to do this; we assign group descriptions 0x7f00-0x7fff (the high end of the IANA unassigned list) to be dynamically assigned by the initiator.  That is, the initiator could include a notify that may specify "group 7f00 is really group 14 and group 32 concatinated", he can then include that within his policy (and the resulting key share would be the group 14 and the group 32 key share concatenated); the responder can either accept this, or reject it in favor of another proposal (just as the current IKE allows fallback to other DH groups).

The idea here is that we try to reuse as much of the existing KE protocol logic (and security logic) as possible; by reusing this logic, we avoid adding complexity, and we also rely on the same security logic that makes the current KE exchange safe.

So, in summary, this idea:

- Allows us to rely on postquantum key exchanges (once they have been defined and accepted)
- Allows us to also rely on traditional groups as well (so we don't make things worse)
- Is backwards compatible (in that someone proposing this to an unupgraded responder will react in the expected way; either downgrading the key exchange, or rejecting the key exchange, based on the initiator policy)
- Allows a clean way to deprecate traditional groups in the future
- Allows someone to rely on multiple postquantum key exchanges, should they be paranoid.
- Does all this while trying to minimize complexity (most of the changes in the implementation will be in the crypto engine and the policy handling; those would have to change in any such solution)

Thoughts?

Credit: this idea was worked out in conjunction with Oscar Garcia-Morchon, Zhenfei Zhang and William Whyte; this idea applied to TLS can be found in draft-whyte-qsh-tls13

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Tue, 22 Aug 2017 15:03:17 +0000

Hi Tero

So I’m not a big fan of the interim exchange (Scott had suggested something similar).

I would imagine that it’s going to decrease the tunnel setup rate on VPN GW’s.

Adds at minimum another round trip, which could be >two if the QS blob isn’t correct or many more if fragmentation.

It seems to be a large change to what’s there today.

Does not allow for a 1-1 swap for the DH value today to something that is QS.

On a more positive note I like the idea of the incrementing message ID’s for re-transmissions. I had a similar idea myself ☺

As mentioned before, if the issue is with sending these QS blobs is the size. At the moment CJ has given some indication of the sizes, however what is going to be used isn’t decided. 

With regards to sending the QS blob using IKEv2 fragmentation. Unless this is sent after authentication occurs it still allows for an attack whereby someone can send up to 

 HDR(PRE_AUTH, MID=1),
           SKF(NextPld=0, Frag#=m-1, TotalFrags=m)

To exhaust the receivers buffers..

cheers

On 09/08/2017, 11:08, "IPsec on behalf of Tero Kivinen" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Initiator                         Responder

       HDR(PRE_AUTH, MID=1),

       HDR(IKE_AUTH, MID=2),