To clarify what I'm asking about, Section 2.1 says "ML-KEM key exchange messages can be negotiated in IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages as defined in the Multiple Key Exchanges in IKEv2 specification [RFC9370]." I'm suggesting that CREATE_CHILD_SA be included as an option alongside IKE_INTERMEDIATE and IKE_FOLLOWUP_KE. As described below, I can imagine a scenario in which ML-KEM may be used in IKE_INTERMEDIATE and CREATE_CHILD_SA, but not IKE_FOLLOWUP_KE.
Rebecca Guthrie she/her Center for Cybersecurity Standards (CCSS) Cybersecurity Collaboration Center (CCC) National Security Agency (NSA) -----Original Message----- From: Paul Wouters <p...@nohats.ca> Sent: Thursday, January 23, 2025 10:34 PM To: Rebecca Guthrie (GOV) <rmgu...@uwe.nsa.gov> Cc: ipsec@ietf.org Subject: Re: [IPsec] CREATE_CHILD_SA in draft-kampanakis-ml-kem-ikev2 On Thu, 23 Jan 2025, Rebecca Guthrie wrote: > In a scenario where a traditional key establishment algorithm is used > in IKE_SA_INIT and ML-KEM is used in IKE_INTERMEDIATE, the draft > implies (but does not require) that when rekeying or creating a child > SA, the traditional algorithm would be used again in CREATE_CHILD_SA, > and then ML-KEM would be used in IKE_FOLLOWUP_KE. I am wondering if > anything would prevent ML-KEM from being used directly in > CREATE_CHILD_SA (in other words, using only ML-KEM to rekey or create > a child SA instead of using both the traditional algorithm and ML-KEM, and > not using an IKE_FOLLOWUP_KE exchange)? My understanding is that a new SA > proposal is sent in CREATE_CHILD_SA (new compared to the SA proposal in > IKE_SA_INIT, that is), so it would be okay if ML-KEM is ADDKE1 in SA[i/r]1 > but Key Exchange Method in the SA Payloads of CREATE_CHILD_SA. There are two things at play here. The first is that the Initial Exchanges create both an IKE SA and a Child SA. We normally call the Key Exchange Methods used here the ones "for the IKE SA". And consider the Child SA "came for free with it". That is, once established, we do not yet know whether the peers will expect to do PFS for the child or not when it is time to rekey this child. And if we do want PFS, perhaps we do not want to use the IKE SA Key Exchange Methods but something else. This is what you are here proposing as optional. Additional Child SAs could be created using all the Key Exchange Methods also used for the IKE SA, but more likely would not. If you create 10 Child SAs at once, you wouldn't want to do so many Key Exchange Methods. You would perhaps use only one for the additional Child SAs. All these things are valid as long as the peers agree. The only sort of limitation implied in 7296 is that a rekey MUST cover the same (or more) Traffic Selectors and that the cryptographic strength is not reduced. Now this latter one is tricky when doing PFS. You might want to only do multiple Key Exchange Methods for IKE SAs and settle for something less for Child SAs, based on the fact that you will rekey the IKE SA again with all Key Exchange Methods you just to establish the initial IKE SA. Formally this would reduce the initial Child SA cryptographic strength, but we consider it to be lifting for free with the IKE SA one (which should always have an equal or stronger cryptographic strength than additional/rekeyed Child SAs!) Or you might do all the Child SAs without PFS, but after you rekeyed all the Child SAs, you immediately rekey the IKE SA to gain PFS. > If this seems like a reasonable option, I would support adding text to > the draft that more explicitly allows for this as a possibility (and would > gladly contribute some text). I did not myself yet look into the text as written. But I think something generic like I wrote above should apply, irrespective of the algorithms plugged in (ML-KEM+25519, FrodoKEM+25519, or even 25519+P256) Note that with the optimized rekey draft and the pfs draft we are also trying to clarify this and are looking at how the peers can convey some of the above proposals to let the peer know the peer is allowed to initiate a REKEY for a Child SA with what parameters. Both drafts should see updates next week. Paul _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
