[AFS3-std] file server token master keys need to be unique per-fileserver

[Benjamin Kaduk]

(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