From: IPsec [mailto:[email protected]] On Behalf Of Russ Housley Sent: Thursday, December 08, 2016 12:03 PM To: Scott Fluhrer (sfluhrer) Cc: IETF IPsec Subject: Re: [IPsec] Quantum Resistant IKEv2
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. 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. In both cases, the traffic that is protected by the initial IKE SA can be recovered; that's because that traffic is encrypted by the initial SK_ei, SK_er keys, and those would be recoverable. In both cases, any IPsec traffic and any traffic protected by a child IKE SA would be safe (in the first option, because we deliberately stir in the ppk when we generate them; in the third option, because we stir in the ppk to form the updated SK_d, and then we use that SK_d to generate those keys). - 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
