Hi Scott, after reading the draft I have one question. The draft redefines both KEYMAT and SKEYSEED for IKE SA rekey derivations for the case when PPK is used. Did you consider variant when only SK_d derivation is modified? Something like this:
No modification to SK_* calculation, SKEYSEED calculation and KEYMAT calculation. However, for the PPK use case define SK_d`, that must be used instead of SK_d, so that SK_d’ = prf+(SK_d, Ni’ | Nr’), where Ni’ = prf(PPK, Ni), Nr’ = prf(PPK, Nr). This is an ad hoc construction, probably it can be improved, but the idea is clear: Introduce a single point (SK_d’ derivation) where modifications to keys derivation algorithm take place, instead of two points. It will make implementations modification easier, I think. So, did you consider such variant? Are there any security disadvantages? Regards, Valery Smyslov. From: Scott Fluhrer (sfluhrer) Sent: 28 октября 2016 г. 23:25 To: IPsecme WG (ipsec@ietf.org) Subject: [IPsec] FW: Quantum Resistance Requirements Here is an update on the voting for the list of potential requirements for a short term Quantum Resistance solution; and a summary of the recent update to our draft (which reflects the stated requirements) The votes so far (omitting the "no opinion" votes); I've listed the voters chiefly so that if I mischaracterized their votes, they can correct me. - Simplicity; how large of a change to IKE (and IKE implementations) are we willing to contemplate? Scott Fluhrer: very important Michael Richardson: very important Tommy Pauly: very important Valery Smyslov: not as important as other issues Oscar Garcia-Morchon: very important. - Preserving existing IKE security properties? Scott Fluhrer: very important Michael Richardson: very important Tommy Pauly: very important Valery Smyslov: important Oscar Garcia-Morchon: very important. - What do we feel needs to protected from someone with a Quantum Computer? Do we feel the need to protect only the IPsec traffic, or do we need to protect the IKE traffic as well. Tommy Pauly: not clear if IKE traffic needs to be protected. Valery Smylsov: important Oscar Garcia-Morchon: IPsec traffic must be protected, IKE traffic would be a nice-to-have. - What level of identity protection do we need to provide? If two different IKE negotiations use the same shared secret, do we mind if someone can deduce that? Scott Fluhrer: not important Michael Richardson: very important Tommy Pauly: not important Valery Smylsov: this is a nice to have, but not critical Oscar Garcia-Morchon: this is less important Russ Houseley: this is a nice to have, but only if it is cheap - PPK management; how much support do we provide for automatically managing the secrets? Scott Fluhrer: not important Tommy Pauly: not important Oscar Garcia-Morchon: not important - How much support do we provide for nonstatic secrets, for example, by QKD, or via something like HIMMO (a key distribution mechanism that appears to be post quantum)? Scott Fluhrer: not important Michael Richardson: not important Tommy Pauly: not important Oscar Garcia-Morchon: not important now, but will become important in the future - Authentication; if someone with a Quantum Computer can break the DH in real time, do we care if he can act as a man-in-the-middle? Scott Fluhrer: not important Michael Richardson: important, provided that we don't run into the same issues that IKEv1 PSKs ran into Tommy Pauly: not important Valery Smylsov: this would be nice to have Oscar Garcia-Morchon: this would be nice to have - Algorithm agility; how important is it that we negotiate any cryptoprimitives involved? Scott Fluhrer: not important Tommy Pauly: not important Valery Smylsov: important Oscar Garcia-Morchon: less important. My tentative summary of the votes: - Simplicity and preserving existing security properties are the most important - Protecting IKE traffic was considered less important. We have updated our draft to reflect these requirements; it is much simpler than the previous draft, but does not provide anonymity. It is based on a suggestion by Tero (which was to do the initial IKE SA establishment as normal, and then stir in the PPK into the IPsec KEYMAT generation process); this makes it much simpler than trying to exchange identities before doing the initial key derivation. We did add a modification to how the child SA SKEYSEED was computed (by stirring in the PPK there as well); the advantage of this is that this means that any child IKE SAs were also quantum resistant. This implies that an implementation that did insist on protecting the IKE traffic could immediately generate a child SA after negotiation, and then use that child SA to do all the real negotiation. We thought that this flexibility justified the extra complication of modifying the SKEYSEED computation. Such an implementation would leak the identities to a Quantum adversary, but everything else would be protected. Here is how the draft scores against the given criteria: - Simplicity; it is fairly simple - Preserving existing IKE security properties? It preserves all IKE security properties against an adversary with a conventional computer - What is protected from someone with a Quantum Computer? It protects the IPsec traffic; it also allows an implementation (with more exchanges) to protect the IKE traffic (apart from the identities) - What level of identity protection do we need to provide? This doesn't provide any identity protection against someone with a Quantum Computer - PPK management; not addressed - How much support do we provide for nonstatic secrets? Not addressed, however it would not be difficult to add in the future. - Authentication; can an attacker with Quantum Computer act as a man-in-the-middle? No, not if both sides have PPK mandatory - Algorithm agility; yes, the only algorithms used are the ones negotiated _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
