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…) On Nov 11, 2014, at 7:03 PM, Tony Putman <[email protected]> wrote: > > 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. 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. > > 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. 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. > > 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 ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. > > 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. 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 > 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) We make no use of the prf at all. Randomness comes entirely from the QKD process. > > 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. 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. > > 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. Let’s talk about these two... > However, you should not define the new Transform Id(s) here: that should > 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 > 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. Let me check with Shota on this. It may be that it can be deleted with no significant impact. > > 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? 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 > 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). > Thanks for the careful read & thoughtful feedback, —Rod
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
