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 <cpat...@cloudflare.com> Sent: Wednesday, July 30, 2025 11:11 AM To: Jun Hu (Nokia) <jun...@nokia.com> Cc: Michael Richardson <mcr+i...@sandelman.ca>; Valery Smyslov <smyslov.i...@gmail.com>; Scott Fluhrer (sfluhrer) <sfluh...@cisco.com>; ipsec <ipsec@ietf.org> 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) <jun...@nokia.com<mailto:jun...@nokia.com>> 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 <mcr+i...@sandelman.ca<mailto:mcr%2bi...@sandelman.ca>> Cc: Valery Smyslov <smyslov.i...@gmail.com<mailto:smyslov.i...@gmail.com>>; 'Christopher Patton' <cpat...@cloudflare.com<mailto:cpat...@cloudflare.com>>; 'Scott Fluhrer (sfluhrer)' <sfluh...@cisco.com<mailto:sfluh...@cisco.com>>; 'ipsec' <ipsec@ietf.org<mailto:ipsec@ietf.org>> 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/>=40nokia....@dmarc.ietf.org<mailto:40nokia....@dmarc.ietf.org>> 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 <mcr+i...@sandelman.ca<mailto:mcr%2bi...@sandelman.ca>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
