[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