Hi Valery,
> 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.
>
> Initiator Responder
> -------------------------------------------------------------------
> HDR, SAi1, KEi, Ni
> N(EARLY_CHILD_PFS_INFO) -->
>
> <-- HDR, SAr1, KEr, Nr, [CERTREQ],
> N(EARLY_CHILD_PFS_INFO)
>
>
> HDR, SK {IDi, [CERT,] [CERTREQ,]
> [IDr,] AUTH, SAi2_with_KE,
> TSi, TSr} -->
>
> <-- HDR, SK {IDr, [CERT,] AUTH,
> SAr2_with_KE, TSi, TSr}
>
>
> 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.
>
> Opinions?
I completely agree. I was wondering if a notify in the response only
would be enough (similar to RFC 6023). But I guess implementations
might need to know that the initiator potentially (or even definitely if
it's made mandatory when a notify is received in the response) sends KE
methods during IKE_AUTH to adapt their verification and proposal
selection code accordingly.
Regards,
Tobias
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
