Subject: [IPsec] Feedback on November 7 QSKE interop testing event

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 27 Nov 2019 16:55:17 +0300

Hi,

at the ipsecme meeting at IETF106 I was asked by the chairs to send feedback to the list 
on QSKE interoperability testing event that took place on November 7.

The slides about this event are available here:
https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-hybrid-qske-for-ikev2-interoperability-testing-event-01

The event was organized by Secunet. There were 3 active participants (strongSwan, QuaSiModO and ELVIS-PLUS)
and few observers. We tested initial IKE SA setup using multiple key exchanges according to 
draft-tjhai-ipsecme-hybrid-qske-ikev2-04. Rekeying wasn't tested since only one
implementation supported it.

The results are: 
- strongSwan and ELVIS+ were able to establish SA using three classical DH exchanges. 
- strongSwan and QuaSiModO performed hybrid key exchange with classical DH + post-quantum KE (newHope);
   the key exchange itself was successful, but SA wasn't established due to incorrect AUTH calculation.

There was some discussion about the draft and its possible implementations.
First, the stable code points are badly needed, at least for IKE_INTERMEDIATE.
I've already requested early code points assignments for IKE_INTERMEDIATE, 
so hopefully this issue will soon be resolved.
Then, there were some discussion on how rekey must be done. The conclusion
was that using a new dedicated exchange for follow-up key exchanges is much 
better than re-using INFORMATIONAL. This was already discussed among the 
draft authors and we agree that it's a right way to go. Some concerns were 
also expressed about using nonces in each additional KE instead of re-using a 
pair of nonces from IKE_SA_INIT (or CREATE_CHILD_SA). I think it's a good
idea and we probably follow this way after we discuss the security 
implications of it among the authos.
Some vendors that haven't yet implemented the draft expressed an intent
to do it once the specification becomes more stable (preferably - becomes an RFC).

Event participants are in CC of this message, so they can correct
me if I was inaccurate in its description or forgot to mention something important.

Regards,
Valery.