[strongSwan] re-key fail due to ESP dhgroup mismatch

[Martin Willi]

Hi,

> Question 1:
> Is there anything I can do (in terms of messing with strongswan.conf
> or ipsec.conf or changing charon code) to make the mismatch detected
> at setup time?

No. As you already have noticed, the DH group is not exchanged in
IKE_AUTH, as no DH exchange is done for CHILD_SAs at this stage. It
doesn't make much sense, as we just did a DH exchange in IKE_SA_INIT.

> Question 2:
> If this is indeed a RFC standard problem, is it possible to configure
> StrongSwan to not include the SA2i, SA2r in IKE_AUTH? Instead do a
> standalone create_child_sa exchange.

IKE_AUTH always requires a CHILD_SA setup in RFC 5996. There is an
extension to create CHILD-less IKE_SAs (RFC 6023), but we currently
don't support this extension.

Implementing RFC 6023 and having an option to defer CHILD_SA setup might
be an option.
 
> Question is, will ecp256 be the first choice at re-key time? Or will
> the no dh-group proposal take precedence because, at IKE INIT time it
> matches? (The one with dh-group can never match if my interpretion of
> rfc5996 is right.)

If the full proposal includes a DH group, the initiator will include a
KE payload with this group (the first group found in the proposal list).
The responder is free to ignore the payload if it finds a matching
proposal that doesn't use a DH group. In this case it won't return a KE
payload, but the exchange should succeed.

> Question 4:
> Another thing I can do is  ban dh-group in ESP altogehter. Man page
> and RFC 5996 all said that will make the connection less secure. Is
> there anything I can to mitigate the risk? E.g. make the ikelifetime
> shorter than keylifetime  so that at re-key time SK_d is fresh.

The DH exchange can be done to achieve perfect forward secrecy. If you
do non-PFS rekeys only, an attacker breaking the initial keys can also
reconstruct rekeyed keys. If PFS is in use, this is more difficult, as
each DH exchange establishes a new secret.

Using IKE_SA rekeyings certainly helps with no-PFS CHILD rekeying, as it
refreshes SK_d with a new DH exchange, which is then used by follow-up
CHILD rekeyings.

Regards
Martin