On Tue, Jul 08, 2025 at 11:25:05AM +0300, Valery Smyslov wrote:
> Hi Antony,
>
> > > I think that the problem that the draft addresses can be solved
> > > in more simple and elegant way. Just lift prohibition for KE transforms
> > > to appear in the SA payload in IKE_AUTH.
> > >
> > > Rationale. Currently all the parameters of the initial Child SA are
> > > negotiated
> > > in the IKE_AUTH exchange except for KE methods. Section 1.2 of RFC 7296
> > > says:
> > >
> > > Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads.
> > > Thus, the SA payloads in the IKE_AUTH exchange cannot contain
> > > Transform Type 4 (Diffie-Hellman group) with any value other than
> > > NONE. Implementations SHOULD omit the whole transform substructure
> > > instead of sending value NONE.
> > >
> > > The only difference between negotiation of Child SA parameters in
> IKE_AUTH
> > > and in CREATE_CHILD_SA is that in the latter case KE method is
> negotiated
> > > too, so that the full set of needed parameters is negotiated. Thus, the
> > > solution -
> > > let negotiation in IKE_AUTH be the same as negotiation in
> CREATE_CHILD_SA -
> > > lift the prohibition for KE method transforms to appear there. But do
> not
> > > use the negotiated KE method(s) for computing session keys for initial
> Child
> > > SA -
> > > just check that negotiation is successful, which means that you will not
> > > have
> > > problems with the following rekey(s).
> > >
> > > To maintain backward compatibility negotiate this feature in IKE_SA_INIT
> > > via exchange of a new notification.
> >
> >
> > If this payload is sent in IKE_SA_INIT, it would apply to all subsequent
> > CHILD_SAs, potentially restricting flexibility. I wonder whether placing
> it
> > in CREATE_CHILD_SA or IKE_AUTH would be more appropriate, to allow
> > per-CHILD_SA PFS negotiation.
> >
> > I remember the use case Valery used to mention if the SA is short lived no
> > need for pfs.
> >
> > >
> > > Initiator Responder
> > > -------------------------------------------------------------------
> > > HDR, SAi1, KEi, Ni
> > > N(EARLY_CHILD_PFS_INFO) -->
> > >
> > > <-- HDR, SAr1, KEr, Nr, [CERTREQ],
> > > N(EARLY_CHILD_PFS_INFO)
> >
> > what is in the payload EARLY_CHILD_PFS_INFO is it single value or list?
> > I propse a list.
>
> You seems to miss the point (perhaps my message wasn't clear enough).
> EARLY_CHILD_PFS_INFO cannot be single or list - it contains no data.
> Its purpose is to allow peers negotiate support for the pfs-info extension.
> If peers successfully exchange EARLY_CHILD_PFS_INFO in IKE_SA_INIT,
> then the initiator can include (A)KE transforms into the SA payload
Thanks for pointing it out. Now I understan EARLY_CHILD_PFS_INFO which is
capability annoucemnt.
I will wait for the updated I.D, it is not yet clear to me how KE from RFC
7296 would alllow multiple KE or would it be ADDKE* from RFC9370?
> in IKE_AUTH (currently this is prohibited by Section 1.2 of RFC 7296)
> and the responder will not be choked. This would allow peers to negotiate
> the _whole_ set of Child SA parameters in IKE_AUTH, including (A)KE methods,
> exactly as if they created IKE SA childless and immediately perform
> CREATE_CHILD_SA.
> The only difference between these two cases is that in case of IKE_AUTH
> the negotiated (A)KE methods will not be used for calculating keys of the
> initial Child SA,
> peers just will make sure that their Child SA policies are compatible and
> they
> will not have problems with the following rekeys of this Child SA.
>
> Hope this helps.
>
> Regards,
> Valery.
>
>
> >
> > >
> > >
> > > HDR, SK {IDi, [CERT,] [CERTREQ,]
> > > [IDr,] AUTH, SAi2_with_KE,
> > > TSi, TSr} -->
> > >
> > > <-- HDR, SK {IDr, [CERT,] AUTH,
> > > SAr2_with_KE, TSi, TSr}
> >
> > If the above is a list. The responder should choose one from the list.
> >
> > EARLY_CHILD_PFS_INFO_LIST from I -> R
> > EARLY_CHILD_PFS_INFO from R-> I
> >
> > This idea could also support one of the initial ideas floated around --
> use
> > the same KE method as IKE. Which could be either used one element of the
> > proposed list. Or it could be special notify.
> >
> > Also both EARLY_CHILD_PFS_INFO_LIST should allow no KE, a.k.a. no PFS too.
> >
> > > In my opinion this solution has the following advantages:
> > >
> > > 1. It allows full-fledged negotiation of KE methods identical to what
> > > CREATE_CHILD_SA allows with no restrictions on the policy
> > > (or these restrictions are the same as for CREATE_CHILD_SA).
> > > 2. It is easy to implement - note that you already have code for
> handling SA
> > > payload
> > > in CREATE_CHILD_SA, which does all the work.
> > > 3. If it is used with optimized rekey, then the problem of initial Child
> SA
> > > rekey will gone -
> > > just save the negotiated KE method(s) and use them in the following
> > > rekeys.
> >
> > I wonder if this would work with PQC scenario? what would
> > EARLY_CHILD_PFS_INFO look like if the peer is going to rekey immediately
> > following the AUTH?
> >
> >
> > > Opinions?
> >
> > I like this one better than the previous proposals.
>
> _______________________________________________
> 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]
