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:
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] <mailto:[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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
