Scott: > In the WG meeting in Seoul, we discussed the Quantum Resistant proposal for > IKEv2, and decided to make the current draft (draft-fluhrer-qr-ikev2-03) as > work item. > > 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. > - The second item is anonymity; some people were interested in > preserving anonymity (however, not at the expense of excessive complexity). > One idea that was brought up was that the initial exchange would be done > using pseudonyms (which would be sufficient for the responder to identity the > PPK), and then once initial IKE SAs have been established (in a QR form), > exchange the real identities. My questions: > o Would this idea of pseudonyms actually give any real identity protection? > Wouldn’t that assume that several initiators use the same PPK (so they could > use the same pseudonym)? Is that the sort of thing we should be encouraging? > o Should this be addressed in this draft, or could it be addressed in a > follow-up draft? > o If it would be addressed in a follow-up, would any hooks be required? > For example, would we want to introduce an opaque bit in a notify message to > indicate this? > o Would we be happy with always negotiating a child SA (as none of the > three proposals for stirring in the PPK attempt to protect the initial IKE > SA)? > My opinion is that this could be placed in a follow-up draft. +1. Please do not delay the quantum resistant work while this gets sorted out. In the past, the discussions of identity protection have not been short. Russ
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
