Hi Valery, уто, 25. јун 2024. у 10:45 Valery Smyslov <smyslov.i...@gmail.com> је написао/ла:
> Hi Vukašin, > > > > Hi Valery, > > > > While updating the code logic to the latest version of the draft some > questions came up to me: > > > > 1. Assume the initiator and responder both already support RFC 8784. > > If the initiator sends USE_PPK_ALT notify, and does not support > IKE_INTERMEDIATE exchange, will the initiator and responder be able to use > the alternative PPK rotation for rekeying the SA's and creating new > PPK-protected SA's? > > > > That is, can this alternative approach be used independent of the > IKE_INTERMEDIATE exchange support? > > > > A sentence in the draft "The initiator that supports both RFC8784 and this > specification MAY include both the *USE_PPK_ALT (along with the > INTERMEDIATE_EXCHANGE_SUPPORTED)* and the USE_PPK notifications if it is > configured to use either specification." makes me think the alternative > approach, thus also the PPK rotation and rekeying, must be used only if the > INTERMEDIATE exchange occurs. > > > > 2. Similarly, assume neither the initiator nor the responder support RFC > 8784 and INTERMEDIATE exchange. Can they implement the alternative approach > and use it for, e.g. rekeying (and adding PPK protection to the original > unprotected IKE SA) and creating new PPK-protected SA's? > > > > The current draft assumes that alternative use of PPK is only > possible if peers support the IKE_INTERMEDIATE exchange: > > > > The IKE initiator which supports the IKE_INTERMEDIATE exchange and > > wants to use PPK to protect initial IKE SA includes the > > INTERMEDIATE_EXCHANGE_SUPPORTED notification and a notification of > > type USE_PPK_ALT in the IKE_SA_INIT request. > > > > Thus, peers may only negotiate support for the alternative > approach if they also support IKE_INTERMEDIATE. > > > > However, the situation with the CREATE_CHILD_SA exchange is a bit > trickier. > > Actually, the initiator may include PPK_IDENTITY_KEY notification > in this exchange > > even if it didn’t negotiate the support for this extension in the > IKE_SA_INIT. > > In this case, if the responder doesn’t support use of PPKs in > CREATE_CHILD_SA > > (even if it supports use PPKS in the initial exchange) or is > configured to tie > > these two cases (don’t use it in CREATE_CHILD_SA unless > negotiation is successful in IKE_SA_INIT), > > then the responder will ignore this notification and the SA will > be created with no PPK. > > This may also happen even if the responder supports use of PPKs > in CREATE_CHILD_SA, > > but for any reason cannot use them right now, e.g. no proposed > PPKs are available. > > > > The two situations may look unrealistic, but clarity on the issues would > be better for cleaner code logic. I suggest a sentence or two are added > somewhere (with MUST, SHOULD, etc. wording) that would clarify how > implementations should behave in the above two situations. In the case I > missed something in the draft about this, I apologize. > > > > I think some clarification may be added, that the use of PPKs in > CREATE_CHILD_SA > > is somewhat independent from initial exchanges, however, the > initiator must be prepared > > to the situation, when the responder doesn’t support this > functionality or refuses to use it. > > > > Any thoughts whether this approach is OK? > Thank you, now everything is clear to me. Adding this explanation that use of PPKs in CREATE_CHILD_SA is independent of initial exchanges sounds good to me! Cheers, Vukašin > Regards, > > Valery. > > > > Thank you in advance! > > > > Regards, > > Vukašin >
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
