[strongSwan] Implications of Weak DH / Logjam on IPSec

[Martin Willi]

Gerd,

> you are probably aware of the recent Weak DH / Logjam attack on Diffie-Hellman, 
> see: https://weakdh.org/

Yes. Our TLS stack as server uses at least MODP2048, so is not directly
affected. I've queued a fix to reject groups smaller 1024-bit as client,
subject for the next release, see [1].

> Let's assume IKEv1 Main Mode and an attacker who is able to pre-compute an 
> attack on DH Group 2 / MODP1024. If you are using PSK, the attacker now only 
> needs to know or crack the PSK to gain the session keys and he is able to 
> decrypt the traffic.

For IKEv1 with PSKs this is true, as the PSK is included in the derived
keymat and provides additional protection (but this very same property
of the protocol makes IKEv1/PSK difficult to use for road-warriors, as
you'll have to choose a PSK for the connecting peer without knowing its
identity, as it is encrypted with keymat using that PSK).

> So the attacker can reduce the security of Main Mode to that of
> Aggressive Mode in the end.

Aggressive Mode uses a DH exchange as well, but does not protect the
peer identity or the authentication data under it, allowing attacks on
the PSK.

> What happens if you use RSA keys instead of PSK? I guess the attacker
> now also needs to crack them before he can get at the session keys,
> correct?

No. With RSA authentication in IKEv1, or any authentication method in
IKEv2, the long-term credentials are used for authentication only. So if
you manage to break MODP1024, the protocol is broken. If you can compute
the shared DH secret from the public values, you can derive all keymat
as passive attacker.

> Does the use of PFS for phase 2 / IPSec anyhow weaken the overall
> security of the connection compared to using phase 2 without PFS?

No. Both IKEv1 and IKEv2 use perfect forward secrecy in the terms of TLS
(an ephemeral DH exchange) in all cases. PFS in IPsec usually refers to
redoing a DH exchange for every rekeying, further increasing security.
If an attacker can compute the DH shared secret, it will have to do so
after every rekeying if PFS is enabled.


So for IPsec/IKE there is not that much news in that paper. MODP1024
can't be considered secure against attacks with state-level resources,
and the paper very well underlines that.

Unfortunately MODP1024 is widely used by implementations, and we by
default include it in the default proposals as a fallback. As I'm not
aware of any proposal downgrade attack for IKE, you usually end up with
a better group if both peers support it.

Regards
Martin

[1]https://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=refs/heads/tls-weakdh