Valery Smyslov writes: > The draft uses the method similar to RFC 8784: > > SK_d = prf+ (PPK, SK_d') > > with the replacement of SK_d with SKEYSEED. > > The rationale for using the current form: > 1. This is the most straightforward and conservative use of prf, > when the first argument (PPK) is uniformly random key.
The Multiple Key Echange RFC9370 uses SK_d which is uniformly random key as it is generated using PRF. The PPK is NOT uniformly random key, as it is usually generated by user, and might for example only contain base64-characters (as recommended Mixing PSKs in IKEv2 for PQ Security RFC 8784 for the PPK_ID_FIXED). So SK_d is uniformly random, PPK might be or might not be depending how it was generated. I do not think it affects security as much how it is generated as long as it has enough entropy, but if you are concerned that PRF might not be as good if the key is not uuniformy random, then you really should use SK_d instead ofPPK. > 2. The first argument to prf is usually a key while the second is > usually a (public) data, some API to crypto libraries may not > allow use of a secret key as a data and may not allow export > it, so the current use of PPK is generally easier to implement. Here we have two keys, SK_d and PPK, and one of them is uniformly random (SK_d), and other might be uniformly random or might be very much not uniformly random (PPK). > 3. The draft can be seen as an successor to RFC 8784, and it is > believed that these two will be implemented together, thus > re-using the computation method from RFC 8784 makes sense. In > contrast, the draft is completely independent from RFC 9370. It is independent from the Multiple Key Exchanges RFC9370, but uses IKE_INTERMEDIATE echange, and the original PPK in IKE_AUTH RFC 8784 does not, and the text how to mix new keys to the crypto context of the IKEv2 SA perhaps should have been in the IKE_INTERMEDIATE RFC, not in the Multiple key exchanges RFC, as we can generate ways to mix new keys to crypto context also in other places than multiple key exchanges. And we did have much more discussion about the mixing of the keys when we were working on the multiple key exchanges RFC than when we were working on the PPK in IKE_AUTH RFC, so I would consider the multiple key exchanges version to have received more reviews. -- kivi...@iki.fi _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
