thanks, this make sense. It would be nice to document the clarification somewhere, maybe either go into 9370bis(if there gona be one) or draft-kampanakis-ml-kem-ikev2 (if it gets adopted) ?
From: Valery Smyslov <smyslov.i...@gmail.com> Sent: Thursday, September 19, 2024 1:01 AM To: Jun Hu (Nokia) <jun...@nokia.com> Cc: ipsec@ietf.org Subject: RE: [IPsec] interaction between RFC9370 and RFC8784 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Jun, RFC8784 and RFC9370 are not interdependent, thus the can be used together. Among the options you listed, only b) is feasible. You cannot use PPK unless you know its identity, which is sent in the IKE_AUTH request. Thus, all IKE_INTERMEDIATE exchanges are performed as defined in 9370 and IKE_AUTH is performed as defined in 8784. After last IKE_INTERMEDIATE is completed and keys are updated as per 9370, the initiator applies PPK and re-calculate keys again as per 8784. Note, that it is also possible to use draft-ietf-ipsecme-ikev2-qr-alt with RFC 9370. The draft explicitly says: If a series of the IKE_INTERMEDIATE exchanges takes place, the PPK_IDENTITY_KEY notification(s) MUST be sent in the last one, i.e. in the IKE_INTERMEDIATE exchange immediately preceding the IKE_AUTH exchange. and later: Note that if the IKE SA keys are also recalculated as the result of the other actions performed in the IKE_INTERMEDIATE exchange (for example, as defined in [RFC9370]), then applying PPK MUST be done after all of them, so that recalculating IKE SA keys with PPK is the last action before they are used in the IKE_AUTH exchange. Hope this helps. Regards, Valery. From: Jun Hu (Nokia) <jun.hu=40nokia....@dmarc.ietf.org<mailto:jun.hu=40nokia....@dmarc.ietf.org>> Sent: Wednesday, September 18, 2024 9:16 PM To: ipsec@ietf.org<mailto:ipsec@ietf.org> Subject: [IPsec] interaction between RFC9370 and RFC8784 Hi, I don't know if this has been discussed before, but what would be the interaction between 9370 and 8784 if they are both used? I know it seems unnecessary to use both of them, but it could happen technically, I see following options: 1. Not allowing this: e.g. if a responder receives USE_PPK and ADDKEx transform that is PQC alg in IKE_SA_INIT request, it choose to only use on mechanism, e.g. if choose to use 9370, then responder doesn't include USE_PPK in response 2. Support this, then the question is how would ppk be used? * Used in every key exchange, to derive the SK_d, sk_pi, sk_pr as specified in 8784 * Used only in last round key exchange * Used only in first round #1 seems simpler to implement, but is there any security benefit to do #2, like ppk used as another level security enhancement? I know there are IPsec implementations(include mine) already implemented 8784, and now in process of implementing 9370 for PQC, I think it will be beneficial to have some clarity on this interaction. ------ Hu Jun
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
