Hi Ben and authors, Personally, I strongly favor the fourth option (adding back the 0x01 in prf+).
In vanilla IKEv2, prf+ iteratively appends a counter to prevent collisions. Since we are switching to an XOF/KMAC to leverage single-call generation for the entire key material, we don't need the complex loops anymore. However, simply appending a fixed, single 0x01 byte to the input data before making the single call elegantly solves the issue. This approach completely eliminates the risk of prf and prf+ producing identical outputs from identical inputs. More importantly, it avoids any dependency on customization strings, offering 100% backward and forward compatibility with legacy hardware and future XOF algorithms. Best regards, Wang Xi From: Ben S3 <[email protected]> Sent: Tuesday, July 21, 2026 12:13 AM To: [email protected] Subject: [newsletter] [IPsec] Customisation strings with variable-length PRFs? Hi IPSECME, If you're watching the IPSECME WG live, you'll have just seen a presentation discussing whether or not to use customisation strings in variable-length PRFs that support them. draft-ietf-ipsecme-sha3 specifies the use of KMAC in IKE/ESP. Valery has very helpfully written draft-ietf-ipsecme-ikev2-prf-plus, which specifies a generic approach to using variable-length-output PRFs (i.e. XOFs) that draft-ietf-ipsecme-sha3 utilises. draft-ietf-ipsecme-ikev2-prf-plus proposes a change to the prf+ function when using an XOF. Instead of iteratively calling the PRF with a fixed output length to generate the required length of key material, instead you just call the PRF directly specifying the desired output length, so the entire key material can be generated in a single call. This is a major benefit from using an XOF, and we wouldn't want to change this. However, this change does open a potential can of worms, in that we now have prf+(K, S, L) === prf(K, S, L). This was not the case in vanilla IKEv2 (since during prf+ calculation a counter is appended to the input, so at the very least you'd have prf+(K, S) = prf(K, S | 0x01)). This means we have two ostensibly-different functions that are invoked in different contexts that give the same outputs when given the same inputs. This sort of thing could be potentially scary to cryptographers. For instance, consider the following derivations of SKEYSEED (following a rekey), and of KEYMAT (generated in a CREATE_CHILD_SA): SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr) When using KMAC, prf and prf+ are identical, hence if asking for the same amount of key material, given the same inputs these would produce the same outputs. In this case, it's probably fine, but there's lots of combinations we'd have to check to make sure they're safe (including future extensions), and the mere possibility of this sort of thing might make some uneasy. A way to remove any doubt would be to use customisation strings. KMAC supports use of a customisation string, which binds the output to the context in which it was generated, so there'd be no danger of generating the same value in two different contexts (this property would likely be easy to prove using a tool like Tamarin, though I have not done so). However, future standardised XOFs might not support customisation strings, and adding support for them in legacy IPsec implementations might be an undesirable amount of work. The current state of play is that draft-ietf-ipsecme-sha3 specifies use of (fixed) customisation strings wherever prf and prf+ are invoked, but draft-ietf-ipsecme-ikev2-prf-plus specifies leaving them as empty strings. I don't think the authors of either draft have strong opinions of what the best approach is, but we (the WG) should decide on an approach. A few viable possibilities are: * Don't use customisation strings at all: specify in draft-ietf-ipsecme-ikev2-prf-plus that customisation strings should always be empty * Specify use of customisation strings in all XOFs (present and future) that support them (this would probably be done in draft-ietf-ipsecme-ikev2-prf-plus) * Specify use of customisation strings on a per-algorithm basis (i.e. specify it in draft-ietf-ipsecme-sha3, and be agnostic on the point in draft-ietf-ipsecme-ikev2-prf-plus) * Something else? (e.g. add back the 0x01 in prf+) We need opinions from the WG on this to finish these two drafts off, so please share them here! Thanks, Ben (on behalf of the authors) *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
