Hi all, Apologies for the immediate follow-up. In my previous message, erroneously assigning the quoted text to Andrew.
To correct the record, it was Michael who raised this objection. Here is the properly formatted reply: Michael Richardson <[email protected]> wrote: > How can it do that when it hasn't got an encrypted SA? > To get encrypted, you have to do the KEM too. According to RFC 7296 and RFC 9242 (Section 3), the symmetric crypto keys (SK_e/SK_a) are derived immediately after the IKE_SA_INIT exchange. This is why any subsequent messages—whether they are IKE_INTERMEDIATE or IKE_AUTH—are already strictly encapsulated within an Encrypted (SK) payload (structured as HDR, SK {...}) on the wire. The additional KEMs running inside IKE_INTERMEDIATE are for augmenting quantum resistance, not for enabling initial encryption. Therefore, at the identity junction of IKE_AUTH, the responder absolutely possesses the valid SK_e/SK_a keys to reply with a symmetrically encrypted COLLISION_ABORT notification, successfully protecting the packet from spoofing while bypassing the asymmetric PQC signing. Best regards, Wang Xi -----Original Message----- From: Wang Xi Sent: Thursday, September 3, 2026 2:38 PM To: 'Michael Richardson' <[email protected]>; Andrew Cagney <[email protected]>; Valery Smyslov <[email protected]>; Wang Xi <[email protected]>; IPsec WG <[email protected]> Subject: RE: [IPsec] Re: fail Child SA with TEMPORARY_FAILURE response during IKE_AUTH Andrew Cagney <[email protected]> wrote: > How can it do that when it hasn't got an encrypted SA? > To get encrypted, you have to do the KEM too. According to RFC 7296 and RFC 9242 (Section 3), the symmetric crypto keys (SK_e/SK_a) are derived immediately after the IKE_SA_INIT exchange. This is why any subsequent messages—whether they are IKE_INTERMEDIATE or IKE_AUTH—are already strictly encapsulated within an Encrypted (SK) payload (structured as HDR, SK {...}) on the wire. The additional KEMs running inside IKE_INTERMEDIATE are for augmenting quantum resistance, not for enabling initial encryption. Therefore, at the identity junction of IKE_AUTH, the responder absolutely possesses the valid SK_e/SK_a keys to reply with a symmetrically encrypted COLLISION_ABORT notification, successfully protecting the packet from spoofing while bypassing the asymmetric PQC signing. Best regards, Wang Xi -----Original Message----- From: Michael Richardson <[email protected]> Sent: Thursday, September 3, 2026 9:41 AM To: Wang Xi <[email protected]>; Andrew Cagney <[email protected]>; Valery Smyslov <[email protected]>; Wang Xi <[email protected]>; IPsec WG <[email protected]> Subject: Re: [IPsec] Re: fail Child SA with TEMPORARY_FAILURE response during IKE_AUTH Wang Xi <[email protected]> wrote: > Thanks for the insights. Glad to hear we are aligned on keeping this > purely within the application layer > If we strictly wait for the response to arrive as per RFC 7296, the > responder (the loser) is still forced to execute the heavy PQC signing > just to generate that doomed response. This completely defeats the > purpose of mitigating PQC overhead. Yes, this is a problem for a responder that sees that the SA in question will not be the winning SA. If the initiator doesn't implement the sensible heuristic I am proposing, the responders only real choice here is to discard the packet, and risk retransmission. (If the SA *would* be the winning SA, then the responder should stop/delay the SA it is initiating, and it should do the signature...) > To solve this without breaking the state machine or risking a spoofing > DoS, I am NOT suggesting a standard DELETE payload. Instead, once the > responder verifies the collision via local identity checks, it should > reply with an encrypted, lightweight COLLISION_ABORT Notify Payload > using the IKE_SA_INIT keys, and instantly tear down the state. How can it do that when it hasn't got an encrypted SA? To get encrypted, you have to do the KEM too. > To be precise, this mechanism does not eliminate 100% of the PQC > overhead, as the initiator has already computed and sent its initial > IKE_AUTH request. However, it completely saves the responder from > running the heavy asymmetric PQC signing for the response. Since the > reply comes from the responder, it perfectly honors the standard > Request-Response flow, while successfully shielding the responder's > CPU. I think, responsder can just unilaterally protect its CPU by dropping traffic. Maybe it's time for the puzzles to return. A long time ago, that's how FreeS/WAN protected itself against IKEv1 aggressive mode. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ** My working hours and your working hours may be different. ** ** Please do not feel obligated to reply outside your normal working hours ** *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. *** _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
