Ok, the attack with this procedure could work, however from Y point of view it is talking with A instead of X, so if there are additional actions on Y tied to peer’s ID, for example if Y install some firewall/ACL rules based on IDi, and only X is allowed to access some backend service via the installed firewall/ACL rule, this attack won’t get around that.
And beside configure properly, another mitigation against this attack without introducing new protocol changes is just Y mandate use of PPK (RFC8784). From: Christopher Patton <[email protected]> Sent: Wednesday, July 30, 2025 11:11 AM To: Jun Hu (Nokia) <[email protected]> Cc: Michael Richardson <[email protected]>; Valery Smyslov <[email protected]>; Scott Fluhrer (sfluhrer) <[email protected]>; ipsec <[email protected]> Subject: Re: [IPsec] Re: draft-smyslov-ipsecme-ikev2-downgrade-prevention CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Jun, you're correct ... the attack isn't specific to PQ. It takes advantage of the presence of a weak key exchange method, regardless of whether the attacker uses a CRQC to break it. But to answer your earlier question, the attack doesn't require re-signing the IKE_AUTH message from Y. The exact steps of the attack are: 1. X sends initiator IKE_INIT_SA to A 2. A rewrites initiator IKE_INIT_SA by dropping support for the strong key exchange and sends it to Y 3. Y sends responder IKE_INIT_SA to A 4. A sends (unmodified) responder IKE_INIT_SA to X 5. X sends initiator IKE_AUTH to A 6. A decrypts IKE_AUTH (by breaking the weak key exchange), signs it with A's key, re-encrypts it, and sends it to Y 7. Y sends responder IKE_AUTH to A 8. A sends (unmodified) responder IKE_AUTH to X Here's the key: the victim responder Y only signs its own outbound messages, so even though X and Y have a split view of the handshake transcript, they never actually confirm this. Y would have sent the same IKE_AUTH in its conversation with A as it would have in its conversation with X. Chris P. On Wed, Jul 30, 2025 at 2:09 PM Jun Hu (Nokia) <[email protected]<mailto:[email protected]>> wrote: Sorry, I need rephrase that, the attack doesn't rely on a CRQC could break a digital signature in live communication -----Original Message----- From: Jun Hu (Nokia) Sent: Wednesday, July 30, 2025 11:08 AM To: Michael Richardson <[email protected]<mailto:mcr%[email protected]>> Cc: Valery Smyslov <[email protected]<mailto:[email protected]>>; 'Christopher Patton' <[email protected]<mailto:[email protected]>>; 'Scott Fluhrer (sfluhrer)' <[email protected]<mailto:[email protected]>>; 'ipsec' <[email protected]<mailto:[email protected]>> Subject: RE: [IPsec] Re: draft-smyslov-ipsecme-ikev2-downgrade-prevention [HJ] sure, but my understanding is the attack we are discussing here doesn't rely on a CRQC Jun Hu \(Nokia\) <jun.hu<http://jun.hu/>[email protected]<mailto:[email protected]>> wrote: > So if A just passthrough Y's certificate payload to X in the IKE_AUTH > response A sent to X, how could A signs the AUTH payload without having > Y's private key that corresponds to Y's certificate? The CRQC was able to break the quantum-unsafe algorithm, turning a public key into a private key. (That's the point of the CRQC) -- Michael Richardson <[email protected]<mailto:mcr%[email protected]>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
