Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt
Greetings ipsecme, Wanted to follow up about draft-smyslov-ipsecme-ikev2-qr-alt. Has there been sufficient support expressed in order for this draft to be adopted? From the adoption call, it looks like 7 people (including author) expressed support for adoption, no one spoke against adoption, 2 implementations (including the author's) exist, and there are 2 offers to review. Thanks, Rebecca Rebecca Guthrie she/her Center for Cybersecurity Standards (CCSS) Cybersecurity Collaboration Center (CCC) National Security Agency (NSA) -Original Message- From: IPsec On Behalf Of Tero Kivinen Sent: Monday, November 27, 2023 1:32 PM 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
Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt
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 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
Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt
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 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 > >
Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt
I support adoption as well. Regards, Vukašin Date: Mon, 27 Nov 2023 14:20:42 -0500 (EST) > From: Paul Wouters > To: Tero Kivinen > Cc: ipsec@ietf.org > Subject: Re: [IPsec] WG Adoption call for > draft-smyslov-ipsecme-ikev2-qr-alt > Message-ID: <83fa6733-93fc-b282-d64e-cac6aaf8c...@nohats.ca> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On Mon, 27 Nov 2023, Tero Kivinen wrote: > > > 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. > > I support WG adption. The Libreswan Project has implemented the -08 version > already and is working on the latest -09 version. > > Paul > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt
I also support adoption > -Original Message- > From: IPsec On Behalf Of Rebecca Guthrie > Sent: Tuesday, November 28, 2023 11:30 AM > To: Tero Kivinen ; ipsec@ietf.org > Subject: Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt > > I support adoption, and can review. > > Rebecca Guthrie > she/her > Center for Cybersecurity Standards (CCSS) Cybersecurity Collaboration Center > (CCC) National Security Agency (NSA) > > -Original Message- > From: IPsec On Behalf Of Tero Kivinen > Sent: Monday, November 27, 2023 1:32 PM > 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt
I support adoption, and can review. Rebecca Guthrie she/her Center for Cybersecurity Standards (CCSS) Cybersecurity Collaboration Center (CCC) National Security Agency (NSA) -Original Message- From: IPsec On Behalf Of Tero Kivinen Sent: Monday, November 27, 2023 1:32 PM 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
Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt
I support adoption. And I will review. -Original Message- From: IPsec On Behalf Of Tero Kivinen Sent: Monday, November 27, 2023 1:32 PM To: ipsec@ietf.org Subject: [EXTERNAL] [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. 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
Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt
HI, I support adoption of this document (I am its author). We also have implemented it. Regards, Valery. > 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
Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt
On Mon, 27 Nov 2023, Tero Kivinen wrote: 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. I support WG adption. The Libreswan Project has implemented the -08 version already and is working on the latest -09 version. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
