Subject: Re: [IPsec] IPsec with QKD

From: Tony Putman <[email-masked]>
Date: Wed, 12 Nov 2014 00:03:17 +0000

Rod,

I read your draft with interest and have a number of comments and
questions.  I've not been around long enough to remember previous
discussions on this (and couldn't find anything after a cursory search
in archives), so please forgive me if I'm rehashing previous arguments.

The QKD keys (and other similar out-of-band keys) are associated with
key agreement, so it makes sense to me to reuse the KE payload.  This
would allow standard notifications and negotiations to take place.  It
also means that you don't need to define a new payload and tranform,
only get IDs assigned to cover OOB key sharing; the way the key
information is packed into the structure also needs to be defined.

Possibly the above was suggested previously and rejected.  If so, I
would suggest producing a new payload which has exactly the same
structure and behaviour as the KE payload.  In other words:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Key Exchange Method Num    |           RESERVED            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        QKD Device ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                            Key ID                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It's not clear to me how the actual key is used.  Your draft says that
the KE and Nonce payloads are not needed, so I assume that you propose
that the key be used directly as SKEYSEED.  I suggest instead that the
Nonces are retained, and that the key simply replaces the g^ir factor;
that is (for the IKE SA):

SKEYSEED = prf(Ni | Nr, QKD key)

You have said that keys MUST NOT be reused.  This seems overly
restrictive to me, and opens you to denial of service attacks.  An
attacker would be able to very quickly exhaust your keys if each
IKE_SA_INIT exchange used up a key, whether or not the subsequent
authentication phase succeeded.  Provided you make use of the nonces as
I suggest above, you could allow reuse of keys which were part of a
failed exchange (up to a limit): the encrypted part of the subsequent
IKE_AUTH message would use different keys each time.  Since we are in
any case making assumptions about the security of the IPsec ciphers,
this seems to leak very little information about the QKD key.

I don't understand the fallback concept.  I would have thought that this
could be negotiated at the time that rekeying (or creating a new Child
SA) was needed.  In other words, the end which initiates the rekey can
use a QKD KE payload, and may include SAs with a DH transform
(equivalent to Diffie-Hellman fallback) or no KE transform (equivalent
to Continue fallback).  If the initiator is simply making a suggestion
that a fallback transform would be acceptable, so as to save QKD keys,
then I suggest using a Notify payload instead of defining a new one.

In section 3.1.3, you define a new transform type.  As I say above, this
is not needed if there is general acceptance to define a new KE
Transform Id for QKD; if there is not, then I agree this is necessary.
However, you should not define the new Transform Id(s) here: that should
also be left to IANA.  It is not clear to me how PAK-DH provides any
meaningful additional security, but if you wish to include it in this
document then you need to define clearly how it applies to IKEv2:
RFC5683 is very general and more specific information will be needed here.

Lastly, something which seems to be missing is a discussion and
specification of QKD key size.  Is this assumed to be implicit in the
Key ID?  It seems to me that this would be a parameter which needs
negotiation.  As such, I would expect to see multiple Transform IDs for
QKD, each representing a different key size.  It may be possible to do
this using an attribute instead, but I think that this would complicate
negotiation (e.g. the INVALID_KE_PAYLOAD indicates which transform it
prefers, and this doesn't have space for an attribute).

Regards,
Tony

---

From: Rodney Van Meter <[email-masked]>
Date: Tue, 11 Nov 2014 22:22:28 -0500

Thanks Tony, good thoughts.  Let me try to respond, though a couple of these are really Shota’s expertise, so if I misrepresent something hopefully he’ll correct me.

(Man, it took me much of the afternoon to read through this, dig through a little code and some RFCs, and I still haven’t completely answered all your questions, but it’s luau time…)

> in archives), so please forgive me if I'm rehashing previous arguments.

Most of the prior discussion was in person or in private email; little to nothing happened on the ML during the discussion of the -00 draft.  (A couple of the experts who reviewed it are probably not even on the ML.)

This time around, we have input from you, Paul Koning, Greg Troxler (who implemented the first version of this), and offline, Tero and a couple of senior people.

Does this mean that there is enough interest from the WG that this should be a work item?  Would be happy to have that as an outcome.

> information is packed into the structure also needs to be defined.

The KE Payload explicitly names fields like Diffie-Hellman Group Num.  It’s pretty closely tied to D-H.  RFC 5996 says, "The Key Exchange payload, denoted KE in this document, is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange.”  I’m opposed to shoehorning something with rather different semantics into the same stuff, and adding caveats like, “We know that the normal use is for D-H group number, but we cheat and use it instead to mean…”  That approach seems likely to lead to maintainability problems down the road, including on things like having non-D-H items listed in the table of group numbers.

> structure and behaviour as the KE payload.  In other words:

So in this case, your figure above reuses the KE Payload ID, or not?  I think you’re asking for a new Payload ID here (same as we are), just want to be clear.

I’m not opposed to the new QKD (or OOB) Payload hewing fairly closely to the format of KE, but we did add some fields in our QKD ID Payload.  For the record, here’s the current format, from the I-D:

QKD KeyID Payload

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Next Payload  !C!  RESERVED   !         Payload Length        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !    version    !F!   flags     !          QKD Device ID        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !         Key ID Length         !                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               !
   !                    Key ID (variable length)                   !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A “version” seemed prudent, since this may continue to evolve.  “F” indicates we have transitioned to Fallback mode, which should only happen if the OOB key generation underruns.  Those are the only things we would be sacrificing by adopting your format, I think.  Shota will have to weigh in on how eliminating the Fallback flag will affect the implementation.

On the other hand, as long as we’re adding a new Next Payload ID, I don’t see any reason _not_ to include these extra fields.

> that the key be used directly as SKEYSEED.

No, the bulk encryption key(s) are taken _directly_ from the QKD-generated random bits.  That is,
SK_d is the first n bits of QKD material,
SK_ai is the next n bits of QKD material, then
SK_ar, SK_ei, SK_er, SK_pi, SK_pr
are taken in order from the QKD-generated material.

Hmm, this probably deserves to be written down.

Note that guaranteeing that there are enough bits associated with a given Key ID and how to avoid wasting any bits that aren’t used (e.g., should they appear as KeyID+1 for later use?) we _deliberately_ did not put into the draft, to avoid unnecessarily constraining the QKD implementation.  Guaranteeing interoperability with different QKD implementations would require agreeing on that, but IMNSHO that part belongs to whoever writes the specs to make that happen.

>  I suggest instead that the

We make no use of the prf at all.  Randomness comes entirely from the QKD process.

> this seems to leak very little information about the QKD key.

Let’s see, this is an interesting question.  I don’t think there is any in-band IP-level DoS attack here, but let us think about what happens when someone attempts to spoof the legitimate partner who actually holds the KeyID that matches.

> Transform Id for QKD; if there is not, then I agree this is necessary.

Let’s talk about these two...

> also be left to IANA.

Yes, this list, correct?
http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml
We need to get the text deferring to IANA written write, so wordsmithing suggestions welcome.

>  It is not clear to me how PAK-DH provides any

Let me check with Shota on this.  It may be that it can be deleted with no significant impact.

> Key ID?

See above, we think this part is out of scope.  There are tons of parameters and specifications that have to be done in order to get to interoperable QKD devices, and that is WAAAAAAYYY out of scope here.  I’m pretty sure we can defer this part to the point in time when the interface between the QKD device  and the IPsec gateway (or subsystems, if the IPsec gateway is integrated into the QKD box) gets written down in a formal specification.  I’m willing to be persuaded differently, though.

Note that ETSI has an effort to standardize some parts of QKD; preempting that to make sure that any changes to IPsec & IKE are documented where they should be, in IETF.

>  It seems to me that this would be a parameter which needs

Thanks for the careful read & thoughtful feedback,

			—Rod

---

From: Tony Putman <[email-masked]>
Date: Wed, 12 Nov 2014 20:01:04 +0000

Rod,

I would class myself as an interested bystander, not one who would
actually implement or use a QKD protocol, so I don't know whether this
should be a work item or not.  Certainly, some of the suggestions I'm
making should not be adopted unless it *is* accepted as a work item.

On 12/11/14 03:22, Rodney Van Meter wrote:
> The KE Payload explicitly names fields like Diffie-Hellman Group Num.
> It’s pretty closely tied to D-H.  [...]
> I’m opposed to shoehorning something with rather
> different semantics into the same stuff, and adding caveats like, “We
> know that the normal use is for D-H group number, but we cheat and
> use it instead to mean…”  That approach seems likely to lead to
> maintainability problems down the road, including on things like
> having non-D-H items listed in the table of group numbers.

I don't see this as having different semantics.  Certainly the text ties
it to D-H, but conceptually it is just a method of exchanging enough
information to establish a session key with forward secrecy.  I can
describe some of the advantages that I see to doing it this way, but I
fully agree that this would need broad agreement before going ahead with
it.  Without such agreement, I suggest a new payload with the same
semantics as the KE payload.

The main advantage of using the same payload is to do with algorithm
negotiation.  It's not easy to motivate algorithm negotiation when the
underlying assumption is that the peer is known to have a shared QKD key
and so presumably already supports this draft, but let me try. 

Let's suppose that both direct use and PAK-DH are supported.  Then the
standard IKEv2 approach would be for the initiator to pick one for the
initial exchange, but to signal support for both in the SA payload.  If
the responder does not support the chosen algorithm but will support the
other, then it sends back the INVALID_KE_PAYLOAD notification which
indicates the transform that it would accept.  If we use a different
payload, then the same can be achieved by using a different
notification, but it is hard to negotiate a choice between current DH
key agreement and QKD key agreement (assuming both are acceptable to the
initiator).

Perhaps this the key point: will the initiator ever be in a position
where it does not know that the responder will accept QKD?  If so, then
it makes sense to indicate support for both DH and QKD, and allow the
responder to choose.  Although this *can* be done using two different
payload types, it is a lot simpler to use the same payload type for
both.  I have no idea what the answer to this question would be.

> So in this case, your figure above reuses the KE Payload ID, or not?
> I think you’re asking for a new Payload ID here (same as we are),
> just want to be clear.
>
> I’m not opposed to the new QKD (or OOB) Payload hewing fairly closely
> to the format of KE, but we did add some fields in our QKD ID
> Payload.  [...]

At this stage, I'm not taking a position on whether a new Payload ID is
used.  I'm only saying that the same format can be used either way.  In
this case, the "Key Exchange Method Num" (which may or may not be
identical to the "Diffie-Hellman Group Num" in the KE Payload) is
equivalent to your "version": evolving just consists of defining a new
Method; also, this will be the same number as is used as the Transform
ID (and should be maintained by IANA), so that you can negotiate which
version to use.  I described previously how I envisage implementing
negotiation on fallback policy, so I don't see a need to explicitly
include it in the QKD KeyID payload.

> [Description of key generation]

This is useful information.  It answers my question elsewhere about key
size: it's defined by the selected algorithms.  However, I still think
that Ni and Nr should feed into this in order to allow key reuse where
the authentication stage has failed.  One way to do this would be to
define SK_d as the first n bits of the QKD material, then create a
keystream as prf+ (SK_d, Ni | Nr | SPIi | SPIr) and xor this with the
remaining QKD material to obtain the remaining keys.  As far as I can
see, this doesn't decrease the entropy of the keys.

> [Regarding key material exhaustion]  I don’t think there is
> any in-band IP-level DoS attack here, but let us think about what
> happens when someone attempts to spoof the legitimate partner who
> actually holds the KeyID that matches.

After some thought, this seems to need an active attacker, so maybe it
is not so important.  But I also think that the remedy is quite simple
(and is already part of IKEv2).

> [...] 

My pleasure!  I'm afraid that I've skipped some important points, but I
want to think more about the question of algorithm negotiation before I
address them.  I look forward to your thoughts on the matter.

Tony

---

From: <[email-masked]>
Date: Wed, 12 Nov 2014 20:11:23 +0000

On Nov 12, 2014, at 3:01 PM, Tony Putman <[email-masked]> wrote:

> ...
> where it does not know that the responder will accept QKD?

I would say yes.  That would be a policy matter; it could be viewed as a downgrade, and if so you may want to block downgrade attacks by insisting on QKD.  But if the QKD channel has failed, your options are (a) don’t communicate, (b) use a conventional key agreement algorithm, or (c) send in the clear.  (c) is an unlikely choice in practice, but both (a) and (b) are plausible depending on policy preferences.  What you suggest would enable (b) in a straightforward way.

> ...

In a sense, the existing DH group number already carries a kind of method selector: we have the MODP flavor of D-H and the ECP one.  While they share basic concepts, they clearly are not the same algorithm.  So redefining that field to have that more general meaning certainly seems reasonable.

	paul