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]
