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". 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. 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." 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. Regards & Thanks! Wei PAN (潘伟) > -----Original Message----- > From: IPsec <ipsec-boun...@ietf.org> On Behalf Of Tero Kivinen > Sent: Tuesday, November 28, 2023 2:32 AM > To: ipsec@ietf.org > 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. > -- > kivi...@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec