[AFS3-std] rxgk-afs: moving SetCallBackKey to a separate document?

[Benjamin Kaduk]

On Sat, 2 Mar 2013, Simon Wilkinson wrote:

> On 2 Mar 2013, at 18:30, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
>> I'm in a similar position as jhutz; I think I understand what the callback protection mechanism should look like, and it doesn't involve protocol level changes outside of SetCallBackKey.
>
> When a server receives a SetCallbackKey RPC, which set of callbacks does 
> that RPC apply to?

The flip answer is of course "those from the same client" [over 
connections using the indicated security index].

Actually specifying what that means does require some effort; the current 
text in the rxgk-afs document is attempting to say that RPCs made over an 
rxgk-authenticated connection, where one of the identities in the token 
used to authenticate the connection matches the identity used to secure 
the SetCallBackKey RPC, will use the key set by the SetCallBackKey RPC. 
This is okay for keyed cache managers, where the intent is that a CM 
identity will be unique per host, and the SetCallBackKey RPC is called 
using a token with just one identity, the CM-specific identity.  If that 
CM identity is shared between multiple hosts or a single-user CM is using 
the user's identity to register SetCallBackKey, this falls apart quickly.

But, we have other ways to identify clients.  In particular, we have a 
UUID for the cache manager, and this UUID is sent as the appdata field of 
the rxgk authenticator.  Given that we are indexing fileservers by UUID 
for AFSCombineTokens purposes, it seems reasonable to index clients by 
cache manager UUID for callback purposes.  The (UUID, 
SetCallBackKey-securing identity) pair seems like it should be enough to 
uniquely identify a client for callback purposes, at least on quick 
inspection.

-Ben