Hi, I agree with Rebecca's suggestion. Especially the first one, regarding introducing the USE_EARLY_PPK notify, since it seems the introduction would also make the implementation of the draft (combined with RFC 8784) 'cleaner'/easier to understand and verify.
BTW. I support the adoption of the draft as well (there is a newer -08 version). Regards, Vukašin Karadžić уто, 22. авг 2023. у 21:01 <ipsec-requ...@ietf.org> је написао/ла: > Message: 1 > Date: Mon, 21 Aug 2023 21:25:08 +0000 > From: Rebecca Guthrie <rmgu...@uwe.nsa.gov> > To: Valery Smyslov <s...@elvis.ru>, IPsecME WG <ipsec@ietf.org> > Cc: "ipsec-cha...@ietf.org" <ipsec-cha...@ietf.org> > Subject: Re: [IPsec] New Version Notification for > draft-smyslov-ipsecme-ikev2-qr-alt-07.txt > Message-ID: > < > ph8pr09mb92945faff119de5abfe3601bfc...@ph8pr09mb9294.namprd09.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > Greetings, > > I wrote to the mail list before IETF 117 that I support adoption of > draft-smyslov-ipsecme-ikev2-qr-alt, and I have comments I would like to > make. The draft did not get discussed at 117, so I'll share my comments > here. > > Comment: I suggest that the draft define a new Notify Payload, > USE_EARLY_PPK, that uniquely specifies support for this draft, rather than > relying on USE_PPK and INTERMEDIATE_EXCHANGE_SUPPORTED. > > Explanation: There was agreement at the 116 meeting that the extension > specified in this draft should not be used in conjunction with RFC 8784. > The draft does allow for a fall-back to the PSK mechanism specified in RFC > 8784 if the mechanism specified in this draft is not supported by the > responder- this necessitates USE_PPK to be used ambiguously, such that its > inclusion by the initiator in IKE_SA_INIT can represent the initiator's > intent to do either (this draft's PSK mechanism or RFC 8784). > > However, since it is still possible that RFC 8784 and RFC 9242 are used > together, the inclusion of both USE_PPK and INTERMEDIATE_EXCHANGE_SUPPORTED > does not uniquely specify this draft; rather, it could mean that an IKE > peer supports RFC 8784, plans to use IKE_INTERMEDIATE for another purpose, > and does not support this draft. > > There may be a time where certain IKEv2 instances require the use of this > draft such that the peer will abort the creation of the IKE SA if the > extension specified in this draft cannot be supported. The peer may require > the use of this draft either after transitioning away from RFC 8784, or > having never supported RFC 8784 at all. In either case, the initiator and > responder must be able to negotiate the use of this extension in > IKE_SA_INIT. As the draft is currently written, depending on assumptions > made by initiator and responder and depending on what is supported, they > are able to get all the way to the end of IKE_INTERMEDIATE before realizing > requirements cannot be met. > > In the case where the Initiator requires draft-smslov-ipsecme-ikev2-qr-alt > and RFC 9370, and the Responder supports RFC 8784 and RFC 9370, both will > include USE_PPK and INTERMEDIATE_EXCHANGE_SUPPORTED in their respective > IKE_SA_INIT messages, but the Initiator will not discover that it must > abandon the SA until it has computed all of the intermediate key exchanges > only to receive no response to its PPK_IDENTITY_KEY notification(s). > > On the other hand, if the Responder requires the use of this draft and the > Initiator instead supports RFC 8784, it is unclear what the responder > should do when it does not receive a PPK negotiation message from the > Initiator in the last IKE_INTERMEDIATE exchange. It is possible that the > Responder may be expecting another IKE_INTERMEDIATE message containing PPK > negotiation information, but if the Initiator does not support this > extension, then it would instead begin the IKE_AUTH exchange. > > Defining a new Notify Payload, USE_EARLY_PPK, that uniquely specifies > support for this draft would remove the described ambiguity. In order to > indicate support for the fall-back to RFC 8784 capability, the Initiator > would send both USE_PPK and USE_EARLY_PPK Notify Payloads. It should be the > case that when these are sent together, the preference for USE_EARLY_PPK is > implicit. If the responder also supports USE_EARLY_PPK, it will ignore > USE_PPK. If the responder does not support or does not recognize > USE_EARLY_PPK, it may still support USE_PPK, and can proceed with the PSK > mechanism described in RFC 8784. > > Comment: During IKE_INTERMEDIATE, use N(PPK_IDENTITY) in initiator message > and N(PPK_IDENTITY_KEY) in responder message, only for the single PPK the > responder has selected. > > Explanation: Currently, in the last IKE_INTERMEDIATE, the initiator sends > SK { ... N(PPK_IDENTITY_KEY, PPK_ID_1) [ , ... , N(PPK_IDENTITY_KEY, > PPK_ID_n ) ] } where PPK_IDENTITY_KEY is sent for each PPK_ID the initiator > is offering. The responder then sends SK { N(PPK_IDENTITY) } for the PPK it > selects, using the N(PPK_IDENTITY) Notify Payload specified in RFC 8784. > > It's my understanding that the initiator and responder expect the PPKs to > match for any given PPK_ID (i.e. that there is a very high likelihood that > they match). If this assumption is incorrect, please correct me, but if > this is the case, in order to perform fewer computations and shrink the > size of the initiator message, it may make sense to use N(PPK_IDENTITY) > [RFC8784] in the initiator message, and the new N(PPK_IDENTITY_KEY) in the > responder message, only for the single PPK the responder has selected. > Then, before the initiator sends IKE_AUTH, it can use the confirmation > value sent by the responder in N(PPK_IDENTITY_KEY) to check that the PPK > values the initiator and responder are using match. (If they do not match, > the initiator could send another IKE_INTERMEDIATE containing > N(PPK_IDENTITY_KEY)s for each PPK it supports, as currently specified.) > Depending on how many PPKs the initiator offers, this may not considerably > shrink the message size. > > Comment: Update Security Considerations section. > > Explanation: The Security Considerations section currently cites RFC 8784. > I'd suggest that RFC 9242's security considerations be referenced as well, > and I'd suggest repeating some of the security considerations from RFC 9370 > that are relevant here- in particular, the second paragraph of RFC 9370 > discusses how to ensure quantum resistance in Transform Types 2 and 3- this > is worth repeating here, especially in the case that this draft is used > independently (without RFC 9370) to provide QR. > > In RFC 8784 and RFC 9370, there is discussion of the security of each > extension with regard to an active attacker- it may be useful in this draft > to extend this discussion here in order to cover 1. the addition of > IKE_INTERMEDIATE, 2. the fact that QR is achieved prior to IKE_AUTH (either > if this draft is used on its own or in conjunction with RFC 9370), and 3. > the fact that authentication is QR (compared to RFC 9370 alone). > > - Rebecca > > Rebecca Guthrie > she/her > Center for Cybersecurity Standards (CCSS) > Cybersecurity Collaboration Center (CCC) > National Security Agency (NSA) >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec