Subject: [IPsec] Re: WGLC for draft-ietf-ipsecme-ikev2-mlkem
From: "Kampanakis, Panos" <[email-masked]>
To: Valery Smyslov <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 13 Sep 2025 04:15:38 +0000
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>

Thanks again Valery. This https://github.com/csosto-pk/pq-mlkem-ikev2/commit/0cc0b25d2d8613c554b09f5cbfbc6da3ca658924 should cover it. 

-----Original Message-----
From: Valery Smyslov <[email-masked]> 
Sent: Wednesday, September 10, 2025 2:56 AM
To: Kampanakis, Panos <[email-masked]>; [email-masked]
Subject: RE: [EXTERNAL] [IPsec] WGLC for draft-ietf-ipsecme-ikev2-mlkem

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Hi Panos,

> Hi Valery, thank you.
>
> I incorporated all of these in https://github.com/csosto-pk/pq-mlkem-
> ikev2/commit/b627d392eaccd3ee1f82e77ac618867ee2358efa (minor some nits which I fixed afterwards).

thank you for this update. I think we are almost there. Just a few more concerns, please see below.

> Note I trimmed down the last paragraph of the Sec Considerations as 
> suggested but I did not remove it. I wanted to keep the option for 
> cases where the initiators and responder must co-exist with legacy and 
> there is predistributed knowledge of the identities that have been upgraded. It is not a flexible option, but I wanted to lay out the option for large deployments.

OK.

> Also, please confirm that you are OK with the existing text.
>
> > If the checks fail, the responder SHOULD send a Notify payload of 
> > type INVALID_SYNTAX as a response to the request from initiator.

This is OK.

> which I kept as is.

Regarding the text:

        <xref target="I-D.ietf-ipsecme-ikev2-qr-alt"> also enables a negotiation of PPK and ML-KEM
        in a single message without an aditional round-trip penalty.

I think that it somewhat lacks a context for readers (my fault, I was too brief proposing it).
I propose to use the following text (something along the lines):

        As alternative, <xref target="I-D.ietf-ipsecme-ikev2-qr-alt"> can also be used for mixing
        pre-shared keys in IKEv2, as it provides better security properties than <xref target="RFC8784" />
        and, since negotiation of PPK can be combined with additional key exchange performing ML-KEM,
        extra round trip penalty can be avoided.

Regarding the text:

        Afterwards the peers can perform more IKE_INTERMEDIATE key exchanges if necessary
        and then continue to the IKE_AUTH exchange [...]

Please, remove "key" from this sentence - IKE_INTERMEDIATE exchanges can be used for various purposes besides key exchange.

Regarding the text:

        The initiator <bcp14>MAY</bcp14> also send a Delete Payload in a new INFORMATIONAL
        exchange for the responder to remove the SA.

This needs a clarification. If the error occurs before IKE SA is created (i.e. in the IKE_INTERMEDIATE), then the initiator cannot start INFORMATIONAL exchange with Delete payload - it just does not have session keys yet. It can start unprotected INFORMATIONAL, but it will be ignored by responder.
Thus, it is not possible to (and there is no point) to do this in this case.

On the other hand, if the error occurs in the IKE_FOLLOWP_KE during a rekey or establishing an additional Child SA, then the Initiator can delete existing IKE SA in this case.
I believe that it even MUST do this: otherwise some unpleasant situations may happen, if, for example, the error occurs in the last IKE_FOLLOWP_KE message, so that the responder has already created a new SA. In this case the initiator must delete the current IKE SA. And if this was an IKE SA rekey, then the initiator should also delete a new IKE SA, but it cannot - due to the error it cannot calculate the keys for a new IKE SA. This is unpleasant situation for which  IKEv2 provides no good ways to recover from (it may happen even in base IKEv2 with sole CREATE_CHILD_SA).
The only way to recover is to start creating IKE SA from scratch sending INITIAL_CONTACT.

I don't think all these speculations must be in the draft, just clarify, that in case the error occurs in the CREATE_CHILD_SA or IKE_FOLLOWUP_KE exchanges, then the initiator MUST delete existing IKE SA by sending a Delete payload in a new INFORMATIONAL exchange.

(similar text is present in the draft, but is commented out).

Regards,
Valery.

> -----Original Message-----
> From: Valery Smyslov <[email-masked]>
> Sent: Thursday, August 28, 2025 4:40 AM
> To: 'Tero Kivinen' <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Subject: RE: [EXTERNAL] [IPsec] WGLC for 
> draft-ietf-ipsecme-ikev2-mlkem
>
> CAUTION: This email originated from outside of the organization. Do 
> not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> Hi,
>
> I read the document and I think it is ready for publication.
> I also strongly believe that it is the time to request official code points from IANA.
>
> There are still some issues that should be addressed before requesting of publication.
>
> 1. Abstract.
>
> The abstract is not consistent with the body of the document - it only 
> talks about using ML-KEM as an additional KE method, while the document allows both standalone and hybrid use of ML-KEM.
>
> 2. Section 1.
>
>    To address this concern, the Mixing Preshared Keys in IKEv2
>    specification [RFC8784] introduced Post-quantum Preshared Keys as a
>    temporary option for stirring a pre-shared key of adequate entropy in
>    the derived Child SA encryption keys in order to provide quantum-
>    resistance.  This specification can be used in conjunction with PPK
>    as defined in [RFC8784].
>
> I think that draft-ietf-ipsecme-ikev2-qr-alt should also be referenced 
> in this para, as it has advantages over
> RFC8784 and is even more suited for use with hybrid PQ KE, since 
> negotiation of PPK and ML-KEM KE can be combined in a single IKE_INTERMEDIATE - no additional round trip penalty.
>
> 3. Section 1.2.
>
>    ML-KEM-512, ML-KEM-768 and ML-KEM-1024 key exchanges will not have
>    material performance impact on IKEv2/IPsec tunnels which usually stay
>    up for long periods of time and transfer sizable amounts of data.
>
> Perhaps s/material/significant? Or noticeable?
>
> 4. Section 2.1.
>
>    Afterwards the peers continue to the
>    IKE_AUTH exchange phase as defined in Section 3.3.2 of the
>    Intermediate Exchange in IKEv2 specification [RFC9242].
>
> This sentence must be corrected since peers may have more 
> IKE_INTERMEDIATE exchanges to perform after completing the one with ML-KEM before going to IKE_AUTH.
>
> 5. Section 2.1.
>
>    ML-KEM can also be used to create or rekey a Child SA or rekey the
>    IKE SA by using a IKE_FOLLOWUP_KE message after a CREATE_CHILD_SA
>    message.
>
> s/message/exchange (2 times)
>
> 6. Section 2.1.
>
>    ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts may make UDP
>    packet sizes larger typical network MTUs (1500 bytes).
>                                ^^^^
>
> Is not "than" is missed here?
>
> 7. Section 2.1.
>
>    ML-KEM-1024 Key Exchange Method
>    identifier TBD37 SHOULD NOT be used in IKE_SA_INIT messages which
>    could exceed typical network MTUs and cannot be IKEv2 fragmented.
>
> A clarification should be added along the lines "unless IP 
> fragmentation is known not to be an issue (e.g., when reliable transport is used for IKE [RFC9329], [draft-smyslov-ipsecme-ikev2-reliable-transport])".
>
> 8. Section 2.3.
>
>    If the check fails, the initiator MUST
>    reject the ciphertext and MUST fail the exchange.  In this case, the
>    initiator MAY send a Notify payload of type INVALID_SYNTAX to the
>    responder as a separate INFORMATIONAL exchange, usually with no other
>    payloads.  This is an exception for the general rule of not starting
>    new exchanges based on errors in responses.
>
> I think this is a bad idea, not only because it violates RFC 7296 
> Section 2.21, but also because the responder has no clue to associate 
> the received error notification with the exchange containing the ciphertext, which it thinks is completed with no error.
> I think that the proper way to handle this situation for the initiator 
> is to log the error and just to stop creating new IKE SA if it is not 
> yet created (i.e. not to initiate IKE_AUTH or next IKE_INTERMEDIATE) 
> or to send a Delete payload in a new INFORMATIONAL exchange if the IKE 
> SA is deemed to be already created by responder (e.g. if an error occurred in the last IKE_FOLLOWUP_KE message when no more exchanges are expected to complete the rekey).
>
> 9. Section 3.
>
>    Likewise, if the initiator knows
>    out-of-band that a responder supports ML-KEM, it SHOULD abort the
>    negotiation if the responder selects a proposal that doesn't include
>    ML-KEM.
>
> If the initiator knows beforehand that the responder supports ML-KEM, 
> then the easier way for the initiator to handle this situation is to 
> include _only_ proposals with ML-KEM into the SA payload (thus, restricting the possible responder's choice).
>
> 10. Section 3, last para.
>
> I'd rather to remove this para (or at least to shorten it). The 
> initiator usually knows (or at least assumes) who responder is, it even sends the perceived responder's identity in IKE_AUTH.
> In this case, if the initiator knows the responder's capabilities 
> beforehand, then it can avoid all this hassle with postponed PQ KE by 
> simply only offering proposals with ML-KEM. The downgrade attack is 
> only possible if the initiator does not know the responder's capabilities when it starts creating IKE SA and thus offers wider options (including those w/o ML-KEM).
>
> 11. Section 4.
>
> Since official code points are already allocated, please replace 
> TBD35, TBD36 and TBD37 with actual values (35,
> 36 and 37). This also should be done throughout the document.
>
> Also please remove the last row from the table:
>
>     +---------+-------------+--------+-------------------+------------+
>     | 38-1023 | Unassigned  |        |                   |            |
>     
> +---------+-------------+--------+-------------------+------------+
>
> as this is now what is requested (range of unassigned values are 
> maintained by IANA and can be consumed before this draft is published).
>
> Regards,
> Valery.
>
> > This will start two week WGLC for the draft-ietf-ipsecme-ikev2-mlkem 
> > [1]. This last call will end at 2025-09-07. If you have any comments 
> > about the draft send them to the WG list.
> >
> > [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/
> > --
> > [email-masked]
> >
> > _______________________________________________
> > IPsec mailing list -- [email-masked] To unsubscribe send an email to 
> > [email-masked]