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

["Valery Smyslov" <[e-mail]>]

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:[e-mail]] On Behalf Of Graham Bartlett (grbartle)
Sent: Thursday, August 03, 2017 2:57 PM
To: [e-mail]
Subject: [IPsec] Proposed method to achieve quantum resistant IKEv2

 

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> 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}  -->

 

 

———————