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

[Paul Wouters <[e-mail]>]

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,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)

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