Hi William, thank you for these comments. Please see inline.
> Hi, > > I support the adoption of this draft. > I've read the very early version and thought it was quite useful. > I've read it again and still believe it's important and useful. I believe > we're highly likely to implement this > draft. > > > Some quick comments below: > > 1) I feel the title "Alternate approach" doesn't reflect the value of this > draft well. This draft achieves the > goals of using PPK to protect the initiated IKE SA and creating or rekeying > SAs with a new PPK. These are > notable improvements in how PPK can be better used to defend against quantum > attacks. I'm a fan of > Quantum Key Distribution (QKD) and PPKs can be easily and frequently changed > when using QKD. This > draft is well suited in integrating into the solution of QKD. I feel this > draft is more useful than RFC 8784, > especially when used together with QKD. When compared with RFC 8784, the > draft only has a cost of the > round of IKE_INTERMIDATE exchange, and this cost is relatively small, at > least to me. So I prefer > something like "Enhanced approach" rather than "Alternate approach". Good point. Actually, the draft has went a bit away from the point it was just an alternative way to use PPK :-) I don't have objections to "Enhanced approach", but first wat to see more proposals. > 2) I strongly recommend adding support for using a new PPK for creating the > first Child SA, i.e., support > sending PPK_IDENTITY_KEY notifications in IKE_AUTH. This draft already > supports using different PPKs > for creating the first IKE SA, creating the additional Child SAs, and > rekeying both IKE and Child SAs. For > the scenario when a stronger security requirement is needed, for example, one > PPK for one SA, what is > missing in the current draft is using a new PPK for creating the first Child > SA. Using PPKs in the IKE_AUTH > exchange is similar to using PPKs in the CREATE_CHILD_SA exchange as defined > in section 3.2. So, I > believe adding support for using PPKs in the IKE_AUTH exchange is a small > modification to the draft but > complementary to the whole solution. The integration solution of IPsec and > QKD would significantly > benefit from this draft and this complement. So, you want to be able to use separate PPKs for IKE SA and for all its Child SAs, including the very first one? > 3) For the last paragraph of section 3.1, > Since the responder selects PPK before it knows the identity of the > initiator, a situation may occur, when the responder agrees to use > some PPK in the IKE_INTERMEDIATE exchange, but during the IKE_AUTH > exchange discovers that this particular PPK is not associated with > the initiator's identity in its local policy. Note, that the > responder does have this PPK, but it is just not listed among the > PPKs for using with this initiator. In this case the responder > SHOULD abort negotiation and return back the AUTHENTICATION_FAILED > notification to be consistent with its policy. However, if using PPK > with this initiator is marked optional in the local policy, then the > responder MAY continue creating IKE SA using the negotiated "wrong" > PPK. > Regarding the situation that the PPK is not associated with the initiator's > identity in the responder's local > policy, I think the right choice is to not use that PPK, i.e., aborting the > negotiation. But, because this > seems not to be a fatal fault, I can also accept the handling that the > responder will use this "wrong" PPK > if it is configured to do so. But I don't feel the causal logic described in > the last sentence is correct. If > using PPK with this initiator is marked optional in the responder's local > policy, it only means the > responder can use PPK or not use PPK with the initiator, but doesn't mean the > "wrong" PPK can be used. > I suggest the last sentence be reworded to " However, the responder MAY > continue creating IKE SA using > the negotiated "wrong" PPK if this situation is marked acceptable in its > local policy." OK, makes sense. > Two nits: > 1) In the first paragraph of section 3.1.1, there is a missing ")" after > "(for example, as defined > in [RFC9370]". > 2) Also in section 3.1.1, suggest the following changes: > OLD: In the formula above Ni and Nr are nonces from the IKE_SA_INIT exchange > and SPIi, SPIr - SPIs of > the IKE SA being created. > NEW: In the formula above, Ni and Nr are nonces from the IKE_SA_INIT > exchange, and SPIi and SPIr are > the SPIs of the IKE SA being created. Fixed, thank you. Regards, Valery. > Regards & Thanks！ > Wei PAN (潘伟) > > > -----Original Message----- > > From: IPsec <[email protected]> On Behalf Of Tero Kivinen > > Sent: Tuesday, November 28, 2023 2:32 AM > > To: [email protected] > > Subject: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt > > > > This is two week adoption call for draft-smyslov-ipsecme-ikev2-qr-alt. > > If you support adopting this document as a working group document for > > IPsecME to work on, and then at some point publish this as an RFC, send > > comments to this list. > > > > This adoption call ends 2023-12-13. > > > > Note, that I do want to see people saying that they think this document > is > > worth of working on, and that they plan to review and comment on it. If > I > > only get one or two people (including authors :-) to say they support > this > > work, then there is no point of work on this in WG. > > -- > > [email protected] > > > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
