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

Simon Chan simon.chan3 at yahoo.ca
Mon Jul 23 07:24:24 CEST 2012


Dear Experts,

I ran into a ESP dh-group mismatch problem in StrongSwan 4.4.1. Re-tested the scenario in 4.6.1 with same results.
The esp (and ike) transforms of the peers are as follow:

host65
========
 ike=3des-sha2_384-modp1024!
 esp=aes128-sha1-ecp256!

host118
==========
 ike=3des-sha2_384-modp1024!
 esp=aes128-sha1-modp2048!

When host118 initiated the connection, both sides said that they received ESP proposal with no dhgroup:

192.168.12.65 side
===================
Jul 21 19:29:56 host65 charon: 16[IKE] maximum IKE_SA lifetime 28267s
Jul 21 19:29:56 host65 charon: 16[CFG] selecting proposal:
Jul 21 19:29:56 host65 charon: 16[CFG]   proposal matches 
Jul 21 19:29:56 host65 charon: 16[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
Jul 21 19:29:56 host65 charon: 16[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/ECP_256/NO_EXT_SEQ
Jul 21 19:29:56 host65 charon: 16[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ

192.168.12.118 side
===================
Jul 21 19:29:56 host118 charon: 16[CFG] selecting proposal:
Jul 21 19:29:56 host118 charon: 16[CFG]   proposal matches
Jul 21 19:29:56 host118 charon: 16[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
Jul 21 19:29:56 host118 charon: 16[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ
Jul 21 19:29:56 host118 charon: 16[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ

Despite in strict mode, the log said that they chose the received proposal with no dh-group.

Not so amiable at re-key time:
=======================
Jul 21 20:12:59 host118 charon: 12[CFG] selecting proposal:
Jul 21 20:12:59 host118 charon: 12[CFG]   no acceptable DIFFIE_HELLMAN_GROUP found
Jul 21 20:12:59 host118 charon: 12[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/ECP_256/NO_EXT_SEQ
Jul 21 20:12:59 host118 charon: 12[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ
Jul 21 20:12:59 host118 charon: 12[IKE] no acceptable proposal found
Jul 21 20:12:59 host118 charon: 12[IKE] failed to establish CHILD_SA, keeping IKE_SA

This left the tunnel in a peculiar state.

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?

But problem seems a match with the last paragraph in Section 1.2 of RFC 5996:
IKE_AUTH does not contain KE or Nounce payloads... IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman group) with any value other than NONE. 
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. NB: our nodes only talk to StrongSwan that are compiled in-house. We don't interop with other implementations very often.

Question 3:
Another option: I can append a no dh-group proposal to esp, i.e.
esp=aes128-sha1-ecp256,aes128-sha1!
Thus at re-key time, hopefully the no dh-group proposal will act as a safety net.
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.)

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.

Thanks in advance for help.
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20120722/2a38a168/attachment.html>


More information about the Users mailing list