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.
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?
Regards,
Valery.
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
