IPsec PFS Confusion

Question

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?

Answer 1

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.

Answer 2

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.