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
