Valery Smyslov writes: > > 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.
Or you could remove rules set for the obsoleted IKEv1 protocol, and move the configuration to work on the IKEv2 terms. In that case you could define Diffie-Hellman groups for IKEv2 SA and another Diffie-Hellman groups for PFS (i.e. for later create child sa exchanges). > > 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. In the IKE_SA_INIT we have SA payloads specifying the policy for the IKE SA and that include mandatory Diffie-Hellman group. This group protects the whole authentication and the IKE SA and also provides the upper bound for security of the Child SAs created using that IKE SA. If this group is too weak, then the attacker can break the IKE SA protection, thus it can modify the later CREATE_CHILD_SA exchanges at will, and act as man in the middle for them too, thus breaking whatever Diffie-Hellman is used later. Thus there is no point of having more secure Diffie-Hellman group in the CREATE_CHILD_SAs for PFS than what was used in the IKE SA creation. So if you want to check policy for the initial group and PFS group, just check the policy at the load time, and make sure the groups allowed in the IKE SA creation are stronger than the one used in the PFS. So in IKE_SA_INIT and IKE_AUTH there is exactly one group that is specified in the IKE_SA_INIT SA payload and that protects the whole IKE SA and the first Child SA. That group is by definition good enough for the first Child SA, as security of all future Child SAs are also limited to that one group. > > 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: Yes. > 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. Not really, as the DH group used in the IKE SA is by definition the upper bound of the security for all Child SAs created inside it. Doing another PFS later does not add anything if the original Diffie-Hellman is already broken at that time and there is active attacker there. I.e if you use weak Diffie-Hellman group in the IKE SA and there is passive attacker who records the whole IKE SA exchange and starts breaking the Diffie-Hellman you did. After the attacker manages to break the Diffie-Hellman for the IKE SA it can now calculate the SKEYSEED, an from there it can calculate the SK_d, SK_a* etc. It can use the SK_a* and SK_e* and get in the middle of the IKE SA, thus it can take exchange from the IKE SA decrypt them, modify them, reencrypt and reauthenticate them and send them forward. This means that if you do CREATE_CHILD_SA with much stronger PFS group after attacker can act as man-in-the-middle, the attacker can get that CREATE_CHILD_SA request, replace the KE payload in there, send it forward and do the same in the CREATE_CHILD_SA response. Now you have new Child SA between the peers, but there is attacker in the middle of that SA too, even when you used so strong Diffie-Hellman that attacker could not break it. I.e the security of the IKE SA lies in the IKE SA Diffie-Hellman exchange. If that is broken everything is lost. You might even go so far that limit the security of the CREATE_CHILD_SA Diffie-Hellman groups to the security of the IKE SA DH Group. I.e. if the IKE SA used 1024-bit MODP group, there is no point of proposing 2048-bit MODP group for PFS. You might simply propose the same group you used in the IKE SA, as that is the security limit anyways. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
