[strongSwan] SeGW-initiated rekey fails - DH group unacceptable

[Graham Hudspith]

Hi All,

Up till recently, we have been setting up tunnels between client and server
using DH Group 2 (aka MODP_1024). We are starting to transition over to DH
Group 14 (aka MODP_2048) and are coming up against problems. I'm hoping
someone can please shed some light ?

The clients are using a hacked version of strongSwan 4.3.6, the server a
hacked version of strongSwan 4.3.2. We want to support a mixed set of
clients, some using 1024-bit DH and the rest using 2048-bit DH.

The initial tunnels come up fine.

If we set the clients to perform periodic rekeying, everything stays fine.

However, those clients that do NOT perform periodic rekeying are kicking
back when the server eventually lifetime rekeys.

So, when the client sets up the tunnel, it sets:

ike=aes-sha-modp1024!
esp=aes-sha1-modp1024,aes-sha1!


The server config is set up thus:

conn %default

        ikelifetime=24h

        keylife=8h

        rekeymargin=3m

        keyingtries=1

        keyexchange=ikev2

        dpdaction=clear

        dpddelay=270

        left=foo.bar.com

        leftid=@foo.bar.com

        leftsubnet=0.0.0.0/0

        esp=aes-sha1-modp2048,aes-sha1-modp1024

        mobike=no

        auto=add


conn certs-only

        authby=rsasig

        leftcert=sgw.pem

        rightid=@*.bar.com

        rightsourceip=10.13.0.0/24


As the initial tunnel comes up, the client logs:

16[CFG] received proposals:
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

16[CFG] configured proposals:
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

16[CFG] selected proposal:
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024


and:

12[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ

12[CFG] configured proposals:
ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ,
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ

12[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ


Eight hours later, the server decides to rekey and we see the client log:

08[ENC] parsed CREATE_CHILD_SA request 0 [ N(REKEY_SA) SA No KE TSi TSr ]

08[LIB] size of DH secret exponent: 2047 bits

08[CFG] looking for a child config for 10.13.0.98/32 === 0.0.0.0/0

08[CFG] proposing traffic selectors for us:

08[CFG]  10.13.0.98/32 (derived from dynamic)

08[CFG] proposing traffic selectors for other:

08[CFG]  0.0.0.0/0 (derived from 0.0.0.0/0)

08[CFG]   candidate "conn_1" with prio 5+5

08[CFG] found matching child config "conn_1" with prio 10

08[CFG] selecting proposal:

08[CFG]   no acceptable DIFFIE_HELLMAN_GROUP found

08[CFG] selecting proposal:

08[CFG]   proposal matches

08[CFG] received proposals:
ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ,
ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ,
ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ

08[CFG] configured proposals:
ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ,
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ

08[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ

08[KNL] getting SPI for reqid {3}

08[KNL] got SPI c4beec6b for reqid {3}

08[IKE] DH group MODP_2048 inacceptable, requesting MODP_1024

08[ENC] added payload of type NOTIFY to message


As far as I can make out, the server has proposed "aes-sha1-modp2048" and
"aes-sha1-modp1024" (and extra ones), the client has recognised that it can
accept "aes-sha1-modp1024" and "aes-sha1" and chosen from the proposals to
accept "aes-sha1-modp1024" but then barfed.

The client sends back N(INVAL_KE) to the server and we then get into an
endless cycle of trying to renegotiate the tunnel rekey.

Is this because I have made the client specify
"esp=aes-sha1-modp1024,aes-sha1!"
whereas the server is using "esp=aes-sha1-modp2048,aes-sha1-modp1024" ?

It will be hard to change the "esp" line used by the client, but it is easy
(and desirable) to change the server config. Is there any way I can
configure the server to allow clients to renegotiate their DH during a rekey
and support a mix of clients that want either 1024-bit or 2048-bit DH ?

Or will I have to turn off DH renegotiation during a rekey (by getting the
server to use plain "esp=aes-sha1") until I have managed to get all of the
clients to transition to using 2048-bit DH only ?

Or (and I doubt this) is this a bug in strongSwan ?

Regards,

Graham.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20101201/a7d66305/attachment.html>