Hi Tero, > 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).
My point was that it is sometimes tricky to get key data to use as a second argument to prf. Many APIs assume that keys are always the first argument. It may be easier for session keys (which results of KE are) and may be more complex for long-term keys (like PPK). Or may be impossible at all unless you hack APIs. The current design tries to avoid unnecessary complexities. > > 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. I disagree. The idea was that IKE_INTERMEDIATE specification defines only the intermediate exchange and not the numerous ways it can be used. Not all of possible use require key derivation (like RFC 9593). And mixing keys is often needed not only for initial IKE SA, but in CREATE_CHILD_SA too, which is not related to IKE_INTERMEDIATE at all. On the other hand, there may be various ways to mix keys, so I don't think we should stick with the single way for all purposes. Note also, that mixing keys, as specified in 9370 and this draft affects not only IKE_INTERMEDIATE, but also CREATE_CHILD_SA, so this would be strange to specify it in IKE_INTERMEDIATE specification. > 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. Scott was co-author of both RFCs, thus I don't think there are any security issues there. What you propose will in fact complicate implementations. I assume that this specification will most likely be implemented by those, who already implemented RFC 8784, and there is a substantial re-use of code. On the other hand, RFC 9370 is more difficult to implement (and IKE_INTERMEDIATE is not the only source of complexity, IKE_FOLLOWUP_KE is another). There would be many places in code when additional conditions should be added to implement your proposal. Regards, Valery. > -- > kivi...@iki.fi _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
