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