> On Sep 3, 2026, at 19:45, Wang Xi <[email protected]> wrote: > > On Thu, 3 Sep 2026, Paul Wouters wrote: > >> I still don't understand what you are trying to say. As others said, until >> you have authenticated both IKE SAs and verified they have the same Traffic >> Selectors, you have to continue with the negotiation. >> >> And once you have gotten that far, on the responder you might be able to >> send a custom error message and fail the child sa (although should you then >> not keep the 2nd IKE SA around, or send a delete for it), on the initiator >> the if you need to abort it, you need to finish all computations (including >> authentication) and then send an Informational Exchange with the delete in >> it. >> >> So I don't see where we can avoid expensive computations in these cases. > > > My thought is that the negotiation does not need to continue once the > responder receives the initial IKE_AUTH request and determines that its local > parallel session wins. > > In the incoming IKE_AUTH message, the responder can immediately see the > peer's identity (IDi) via symmetric decryption. At this exact identity > junction, the losing responder knows exactly who the peer is
No, it knows who the peer claims to be. Until you completely process the AUTH payload, you have no proof. > and can verify the collision against its own winning parallel outbound > session. > > At this point, instead of executing the heavy asymmetric PQC signing for a > doomed response, the losing responder just needs to reply with a lightweight > ABORT notification using the symmetric keys derived from IKE_SA_INIT, and > then instantly tear down the state. This completely saves one expensive PQC > signing on the responder side. That message cannot be responded to without also authenticating yourself or the other end can’t know for its the real you. Additionally, it’s the Key Exchange that is expensive, the AUTH generation / verification is almost negligible in comparison. Paul > > Best regards, > Wang Xi > > -----Original Message----- > From: Paul Wouters <[email protected]> > Sent: Thursday, September 3, 2026 3:11 PM > To: Wang Xi <[email protected]> > Cc: Michael Richardson <[email protected]>; Andrew Cagney > <[email protected]>; Valery Smyslov <[email protected]>; IPsec WG > <[email protected]> > Subject: Re: [IPsec] Re: fail Child SA with TEMPORARY_FAILURE response during > IKE_AUTH > > ALERT : This message originated outside of the Fortinet network. BE CAUTIOUS > before clicking any link or opening an attachment. > > >> On Thu, 3 Sep 2026, Wang Xi wrote: >> >> 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. > > I still don't understand what you are trying to say. As others said, until > you have authenticated both IKE SAs and verified they have the same Traffic > Selectors, you have to continue with the negotiation. > > And once you have gotten that far, on the responder you might be able to send > a custom error message and fail the child sa (although should you then not > keep the 2nd IKE SA around, or send a delete for it), on the initiator the if > you need to abort it, you need to finish all computations (including > authentication) and then send an Informational Exchange with the delete in it. > > So I don't see where we can avoid expensive computations in these cases. > > Paul > >> 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] >> > > > > *** 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] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
