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
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 -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
