Ok, I held this informal poll, and here are the results:
- For the first question ("how do we stir in the PPK"), there were no strong opinions; some people did express a preference for the third option (Valery's suggestion to modify only the initial SK_d). I'll update the draft to reflect that. - For the second question ("how important is anonymity"), it would appear that the majority opinion is that this could be handled in a follow-up draft. Michael Richards also suggested we attempt to address how to distribute the PPKs. However, I would agree with Valery Smyslov; this is out of scope for this document; for example, the current IKE RFC allows preshared secrets, and does not address how to distribute them. I'll be published an updated draft shortly; are there any other issues people feel need to be addressed? From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Scott Fluhrer (sfluhrer) Sent: Tuesday, December 06, 2016 4:32 PM To: IPsecme WG (ipsec@ietf.org) Subject: [IPsec] Quantum Resistant IKEv2 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? - 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. Thoughts???
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec