Hi, I won’t speak for implementers, but as a person who is looking at security proofs:
- Please separate PRF from PRF+ - KMAC presumably separates the value from the input S correctly, so you don’t have to worry about `0x01` being part of an input to PRF somehow if you use context strings. I would expect that KDFs continue to have label inputs. https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final defines this API with labels. Cheers, Thom > Op 21 jul 2026, om 09:13 heeft Ben S3 <[email protected]> > het volgende geschreven: > > 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) > > _______________________________________________ > IPsec mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
