Home / server / Questions / 972886
Accepted
sunknudsen
Asked: 2019-06-26 16:07:57 +0800 CST

When configuring strongSwan servers, is it safer to use `rekey=yes`?

  • 772

Currently, I use the following configuration. Should I switch to rekey=yes and, if so, why? I’m looking to enforce perfect forward secrecy (PFS). Other security suggestions are welcomed.

config setup
    charondebug="ike 1, knl 1, cfg 0"
    uniqueids=never

conn ikev2
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    ike=aes256gcm16-sha384-modp3072!
    esp=aes256gcm16-sha384-modp3072!
    dpdaction=clear
    dpddelay=300s
    rekey=no
    left=%any
    leftid=my-vpn.com
    leftcert=vpn-server.crt
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    right=%any
    rightid=%any
    rightauth=eap-tls
    rightdns=1.1.1.1,1.0.0.1
    rightsourceip=%dhcp
    rightsendcert=never
    eap_identity=%identity
strongswan

1 Answers

  1. Best Answer

    Perfect forward secrecy (PFS) is an inherent part of IKEv2, as the key material for every IKE_SA is derived from an ephemeral Diffie-Hellman (DH) exchange and reusing DH factors is (hopefully) not a very common practice (strongSwan doesn't do that).

    So even without rekeying each new IKE_SA will use independent keys. Unless childless IKE_SA initiation is used (RFC 6023), the keys for the first CHILD_SA are always derived from that key material. If additional CHILD_SAs are created (not the case with your config), they can optionally derive the keys from a separate DH exchange.

    Rekeying the IKE_SA always requires using a DH exchange to create completely independent key material, it's optional when rekeying CHILD_SAs. Again, without DH exchange the CHILD_SA keys are derived from the IKE_SA's key material. Which means that depending on whether the IKE_SA has been rekeyed before the CHILD_SA, the new CHILD_SA keys are not related to those used by the previous CHILD_SA.

    So rekeying basically controls how long, or for CHILD_SAs also for how many packets/bytes, a particular set of keys are used, that is, how much data an adversary who recorded all traffic can decrypt after a successful attack on a single DH exchange. Whether to employ rekeying and in what interval, therefore, depends on your policies/preferences under these aspects (it also depends on how long you expect the connection to be established at a time).

    For IKE_SAs it's also possible to use reauthentication (reauth=yes in ipsec.conf) instead of rekeying, which creates a new IKE_SA and its CHILD_SAs from scratch (either before or after tearing down the previous SAs). This can, for example, be used to ensure a client still has access to a private key on a smartcard. However, the process is not as smooth as inline rekeying, so some packets can get dropped (in particular if the default break-before-make reauthentication is used).

    • 2