[AFS3-std] draft-wilkinson-afs3-rxgk-afs-03 addresses SetCallBackKey

[Benjamin Kaduk]

I have made an update to the rxgk-afs integration document, but the 
internet-draft submission tool is not letting me finish the submission, 
at the moment.  In particular, the update has the SetCallBackKey now 
providing both a token and a key (and some other details for the 
connection).

For now, I've put the rendered copy up at 
http://web.mit.edu/kaduk/Public/draft-wilkinson-afs3-rxgk-afs-03.txt

On Mon, 4 Mar 2013, Simon Wilkinson wrote:

>
> On 4 Mar 2013, at 17:27, Benjamin Kaduk wrote:
>
> There are other approaches, but they involve you either having to store 
> a key for every user who is accessing the fileserver (rather than just 
> every CM), or having to store which FID was last accessed by which key 
> in order to determine how to encrypt the callback. Neither of these are 
> desirable from an implementation stand point. Using CM identities has 
> the big advantage that the volume of information being tracked by the 
> fileserver for each client isn't dramatically larger, or more complex, 
> than it is today.

I have mostly convinced myself that the server does need to associate a 
key/token with the host entry for a given callback, and in particular the 
callback list for a given fid could contain multiple entries for the same 
host with different keys.

The scenario is: legitimate cache manager calls SetCallBackKey and then 
acquires a callback for the fid, then an attacker spoofs the host/uuid to 
call SetCallBackKey and (re-)acquire a callback for that fid.  The 
fileserver can either break the existing callback when the new 
SetCallBackKey call is made, or store a list of keys for the host and 
accept the new callback.  Clearly, in the latter case, we need to have two 
callback entries for the fid, one for the real host and one for the 
attacker.  The former case is less clear-cut, but having the key handy 
might make breaking just those callbacks easier.  The latter case might 
limit the scope of damage an attacker could perform, though I'd need to 
think about it more.

In any case, I am inclined to require that calls generating extended 
callback promises must be performed using a combined token including the 
cache manager identity, and only the cache manager identity (a 
single-identity token) should be used for the SetCallBackKey.  We may need 
to adjust the AFSCombineTokens text slightly to enforce this; I think we 
currently only say that cache managers with multiple users SHOULD provide 
token1 as a CM token, but do not restrict other uses of token1.  Requiring 
that token1's identity be a single host-based name seems like a matter for 
application policy, not a protocol-level constraint, so I did not add 
any text of that nature.

A solution that required an exact match between the identities for 
SetCallBackKey and XCB-generating calls (that is, one which requires a 
combined token to be used for SetCallBackKey when combined tokens are in 
use, so that there would be as many XCB connection keys as users on the 
machine) should be functional, but seems to add a potentially large amount 
of overhead for minimal (if any?) benefit.

-Ben