Hi I too am in favour of Valery¹s option. The rational being, if an attacker can recover the SKEYSEED using a QC, I would assume that they can then inject traffic into the IKEv2 SA, examples being to use configuration payload to manipulate routing, rekey with amended traffic selector etc.. Simply put I feel we need to protect both IPsec SAs and child IKEv2 SAs.
For users concerned against active attacks, the IKEv2 SA should rekey directly after IKE_AUTH and the new child IKEv2 SA be used for configuration payload. This should be called out in the draft, but shouldn¹t be mandatory. cheers From: IPsec <[email protected]> on behalf of Russ Housley <[email protected]> Date: Thursday, 8 December 2016 22:02 To: "Scott Fluhrer (sfluhrer)" <[email protected]> Cc: IETF IPsec <[email protected]> Subject: Re: [IPsec] Quantum Resistant IKEv2 >> o Valery Smyslov gave a suggestion that we instead stir in the PPK into the >> initial SK_d; as all keying material is generated based on that, this would >> also mean that IPsec SAs and any child IKE SAs are also protected. This also >> means that an implementation would not need to remember the PPK after the >> initial negotiation. The only downside I can see is that we would have to be >> a bit careful about when we update the SK_d (obviously, before we actually >> use it). >> To me, all three strike me as reasonable ideas (unless we decide that we will >> need to protect the real identity data encrypted via the IKE SA; in that >> case, Dan¹s idea doesn¹t protect that). Can I get opinions as to which >> strikes the group as the best? Are there any fourth options that people >> would want to put on the table? >> >> I would like to see the preshared key used in a manner that protects the IKE >> SA as well as the child SA. I have a mild preference for the third >> alternative over the first one. > > Actually, in terms of what IPsec/IKE traffic is immune from recovery from an > adversary with a Quantum Computer, the first and third options are identical. I recognize that. I would like to see the preshared key used in a manner that protects the IKE SA as well as the child SA, and between the two alternatives that offer that, I have a mild preference for the third alternative. Russ
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
