1

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
sunknudsen
  • 701
  • 3
  • 14
  • 28

1 Answers1

2

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).

Community
  • 1
ecdsa
  • 3,973
  • 15
  • 29
  • Thanks ecdsa. So if a server is configured using `rekey=no`, does it mean that a particular set of keys is used forever allowing an attacker to decrypt more data? Also, if a client is configured using `rekey=yes`, does it trigger a rekey even though the server has `rekey=no`? – sunknudsen Jun 28 '19 at 00:30
  • 1
    The keys are used until the IKE_SA is terminated, or any of the SAs are rekeyed by the client. The decision to rekey and when is a local one, it's not negotiated. Setting `rekey=no` only disables the initiation of rekeyings, those initiated by the peer are still handled (some clients, e.g. some Windows versions, don't like it actually if servers initiate rekeyings). However, it's possible to request clients to reauthenticate, see the page I linked (requires `reauth=yes` and `rekey=yes` on the server, and the client must support it, otherwise the server will just close the IKE_SA at that time). – ecdsa Jun 28 '19 at 06:22