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 _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
