Re: [IPsec] IPsec with QKD

[Rodney Van Meter <[e-mail]>]

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

On Oct 29, 2014, at 11:03 AM, <[e-mail]> <[e-mail]> wrote:

> 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
> 
>> 
>> On Oct 27, 2014, at 2:13 PM, Rodney Van Meter <[e-mail]> wrote:
>> 
>>> ...
>>> * 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
>> 
>