I'm reading conflicting things about how PFS works in IPsec. Some sources say it's simply a renegotiation of the Phase 1 IKE/ISAKMP SA that ignores the original IKE/ISAKMP SA lifetime value and that it generates a new derivative key for Phase 2 IPsec SA keying material. Others say it's an entirely separate DH key exchange producing its own Phase 2 IPsec SA keying material that doesn't rely on a derivative key from a renegotiated IKE/ISAKMP SA.

Or does it do both of these things? Meaning PFS triggers two new DH key exchanges - one for a new IKE/ISAKMP SA and another one for the IPsec SAs that's independent from the new IKE/ISAKMP SA derivative key?

2 Answers 2


Each implementation may vary in some details and some functions and features of any IPSec peer relationship will be negotiated for each connection but the basic idea is that each Quick Mode during the Phase 2 negotiation/connection process will perform another DH exchange if PFS is specified for the peer setup.

According to Cisco:

Perfect Forward Secrecy: If perfect forward secrecy (PFS) is specified in the IPSec policy, a new Diffie-Hellman exchange is performed with each quick mode, providing keying material that has greater entropy (key material life) and thereby greater resistance to cryptographic attacks. Each Diffie-Hellman exchange requires large exponentiations, thereby increasing CPU use and exacting a performance cost.

Essentially, the Phase 1 setup is done once for the peer connection (until it times out or reaches its end of life), and Phase 2 will be repeated on a negotiated schedule over and over for the life of the peer connection but with PFS it does more work with more entropy and more frequently than normal to make it harder for any kind of replay attack to successfully decript any captured data from the session.

  • So let's say PFS is enabled. The first IPsec SA lifetime is up for expiration, triggering a renegotiation. A Phase 1 renegotiation occurs prompting a fresh new DH key exchange for a new IKE/ISAKMP SA. Does IPsec now generate new keying material from the new derivative key from that new SA? Or does a second DH key exchange occur for the new IPsec SA for new keying material not reliant on the new IKE/ISAKMP SA's derivative key?
    – Ceejus
    Apr 12 at 4:05

With the deprecated IKEv1 (ISAKMP) every IPsec SA is negotiated with a separate Quick Mode exchange. Each one can use its own DH exchange to derive fresh key material. The peers have to strictly agree on the DH group and whether DH is used at all. If no DH exchange takes place, the keys are derived from the key material of the IKE SA. The same pattern is repeated when IPsec SAs are replaced (rekeyed). IKE SAs are recreated from scratch with IKEv1 (reauthentication), without affecting existing IPsec SAs (which are basically viewed as independent from the IKE SAs) but keys of those created afterwards will be based on fresh key material even if they don't use a separate key exchange.

With IKEv2 the first Child/IPsec SA that's created with the IKE_AUTH exchange is always derived from the key material of the IKE SA unless childless IKE SA initiation is used (RFC 6023). All other Child SAs (and with childless initiation also the first one) can optionally use an independent key exchange during the CREATE_CHILD_SA exchanges, otherwise, the keys are derived from that of the IKE SA. The same applies when rekeying Child SAs.

Unlike with IKEv1, the key exchange method can be negotiated (the responder can reject the one in the KE payload and request another one the initiator proposed) and it can even be optional (the initiator can include NONE in the proposals), which can avoid some of the issues that occurred with IKEv1 where both peers had to strictly agree. However, the removal of the KE transforms from the Child SA proposals during IKE_AUTH can also create an issue if the peers don't agree at all on whether or which key exchange method to use during rekeying of that initial Child SA.

As with IKEv1, IKE SAs may be reauthenticated (i.e. replaced from scratch), but here this also recreates all Child SAs. So they all get fresh keys either from the new IKE SA's key material or from an independent key exchange. IKEv2 also provides inline rekeying for IKE SAs with mandatory key exchange. Similar to reauthentication with IKEv1 this doesn't affect existing Child SAs, but all Child SAs created or rekeyed after the IKE SA rekeying will be based on the fresh key material of the new IKE SA even if they don't use independent key exchanges.

Based on that you can see that there are basically two layers of PFS. On the IKE layer it's mandatory, so depending on the interval in which IKE and IPsec SAs are rekeyed, the latter also regularly get fresh key material without much additional overhead (in particular if there is only a single Child SA). Their keys are linked to the key exchange of the IKE SA, though. So using separate key exchanges for every Child SA might be preferable in some situations to protect traffic with completely independent keys. For IKEv2, childless IKE initiation is required to achieve that for every Child SA including the first one.

Also note that there might be implementations that reuse key exchange parameters, which could reduce the level of PFS.

  • Appreciate the explanation but I'm still lost on something here. If PFS makes it so phase 2 keys are not reliant on SKEYID_D, then why is SKEYID_D still used in the KEYMAT calculation even when PFS is used? From RFC 2409: If PFS is desired and KE payloads were exchanged, the new keying material is defined as KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)
    – Ceejus
    Apr 13 at 0:58
  • It ties the IPsec SAs to the IKE SA. And using the derived secret from the key exchange as input and not as key for the PRF is also because some (historic) PRFs had fixed sized keys (e.g. AES-XCBC-PRF-128 originally only accepted a 128-bit key, which was fixed in RFC 4434). SKEYID_d (or SK_d for IKEv2, again, IKEv1 is deprecated) has a length equal to the preferred key size of the PRF so that works naturally as key.
    – ecdsa
    Apr 13 at 6:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.