(was Re: [AFS3-std] last call comments on draft-wilkinson-afs3-rxgk-afs-07)
On Thu, 14 May 2015, Benjamin Kaduk wrote: > In section 9, when no cm_tok is supplied, the K0 from the user_tok is > currently reused unchanged in the new_token. There doesn't seem to be any > particular reason for directly reusing this key material, so I would > propose that we use some sort of key-derivation scheme with a fixed salt > and the fileserver uuid as a pepper, just from the sense of crypto best > practices against reusing key material for different applications. The crux of the issue is that, in the encrypted token, the file server receives a key which is useful somewhere else. For the "reuse K0 unchanged" case with no cm_tok, this key is useful against database servers as well as other file servers being accessed without a cm_tok. However, the case where a cm_tok is supplied is *also* affected -- the key generation in that case depends only on the keys from the input tokens, so a file server token for fs1 has the same K0 as a file server token for fs2, with the scheme given in the -07. Since a goal is to allow file servers to be operated by parties which do not trust each other, this is a problem. (I elide the part of the attack wherein a rogue file server sniffs a token for the server it is targetting off the network or otherwise comes up with a way to use the K0 in question, but that does not seem like the interesting part of the attack.) I believe that we need to mix the target file server UUID into the generated K0 in all calls to AFSCombineTokens, regardless of whether a cm_tok is provided. This does not require a change to the core rxgk specification (which is finished) where CombineTokens is defined, since we can just stop incorporating its use of KRB-CF-FX2 by reference and specify an alternative which does incorporate the UUID. This does mean that there is not much incentive for someone to implement the plain CombineTokens, but that is not exactly problematic. -Ben _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
