[Swan-dev] [IPsec] interoperability issue with modp transform mismatch forchild sa (fwd)

[Paul Wouters]

So I think we should:

- Omit sending MODP transform for child sa in the Initial Exchange as
   per RFC
- Allow these to appear, but ignore them (it's unused, and we'll remain
   compatible with our older selves and openswan)

then we should either:

- enforce IKE modp group >= ESP modp group (for IKEv1 and IKEv2)

or:

- enforce IKE modp group == ESP modp group (for IKEv1 and IKEv2)

Paul
---------- Forwarded message ----------
Date: Thu, 10 Jul 2014 07:52:54
From: Tero Kivinen <kivinen at iki.fi>
Cc: ipsec at ietf.org, Paul Wouters <paul at nohats.ca>
To: Valery Smyslov <svanru at gmail.com>
Subject: Re: [IPsec] interoperability issue with modp transform mismatch
     forchild sa

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.
-- 
kivinen at iki.fi

_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec