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]
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
