Hi Paul,
RFC 5996 states:
Although ESP and AH do not directly include a Diffie-Hellman
exchange, a Diffie-Hellman group MAY be negotiated for the Child SA.
This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA
exchange, providing perfect forward secrecy for the generated Child
SA keys.
software tends to configure the modp group as part of the phase2alg=
or esp= option, inherited from IKEv1's strict separation. With IKEv2,
we have a child sa negotiation in the initial exchange and one in the
create_child_sa. For the initial exchange, you would never do a new
DiffieHellman.
But a configuration does not know whether it will be initiated via
the initial exchange or via the create_child_sa. It can depend on
which happens to be the first tunnel with the peer.
I see an interop issue where a transform for a child sa is rejected in
the initial exchange because of a mismatch in the modp transform.
Our implementation requires that the list of DH groups for
IKE and IPsec be the same in case of IKEv2.
My questions:
Should we accept an initial exchange child transform that does not specify
a modp transform if we are configured to need one for the child sa?
I think we should as it is a special case. But we must ensure that the
group,
negotiated in IKE_SA_INIT is also acceptable for the Child SA.
Should we leave out the modp group transform for the child sa in the
initial
exchange, if we are configured to need one for the child sa?
Not only we should, we must leave it out. RFC5996, page 12:
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.
Again, it is a special case. And while proposing DH group
for the IKE SA we must ensure that it is also acceptable
for the child SA.
Regards,
Valery.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
