Subject: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Nov 2014 12:06:11 -0800

<chair hats on>

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.

Please reply by December 8, 2015.

--Paul Hoffman and Yaron Sheffer

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Nov 2014 22:05:46 -0500

Paul Hoffman <[email-masked]> wrote:
    > 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 think ISE is the right way.

My comments start with the first paragraph:

   This document describes modifications to IKEv2 to use keys created
   via QKD for the Internet Key Exchange IKE_SA[RFC4306], the key
   agreement protocol for IPsec[RFC4301] .  With the exception of the
   use of the new Payloads defined below and the removal of the Diffie-
   Hellman key agreement information, IKEv2 system operates in standard
   fashion.

It seems like if one is going to use the QKD to distribute keys for other
than direct use by IPsec, then the major reason for doing this is to get PFS.
As such, why remove the DH?

It seems like the QKD should just provide a PSK-like authentication.

Some of the explanation seems to be:
   However, existing IPsec/IKE implementations actually have a lower
   data secrecy lifetime, due to their dependence on Diffie-Hellman key
   agreement.  The security of Diffie-Hellman depends on the difficulty
   of the factoring problem, which remains uncertain; factoring may
   prove vulnerable either to theoretical advances in algorithms, or the
   deployment of large-scale quantum computers.  An eavesdropper who
   records encrypted packets today can store those packets, and decrypt
   them later by discovering the key, when it becomes technically
   feasible to do so.

I'm not entirely sure I understand how to QKD key material gets mixed in with
the nonces, etc. to form keys; but that's probably because I read too
quickly.

I vote for ISE.  Give them whatever numbers they need, and let's hear back
how it goes...

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Nov 2014 13:13:38 +0200

Paul Hoffman writes:
> 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.

I think we should standardize this usage, and that draft might be good
starting point (I do have quite a lot of comments to it, I will sent
out shortly).

> 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.

Either due through this working group or through individual submission
would be fine. I do not like documenting extensions to the standard
track protocol through independed submissions editor, especially if
the idea is to make such extension standard used between multiple
vendors. Some vendor just wanting to document their own way of doing
something would be fine through ISE, but if I have understood
correctly the reason this effor is ongoing is to make extension that
can be used between multiple vendors. For such effort IETF stream
would be better. 
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Nov 2014 10:51:56 -0500

> vendors. Some vendor just wanting to document their own way of doing

I believe that no matter how it proceeds, this extension will definitely need
to be marked "experimental".  

I think that there can be no-interoperation of the IKEv2 side without
interoperation at the QKD side.  My reading is that the QKD side requires 
an unbroken light pipe connection between the two end-points (not sure if
amplification is allowed; I suspect not).  

I agree that really, it's out-of-scope to IPsecME to care about that: the two
end points just have some really high quality random bits that they "share",
and really, *ANY* mechanism (including Pony Express) would do.  {which raises
the question: why KINK isn't a better place for them to start}

As such, I don't see how this work can become "standard" for along time.
Maybe the bis-bis of it.
I am, however, all for accomodating the need for protocol numbers to make this work.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Wouters 🔓 <[email-masked]>
Date: Fri, 28 Nov 2014 14:21:38 -0500 (EST)

> 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 revie…

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