On Nov 12, 2014, at 3:01 PM, Tony Putman <[email protected]> wrote:
> ...
> Perhaps this the key point: will the initiator ever be in a position
> 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.
> ...
> 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.
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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
