0
$\begingroup$

A question for the crypto-experts to help out a somewhat confused guy: why does PFS (perfect forward secrecy) also exist in phase II as well as in phase I?

Rationale: In phase I ISAKMP, the result of main mode is following keying material:

SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)

SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)

SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)

SKEYID_d is used in phase II to come up with a session key. g^xy is the DH (Diffie-Hellman) shared secret.

So there is already PFS in phase I by design. Each time someone establishes a new IPsec VPN tunnel, a new DH shared secret g^xy will be used to compute SKEYID_d, right? Hence, the session key in phase II will also be unique. This is PFS right there?

So if we also do DH in phase II we have double PFS? What is the point?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
1
$\begingroup$

So there is already PFS in phase I by design. Each time someone establishes a new IPsec VPN tunnel, a new DH shared secret g^xy will be used to compute SKEYID_d, right? Hence, the session key in phase II will also be unique. This is PFS right there?

No, you do not recompute a fresh SKEYID_d for every Quick Mode; instead, a value for SKEYID_d is assigned when the IKE Security Association is created (just like all the other SKEYID values), and is thereafter constant for the duration of the SA.

Hence, that wouldn't meet the definition of Perfect Forward Secrecy; the idea behind it is if the adversary captures the device (and learns everything it knows), he would not learn any previous keys (of course, he would learn any current keys).

In this case, the adversary would learn the value SKEYID_d; the IPsec keys are derived in IKEv1 from prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b). If the attacker captures the device (and so learns the SKEYID_e value, and so is able to decrypt the IKE traffic), he learns the values of protocol, SPI, Ni_b and Nr_b (as they are all sent through the encrypted session).

So, if the PFS option is not used, the attacker can learn the IPsec keying material, and read all the traffic. If the PFS option is (properly) used, then the attacker cannot learn g(qm)^xy, and so does not get the keying material.

I made these comments in the context of IKEv1; similar reasoning applies to IKEv2 (the current version of IKE)

Improve this answer
$\endgroup$
2
  • $\begingroup$ I am a little fuzzed on the benefit of PFS still. If PFS is used for phase II and an attackers compromises the device after some time, all traffic that has been sent using 'old' KEYMAT is safe because the KEYMAT got discarded after every phase II rekey. If the attacker wants to decrypt stuff long term he will have to capture the KEYMAT before each rekey. This is what you are saying I believe? If PFS is not used then, and an attacker can decrypt phase 1 (because he knows SKEYID_e) how would he be able to decrypt the traffic that had been sent before he compromised the device? $\endgroup$
    – Jeroen
    Commented Feb 17, 2020 at 19:57
  • $\begingroup$ @Jeroen: the attacker who compromises the device (and learns SKEYID_d) can then recompute the previous KEYMATs (because, if PFS is not being used, all parameters to the prf are in stored state (SKEYID_d) or sent over the wire (protocol, SPI, nonces) $\endgroup$
    – poncho
    Commented Feb 17, 2020 at 20:05
0
$\begingroup$

Apparently I (TS) am not allowed to comment so I had to type my reply as an answer. @Poncho Thank you for clearing that up. So applying my new found knowledge to a real live scenario, PFS does not hold a benefit for vpn sessions that will never have a rekey in phase II. If you get compromised before a PH II rekey the attacker can get the current SKEYID_d regardless of PFS.

I am aware that in order to fully meet the PFS criteria the phase I key, material should not have a dependency on the phase II key material. That criteria is obviously not met if PFS is not activated for phase II.

In summary for the future reader (please correct if mistaken):

  • If an attacker can compromise (= decrypt phase I) you at the very beginning you are done for: No amount of PFS will help you. This as I assume he will also be able to compute all subsequent KEYMAT generated at every quick mode rekey. If I am right, the rekey exchange info still flows over the compromised phase I (control)channel and thus the necessary parameters to compute the KEYMAT are in clear text for the attacker.

  • WITH pfs: If an attacker can compromise you after (let's say) 10 quick mode (phase II) rekeys, all the traffic up to and including the 9th rekey is safe...because the current KEYMAT is discarded at every rekey. Traffic under the current KEYMAT could also be save as the attacker does not know the parameters to use for recomputing the current KEYMAT (assuming he can't grab them from a device). At the next rekey it is game over though.

  • Without pfs: If the attacker gains access to the KEYMAT in the clear at any given point during the vpn session, he will able to decrypt all past traffic for your current vpn session only=> If you are no longer compromised before staring the next VPN session, you will be safe gain. Assuming your session will end before a PH II rekey, the amount of security is equal to the PFS scenario even though in the strict sense this does not meet the definition of PFS.
Improve this answer
$\endgroup$

Your Answer

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

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