I am not sure we can use a config that says
IP address X -> ML-KEM mandatory.
We need the identity from IKE_AUTH to check against it and enforce ML-KEM.

From: Blumenthal, Uri - 0553 - MITLL <[email protected]>
Sent: Wednesday, May 21, 2025 12:34 AM
To: Kampanakis, Panos <[email protected]>
Cc: Christopher Patton <[email protected]>; Valery Smyslov 
<[email protected]>; [email protected]
Subject: RE: [EXTERNAL] [EXT] [IPsec] Re: Binding properties of 
draft-ietf-ipsecme-ikev2-mlkem-00

Why would you trust “full identity” that’s been authenticated by Classic means?
—
Regards,
Uri

Secure Resilient Systems and Technologies
MIT Lincoln Laboratory


On May 21, 2025, at 09:40, Kampanakis, Panos 
<[email protected]<mailto:[email protected]>> 
wrote:

I fleshed out the details of this approach a bit in https: //github. 
com/csosto-pk/pq-mlkem-ikev2/issues/5#issuecomment-2896485221 Basically you 
don’t do IKE_INTERMEDIATE at all, you do all classical and immediately rekey 
the SA and the Child
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

This message came from outside the Laboratory.



ZjQcmQRYFpfptBannerEnd
I fleshed out the details of this approach a bit in 
https://github.com/csosto-pk/pq-mlkem-ikev2/issues/5#issuecomment-2896485221

Basically you don’t do IKE_INTERMEDIATE at all, you do all classical and 
immediately rekey the SA and the Child SA (if already negotiated) with 
IKE_FOLLOWUP_KE which means that your SKEYSEED and SKEYMAT and all other keys 
that protect data are quantum-resistant. We do all that because at the time of 
IKE_FOLLOWUP_KE we have the full identity of the peer and thus can enforce the 
config that says “I expect Peer X to be upgraded and thus must use ML-KEM”. 
Note the messages and rekeys etc are already supported in RFC9370, we are not 
doing anything exotic. We just use the new configuration flag to enforce the 
“use ML-KEM requirement” by using the right messages. I think this is a simpler 
approach than introducing a new notification N(MAC more things) which both 
peers need to support.

Feedback from the whole WG is welcome.

_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to