ipsecme-ers, We have managed to catch a number of people in the halls to discuss our IPsec with QKD I-D. Haven't managed to catch Yaron yet.
This mail is long. First, an admin summary of where we are, then a technical & writing action item list, and at the bottom a short FYI on the state of QKD, for the curious. Here's where I think we are: * We need this published, so that there is a formal stake in the ground as the growing number of commercial QKD implementations get around to adding a properly engineered IPsec to their supported functionality; existing QKD implementations interface with IP-relevant equipment in an ad hoc manner. (As one person said, "It may be snake oil, but you're entitled to have interoperable snake oil.") * There is no need for Standards Track at the moment; our goal is Experimental RFC as a target for other implementations to aspire to. Therefore, we don't think it's necessary to formally adopt this as a WG item. Taking this through the Independent Stream Editor seems to be the right approach. We have consulted with Kathleen Moriarty, Sean Turner, Paul Hoffman, Nevill Brownlee and a couple of others about this, and they are on board with it. * Even if it's not a WG item, with your permission keeping the discussion public here on the ipsec mailing list seems to be helpful and appropriate. * Several people (Paul Koning, Greg Troxel, Tony Putman, Tero Kivinen) have offered comments on the -01 version. (Sheila Frankel, Alan Mink, Sean Turner offered comments on the -00 version that led to -01.) We will address those in turn; a summary is below. Some of these asked for clarification in the writing, some straightforward changes in packet formats (potentially affecting IANA considerations), a few for significant changes to the semantics. * This will result in a -02 version sometime in the next few weeks as we sort through and address the comments. Our existing open-source implementation corresponds to the -00 draft, but some of these changes are significant enough that we don't want to accept or reject until we have had a chance to at least assess their implementability. * Following the -02, if people on this list are happy, there will certainly be a -03 with wordsmithing. Somewhere around -03, we will probably send to the ISE. My understanding is that he will tap someone to conduct an additional review, and the better we have listened to the folks here the smoother that is likely to go. * Somewhere toward the end of this process, will have to get IANA to assign appropriate IDs. Comments on the above welcome, if we have missed steps or misinterpreted anything. Current action item list, coalescing a couple of prior emails. Had a long F2F session w/ Tero yesterday, some highlights listed here, awaiting full written comments. This list isn't fully orthogonal or prioritized, but obviously some of the suggestions are mutually inconsistent. Conflicts will have to be resolved. Technical questions: * Zeroth suggestion is to broaden to any out of band (OOB) key generation approach (diplomatic pouch being our canonical example). I'm inclined to keep it as focused as possible, but it may well be that by the time we have made the changes proposed, that we are 90% of the way there. * Biggest suggestion is to use the QKD material as SKEYSEED, rather than directly as the bulk encryption keys. We are going to have to think about this, I'm not sure how it will affect what we are trying to accomplish. As long as we avoid the D-H we have accomplished the primary goal, but does using the prf dilute any of the guarantees we get from the QKD itself? e.g., are there vulnerabilities in the prf or known limitations in its lifetime (as with the factoring/discrete logarithm problem of D-H)? I'm not sure. Would it actually add anything to take this approach? I'm not sure. My first inclination is to _not_ adopt this suggestion. * Second biggest suggestion (made by more than one person) is to stick with existing Key Exchange Payload, and just assign a value for the D-H Group Num field to indicate QKD. * Third, fallback is a policy decision, not needed on the wire, perhaps. Just having the right settings in the IKE config should do. * Is there a DoS attack at the IKE negotiation level that can result in us discarding valuable and not yet actually used key material? * Should the nonce be reinstated, and would that allow use to safely reuse some key material? * Can PAK-DH be eliminated? * Should we specify anything about the amount of material matching a KeyID, and what to do we leftover material? * What happens when you have more than one Fallback Payload? Does the prioritization of these need to be documented? * Could a Notify Payload be used instead of a Fallback? * Critical bit is no help against downgrade attack. * Using the keys as material for prf, as in mail, would allow reuse of security proofs. * Can combine device ID, key ID into one undifferentiated field, then add annex saying what our implementation does. * Proposed Payload format is too long and too complex, simpler is preferred. Editing TODO: * Fix IANA-related language * Clarify non-use of prf, order in which keys are extracted from KeyID SK_d is the first n bits of QKD material, SK_ai is the next n bits of QKD material, then SK_ar, SK_ei, SK_er, SK_pi, SK_pr are taken in order from the QKD-generated material. (assuming above change is not adopted) Source matching the -00 draft is available at http://aqua.sfc.wide.ad.jp/research/ipsecwithqkd.html This will be updated around the time we submit -02. Status of QKD: * Several commercial implementations exist, integration into classical networks is still work in progress in the various testbeds, largely being done by (ahem) experimental physicists rather than experienced Internet people. * ETSI was pushing to standardize various physical elements, effort stalled at the moment. * Metro area networks continue to grow; exist in Japan, Spain, China, South Africa, other places. * China announced Beijing-Shanghai network for 2016 http://www.scmp.com/news/china/article/1631479/china-launch-hack-proof-quantum-communication-network-2016 * Battelle doing Columbus-Washington link http://www.battelle.org/our-work/national-security/tactical-systems/quantum-key-distribution * LANL trying for testbed for securing infrastructure * Another very large investment (tens of millions) underway in Europe * Quantum repeaters are in experimental development, don't fully exist yet but would overcome distance limitations (and enable non-QKD applications of quantum states) * Satellite-based QKD also in development, experiment using the International Space Station has been proposed, don't think it has been scheduled yet. If you read this far, thanks. Comments welcome! I'm flying out tonight, but am available in the session right after ipsecme. Otherwise, find us (Shota & me) online. —Rod Rodney Van Meter associate professor, Faculty of Environment and Information Studies, Keio University, Japan [email protected] personal: http://web.sfc.keio.ac.jp/~rdv/ AQUA Group: http://aqua.sfc.wide.ad.jp/ Murai Lab: http://www.sfc.wide.ad.jp/IRL/ GIGA: http://ic.sfc.keio.ac.jp/ Quantum Networking: http://www.wiley.com/WileyCDA/WileyTitle/productCd-1848215371.html http://discourse.quantumnetworks.org/
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
