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

From: Yaron Sheffer <[email-masked]>
Date: Tue, 02 Dec 2014 23:19:39 +0200

Here's a quick reminder to speak up if you're interested in this 
document and are willing to contribute as co-author or reviewer.

Thanks,
	Yaron

On 11/25/2014 10:06 PM, Paul Hoffman wrote:
> <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
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Rodney Van Meter <[email-masked]>
Date: Tue, 2 Dec 2014 17:49:58 -0500

Hi,

Sorry to be a little slow to reply.  I was offline over Thanksgiving, just saw the messages yesterday afternoon.

Of course I favor adoption, and am willing to work with anyone who can contribute to the development of an appropriate protocol.  Momentum seems to be toward a version supporting a variety of out-of-band mechanisms, and I’m willing to work in that direction.

Shota is looking in to the numerous issues I detailed in the long message right after IETF.

		—Rod

> On Dec 2, 2014, at 4:19 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> Here's a quick reminder to speak up if you're interested in this document and are willing to contribute as co-author or reviewer.
> 
> Thanks,
> 	Yaron
>

---

From: Tony Putman <[email-masked]>
Date: Sun, 07 Dec 2014 16:48:46 +0000

Hi,

I'm in favour of standardizing this work and am willing to review the
document(s). I don't have a view on the best way to achieve this, but I
think that the work would benefit from discussion on the list. There are
a number of open questions in my mind, including the following:
 - Should this be QKD only, or PFS through generic OTP?
 - Should this use PAK-DH? (there is a stronger argument for it if this
is about a generic solution)
 - Should there be a standardized structure to the Key ID? (Again, not
needed for direct QKD)
 - What is the best way to derive the keying material?

Tony

---

From: Rodney Van Meter <[email-masked]>
Date: Sun, 7 Dec 2014 09:24:53 -0800

> On Dec 7, 2014, at 8:48 AM, Tony Putman <[email-masked]> wrote:
> 
> Hi,
> 
> I'm in favour of standardizing this work and am willing to review the document(s). I don't have a view on the best way to achieve this, but I think that the work would benefit from discussion on the list. There are a number of open questions in my mind, including the following:

Keep in mind that at this point we are only modifying IKE’s process of generating keys.  The bulk encryption is still dependent on AES or whatever algorithm you negotiate.  However, OTP keys with short lifetimes is a good balance between aggregate data rate and the rate of consumption of key material, and is an excellent analogue for how QKD-generated keys should be thought of, IMO.

>  - Should this use PAK-DH? (there is a stronger argument for it if this is about a generic solution)

Open to advice here.  If I understand what you’re suggesting, I think not.

>  - Should there be a standardized structure to the Key ID? (Again, not needed for direct QKD)

I think the best suggestion on the table here is to *not* standardize that, but to include an annex or appendix in the RFC describing use cases, of which the first would be how we use them in QKD.  This allows for different ideas of generation, including whether or not you need to name the node, interface, even port as the context in which a numeric key ID is to be interpreted.  That would be very different for couriered OTP, where it’s probably “pouch number”+”offset inside pouch”.

>  - What is the best way to derive the keying material?

Tero and a couple of others had opinions here.

		—Rod

>>> On Dec 2, 2014, at 4:19 PM, Yaron Sheffer <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>

---

From: Tony Putman <[email-masked]>
Date: Sun, 07 Dec 2014 18:08:45 +0000

OK, I admit my previous email was a bit short on detail  :-)

> Open to advice here.  If I understand what you’re suggesting, I think not.
What I meant was that if we only consider a direct QKD link between the
endpoints, then the keys are (theoretically) completely secure. But if
we are considering other methods of sharing these keys, then there is an
additional D-H barrier for an attacker to overcome if PAK-DH is used. Of
course, there is also additional computation needed, so there is a
trade-off. I think that it's worth discussing the trade-off on the list.
> I think the best suggestion on the table here is to *not* standardize
> that, but to include an annex or appendix in the RFC describing use
> cases, of which the first would be how we use them in QKD.  This
> allows for different ideas of generation, including whether or not you
> need to name the node, interface, even port as the context in which a
> numeric key ID is to be interpreted.  That would be very different for
> couriered OTP, where it’s probably “pouch number”+”offset inside pouch”.
>
I feel that the right thing to do here is to include a one-byte
KEY_ID_TYPE, and at this stage to only define a single value (OPAQUE).
This give scope to specialize it if necessary without needing any
further changes to the protocol. It is difficult to know how this is
going to be used, so I am in favour of keeping some flexibility (within
reason, of course).

Tony

---

From: Paul Wouters 🔓 <[email-masked]>
Date: Sun, 7 Dec 2014 21:44:55 -0500 (EST)

>  - Should this be QKD only, or PFS through generic OTP?

My preference would be that this would be usable for generic OTP as
well. It could be used in practise, and it would allow implementors
to be able to keep the code tested without needing to own expensive
equipment.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 9 Dec 2014 13:59:16 +0300

Hi,

I thought that I was a late, as today is already December 9,
but then I've noticed, that the survey is untill December 8, 2015 :-)
So I still have some time to express my opinion.

I think that the document in its current form looks like
it is screwing IKE. It leaves a lot of questions why it is done
that way and not another, more convinient, way.
I think, that not many of active members of ipsecme WG are
experts in quantum computing (I definitely not), but
all of them are experts in IKE. And I think that they
could help authors to define the extension so, that
it would not look like improper use of the protocol.
So, the draft definitely needs more review from ipsecme WG.
And thus - either adopt it (although I think that the
technology itself is a bit premature and not widely used),
or, preferrably, give it an individual submission with
closer look from ipsecme WG. And I prefer it to have
experimental status.

Regards,
Valery Smyslov.

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

---

From: Shota Nagayama <[email-masked]>
Date: Sat, 13 Dec 2014 17:05:42 +0900

(2014/11/29 4:21), Paul Wouters 🔓 wrote:
> 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?
Though I replied that fallback mode might be treated as local policy and 
not to be
negotiated at the beginning of IKE, now I notice a difference between 
fallback mode
and other local policies, if my understanding is correct. In current 
IKE, after establishing
the first SA, the success of rekeying is guaranteed at the configuration 
level; any
difference of local policies which are not shared do not prevent 
rekeying the SA.
If fallback mode isn't negotiated, when the system fallbacks, if no 
fallback method is
enabled in both peers, rekeying gets blocked until QKD succeeds to generate
new key. If fallback mode is negotiated at the beginning, the system may 
know
whether rekeying in fallback mode be blocked as such or not. Then, this 
can be
warned to users/system admins before fallback mode is needed to be 
operated.
So, now I think that fallback mode should be negotiated at the beginning and
it should not prevent initial establishment of IKE but should be warned.

>
> 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 :)
My first idea is just replacing QKD-generated bits with SKEYSEED. QKD is 
often argued with OTP to achieve provably secure and I know that just 
replacing QKD-generated bits with SKEYSEED can be used for OTP, however, 
I would like to target only IKE in this project.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 15 Dec 2014 17:02:18 +0200

Shota Nagayama writes:
> Though I replied that fallback mode might be treated as local policy
> and not to be negotiated at the beginning of IKE, now I notice a
> difference between fallback mode and other local policies, if my
> understanding is correct. In current IKE, after establishing the
> first SA, the success of rekeying is guaranteed at the configuration
> level;

Not true. Other end can simply reject the rekey by sending
NO_ADDITIONAL_SAS notification back to the rekey request.

RFC7296 section 1.3 last paragraph:

   The responder sends a NO_ADDITIONAL_SAS notification to indicate that
   a CREATE_CHILD_SA request is unacceptable because the responder is
   unwilling to accept any more Child SAs on this IKE SA.  This
   notification can also be used to reject IKE SA rekey.  Some minimal
   implementations may only accept a single Child SA setup in the
   context of an initial IKE exchange and reject any subsequent attempts
   to add more.

> any difference of local policies which are not shared do not
> prevent rekeying the SA. If fallback mode isn't negotiated, when the
> system fallbacks, if no fallback method is enabled in both peers,
> rekeying gets blocked until QKD succeeds to generate new key.

Yes. Just like it does with normal IKEv2 rekey. On the other hand as
both ends will KNOW for sure when the QKD has succeeded, there is no
need for fallback policy for QKD use. There could be uses for it in
the other out of band key distribution methods, as there the state
might not be shared between both ends at the same time.

In QKD the node will know it has shared keying material with the other
end, and if it will know that it will also know that other end has the
same key material also... 

> If fallback mode is negotiated at the beginning, the system may know
> whether rekeying in fallback mode be blocked as such or not. Then,
> this can be warned to users/system admins before fallback mode is
> needed to be operated. So, now I think that fallback mode should be
> negotiated at the beginning and it should not prevent initial
> establishment of IKE but should be warned.

I do not think there is any need for fallback mode to be negotiated.
If the peer A is willing to fall back to diffie-hellman then it will
try rekeying with diffie-hellman. If other end rejects this rekey with
NO_ADDITIONAL_SAS or some other suitable error notification (depending
how the actual out of band key distribution is negotiated), then they
know there is differences in the policy, thus he cannot rekey. If his
policy says it can continue in that case, it will, if not then it will
close down the IKEv2 SA, and no more packets are sent/received as
specified by the policy. 
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Dec 2014 08:10:16 -0800

Please note that the conclusion of this survey was that the WG was not going to adopt the document. The chairs asked that the authors set up their own discussion fora if they want to continue discussion. Announcing new versions of non-WG drafts on this list is fine, but trying to keep the discussion alive here is not.

--Paul Hoffman

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 15 Dec 2014 22:43:55 +0200

Paul Hoffman writes:
> Please note that the conclusion of this survey was that the WG was
> not going to adopt the document. The chairs asked that the authors
> set up their own discussion fora if they want to continue
> discussion. Announcing new versions of non-WG drafts on this list is
> fine, but trying to keep the discussion alive here is not. 

I do not agree on that. The ipsec is the ietf list for ipsec related
discussion. It was originally for ipsec WG and when IPsecME was formed
we decided to use same mailing list, and I think that at point the
idea was that mailing list should be used with all ipsec related
discussions.

The discussion about those draft has not been that overwhelming that
we would need to create separate mailing list for that. If you are
going to say that most of the active working group participants (I
think most of the really active working group participants did answer
to question, but there might be few missing) are not enough for draft
to be working group document, and then you say that we cannot even
discuss it on the ipsec list I think that is not ok.

I do not want to joining several different mailing list for short time
to discuss about each draft the chairs feel should not be adopted on
the wg and then the lists would most likely be silent forever (except
of course the mandatory spams). 
-- 
[email-masked]

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 23 Dec 2014 08:45:25 -0500

> of course the mandatory spams).

Sorry for my delayed response, I was on vacation and found one of the
few places that has really bad access (data roaming).

I agree with Tero.  This should be discussed on list as that is the
purpose of this list.  If there is enough support, the draft can be
later added as a WG draft, but list members can work on it to develop
it to that point.  If it does not become a WG draft, this will help me
to decide if the draft should be an individual submission or ISE.  As
Tero said, many of the active participants chimed in, so there may be
enough support for an AD sponsored draft minimally.

Thank you,
Kathleen

-- 

Best regards,
Kathleen