Subject: [IPsec] IPsec with QKD

From: Rodney Van Meter <[email-masked]>
Date: Mon, 27 Oct 2014 14:13:06 -0400

Those of you with long-ish memories will recall that about three years ago, Shota Nagayama and I wrote an I-D on the (relatively minor) modifications to IKEv2 necessary to use key material generated by quantum key distribution (QKD) devices.  At the time, it generated a bit of controversy, both because not everyone in the WG agrees on the value of QKD itself (a position I understand, though happen to disagree with) and because there were concerns about whether it is within charter for ipsecme.  So, it more or less got set aside.  We have since talked to a number of people who are supportive of having a documented means of coupling IPsec to QKD, without necessarily taking a strong position on whether QKD will ultimately hold a large place in the security market.  Being one who hates leaving loose ends lying around, I would like to finish this up and get it published as an RFC, presumably Experimental.

The basic argument in favor of doing so:

* several commercial and near-commercial implementations of QKD exist (along with numerous experimental ones);
* each implementation uses the generated key material in a different way, some at L2, some with IPsec;
* ETSI began standardizing some of the low-level technologies, including physical signals and timing and framing;
* experimental deployments are continuing to grow, and those deployments may include IPsec; and
* given that IPsec and IKE are products of the IETF, any necessary changes should be documented and controlled through IETF rather than another organization.

That last point is, I think, critical.

Current status:

* We have just uploaded an -01 of the I-D we wrote, incorporating feedback from several people, including Sean Turner, Sheila Frankel and Alan Mink.
  http://datatracker.ietf.org/doc/draft-nagayama-ipsecme-ipsec-with-qkd/?include_text=1
* An open source software implementation of the -00 version exists, built off of raccoon2.  We will be updating this to match the -01 draft.

Shota and I (and Shigeya Suzuki, who is not an author on the draft but is familiar with our work) will be in Honolulu.  I will arrive Monday evening, leaving Thursday evening.  We hope to meet with folks who are interested in this topic.  Happy to answer questions via email, as well.

Regards,

			—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: Rodney Van Meter <[email-masked]>
Date: Mon, 27 Oct 2014 14:18:40 -0400

> * An open source software implementation of the -00 version exists, built off of raccoon2.  We will be updating this to match the -01 draft.

Oh, one point I meant to mention…IANA considerations:

* We need a Transform Type Value for SA Payloads
* We need Payload Type Values for QKD KeyID and QKD Fallback.

		—Rod

---

From: <[email-masked]>
Date: Mon, 27 Oct 2014 21:30:18 +0000

A nit in section 5:  "The security of Diffie-Hellman depends on the difficulty of the factoring problem”.  More precisely, it depends on the difficulty of the modular discrete log problem, though it may be (I forgot if this is proven or a conjecture) that an efficient solution of that problem can be mapped to/from an efficient solution of the factoring problem.

paul

On Oct 27, 2014, at 2:13 PM, Rodney Van Meter <[email-masked]<mailto:[email-masked]>> wrote:

...

---

From: Rodney Van Meter <[email-masked]>
Date: Mon, 27 Oct 2014 17:43:54 -0400

Yes, you’re correct, we should be more exact there.

Shor’s algorithm solves both (if you believe in large-scale quantum computers).

Classically, I haven’t studied the relationship in depth myself, but this bachelor’s thesis from Harvard seems to be a survey:
http://modular.math.washington.edu/projects/john_gregg_thesis.pdf

		—Rod

---

From: <[email-masked]>
Date: Wed, 29 Oct 2014 15:03:13 +0000

I wonder if this should be worded more generically.  This is really about an external key agreement mechanism.  QKD is one such mechanism, but it isn’t clear to me that the machinery depends on this.
Suppose, for example, that you distributed copies of one-time pad CDROMs to both locations, and used the key ID as offset in the one-time-pad data.  This is a completely different key agreement scheme but it would seem to fit just as well.  The important point is that there is an external source of key material, which has the (assumed) property that the key material is known to the two endpoints of the IKE exchange, and to no other parties.

paul

...

---

From: Rodney Van Meter <[email-masked]>
Date: Wed, 29 Oct 2014 11:34:44 -0400

Actually, we had considered that; the same adjustments to IKE can be used for any out-of-band, asynchronous but ongoing supplier of key material, with OTP keys via courier being the obvious example.  We decided when we started writing to focus on the QKD case, simply because we felt that the broader approach (a) was more likely to result in more discussion and a longer process within the WG, and (b) is less likely to be readily identified, picked up and used by QKD implementers.

When we initially began working on this, we also debated internally about the right level of information to share between IPsec gateways; it wasn’t initially obvious that we could/should do it without more QKD-specific support from IKE.  Managing QKD is itself a big challenge.  We knew right away that we didn’t want to get into any physical-level discussions in the WG or include such negotations in the protocol, but e.g. QKD depends on an authenticated classical channel as it operates, to avoid a man in the middle attack, and it seemed plausible that we might want to tie that channel to IPsec.  In the end, we decided that keeping things as separate as possible was probably wise, and in fact our implementation turned out to be easiest that way.

So, if there is interest within the WG in broadening the language, we can do that, BUT:

* We would need a decision about how to handle the Transform Type Values and Payload Type Values, which is an IANA-relevant discussion; should all out-of-band key agreement methods share a single identifier, or should each one request a separate value?
* Although we have succeeded in keeping a clean interface for this particular case, we didn’t feel like we knew enough about the range of possible OOB key generation methods to state categorically that _they_ would not need additional support within the protocol.

		—Rod

---

From: Rodney Van Meter <[email-masked]>
Date: Fri, 31 Oct 2014 08:12:54 -0400

On Oct 31, 2014, at 7:49 AM, Greg Troxel <[email-masked]> wrote:

> 
> I implemented using QKD material for IPsec (in 2002, if I can remember
> the years right), which included an interface between QKD processing and
> racoon (on NetBSD) to include QKD bits in the Phase 2 hash.  What's been
> published on that effort is:
>   http://dx.doi.org/10.1145/863955.863982

Yes, we’re very familar with your work, the first in the world, as far as I’m aware!  It was one of our inspirations, although our actual implementation was done using QKD devices we borrowed from acquaintances at NEC.  I’ve known Chip since about 2004.  My memory fades already, but when we began this project in 2008, if memory serves, we inquired about simply using your code, but for some reason that wasn’t possible.  I think at the time Chip felt like he was unable to release it, but I can’t remember the details.

When we first wrote down what we had done (even before the I-D -00 was published), Chip looked at our technical approach and endorsed it as more flexible than what you guys had done, which I believe involved borrowing some bits in existing headers rather than creating new payload and transform types.  I don’t recall whether Chip asked you about it directly at that time.  I think Dave Pearson may have looked at it.

FWIW, as long as we’re talking history of projects, Sakane-san, one of the key implementers of racoon2 if I have it right, kibbitzed with us a bit on this project.

		—Rod

---

From: Greg Troxel <[email-masked]>
Date: Fri, 31 Oct 2014 07:55:24 -0400

<[email-masked]> writes:

> I wonder if this should be worded more generically.  This is really
> about an external key agreement mechanism.  QKD is one such mechanism,
> but it isn’t clear to me that the machinery depends on this.
> Suppose, for example, that you distributed copies of one-time pad
> CDROMs to both locations, and used the key ID as offset in the
> one-time-pad data.  This is a completely different key agreement
> scheme but it would seem to fit just as well.  The important point is
> that there is an external source of key material, which has the
> (assumed) property that the key material is known to the two endpoints
> of the IKE exchange, and to no other parties.

I agree that just having an external keying material abstraction makes
sense.   In particular, thinking about it in a larger context is likely
to force clarity on issues of how external keying material is named and
numbered, and how to deal with the possibility that bits which should
match might not.

There are multiple ways to use external material: as OTP, directly as
symmettric keys and by including it in the phase 2 hash.  We implemented
the first and third of these around 2002, and what's been published
about that system is at