On Tue, 25 Nov 2014, Paul Hoffman wrote:
Greetings again. There is a small emerging industry of crypto solutions that
transmit keys using Quantum Key Distribution (QKD), and then use those keys for
classical high-speed encryption. Several such solutions are using IKE, and
there is a perceived need to standardize this usage. If so, that
standardization should be done in this Working Group.
If you agree with the need to standardize this usage, and believe that
draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting place for
that standardization, and are willing to review and contribute text to the
document if it is adopted by the WG, please say so on the list. This WG has a
history of adopting documents but then not having enough reviewers for us to
feel confident that we are making a good standard, so we need to see a
reasonable number of actively interested people before we adopt the document.
If it is not adopted, the authors can ask for it to be published as an RFC
through individual submission or by the Independent Submissions Editor.
I'm in favor of adopting this document as I can see a real use for this
in the future and since it is making changes to the IKE core protocol,
it would be best that this group is involved in that discussion.
Some comments after a quick read:
Why is the fallback field/mode negotiation required? Typically, those
decisions would be determined by local policy, and the remote end is
informed of that local policy by a new incoming IKE request (or not)
that uses a QKD payload or a DH payload. If the peers disagree about
the fallback method, would that prevent initial establishment of IKE?
Why not leave the DH in place and just ignore the SKEYSEED / prf and
use the QKD bits for the private keys (or OTP)? It's less changes
to the IKE protocol (and friendlier to implementers :)
Having an OTP mode, even without QKD would actually be neat, although it
would require a lot of kernel work too :)
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
