Re: [IPsec] IPsec with QKD

[Tony Putman <[e-mail]>]

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

> [...] 
> Thanks for the careful read & thoughtful feedback,

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