Hi, this erratum is correct. Thanks to Thom for finding it.
Fortunately, the error is in a non-normative Appendix in an example and relates to a different IKE extension (RFC9242). Thus, I believe that existing implementations of RFC9370 are not affected. I think that the resolution should be HFDU. Regards, Valery. > -----Original Message----- > From: [email protected] <[email protected]> > Sent: Wednesday, July 8, 2026 10:29 PM > To: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; > [email protected]; [email protected]; > [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: [Technical Errata Reported] RFC9370 (9022) > > The following errata report has been submitted for RFC9370, > "Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 > (IKEv2)" > > -------------------------------------- > You may review the report below and at: > https://errata.rfc-editor.org/eid9022/ > > -------------------------------------- > Type: Technical > Reported by: Thom Wiggers <[email protected]> > > Section A.1 says: > > Original Text > ------------- > The updated SKEYSEED value is then used to derive the following > keying materials. > > {SK_d(1) | SK_ai(1) | SK_ar(1) | SK_ei(1) | SK_er(1) | SK_pi(1) | > SK_pr(1)} = prf+ (SKEYSEED(1), Ni | Nr | SPIi | SPIr) > > As per [RFC9242], both peers compute IntAuth_i1 and IntAuth_r1 using > the SK_pi(1) and SK_pr(1) keys, respectively. These values are > required in the IKE_AUTH phase of the exchange. > > Corrected Text > -------------- > The updated SKEYSEED value is then used to derive the following > keying materials. > > {SK_d(1) | SK_ai(1) | SK_ar(1) | SK_ei(1) | SK_er(1) | SK_pi(1) | > SK_pr(1)} = prf+ (SKEYSEED(1), Ni | Nr | SPIi | SPIr) > > As per [RFC9242], both peers compute IntAuth_i1 and IntAuth_r1 using > the SK_pi and SK_pr keys from IKE_SA_INIT (i.e., the value preceding the > exchange), > respectively. These values are required in the IKE_AUTH phase of the > exchange. > > Notes > ----- > RFC 9242 states that the keys used during epoch i are the keys from epoch > (i-1). From RFC 9242, section 3.3.2: > > Each calculation of IntAuth_[i/r]* uses its own keys SK_p[i/r]*, > which are the most recently updated SK_p[i/r] keys available before > the corresponded IKE_INTERMEDIATE exchange is started. > > Instructions: > ------------- > This erratum is currently posted as "Reported". Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC9370 (draft-ietf-ipsecme-ikev2-multiple-ke) > -------------------------------------- > Title : Multiple Key Exchanges in the Internet Key Exchange > Protocol Version 2 (IKEv2) > Publication Date : May 2023 > Author(s) : CJ. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D. > Van Geest, O. Garcia-Morchon, V. Smyslov > Category : Proposed Standard > Source : ipsecme (sec) > Stream : IETF > Verifying Party : IESG _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
