Subject: [IPsec] IPsec with QKD status

From: Rodney Van Meter <[email-masked]>
Date: Thu, 13 Nov 2014 14:13:27 -1000

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-masked]
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/

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 14 Nov 2014 03:02:34 +0200

Hi Rod,

Two quick comments:

- I am fine with the Experimental/ISE route.

- I support the SKEYSEED idea. It makes sense as a single point of 
integration into the protocol, so that if we ever specify a different 
way of generating key material, it would not need to be re-specified for 
QKD. Of course generation of key material depends on PRF algorithms that 
might get weaker over time, but since we're going to use the key 
material for symmetric algorithms anyway, I think this is appropriate - 
the strength of PRF can be correlated to key length of symmetric 
encryption/MAC algorithms.

Thanks,
	Yaron

On 11/14/2014 02:13 AM, Rodney Van Meter wrote:
> [email-masked] <mailto:[email-masked]>
> Quantum Networking:
> http://www.wiley.com/WileyCDA/WileyTitle/productCd-1848215371.html
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>