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