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

[Cen Jung Tjhai <[e-mail]>]

Hi Paul,

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

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

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

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.

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

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. 

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

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. 

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

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. 


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

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.

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

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

Best regards,
CJ