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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
