On Mon, Jun 30, 2025 at 03:57:24PM +0300, Valery Smyslov wrote:
> Hi,
>
> 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.
>
>
> 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]
