Scott: >> During the discussion, two items were raised, and I would like to hear how >> the wider WG feels about these two items: >> >> - The first item is “how exactly do we stir in the preshared key >> (PPK) into the keying material”. By my count, three options were on the >> table: >> o There is the option listed in the draft, where we modify both the KEYMAT >> and SKEYSEED computations; stirring it into the KEYMAT implies that the >> IPsec SAs are generated with QR-resistant keying material, while stirring it >> into the SKEYSEED implies that any child IKE SAs implies that any IKE SA >> (other than the initial one) also has QR-resistant keying material. This >> latter was done specifically so that an implementation can have protected >> IKE SAs (by negotiating a child SA immediately) >> o Dan Harkins suggested that we modify only the KEYMAT. This is a simpler >> option, and will continue to protect the IPsec SAs; however this implies >> that any data protected by the IKE SA could potentially be recovered by a >> Quantum Computer. >> 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
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
