[AFS3-std] removing SetCallBackKey from the rxgk-afs document

[Benjamin Kaduk]

Hi all,

Simon and I got a lot of time to chat last week at the EAKC.  (Hooray!)

In particular, Simon had a few ideas for how to render SetCallBackKey 
unnecessary (one of which is used by YFS), and neither of us particularly 
like having the RPC around.

The summary after analysis is: with the current SetCallBackKey, the file 
server must maintain a mapping of PrAuthName<>s to (key, token) pairs 
(though the token can be empty if the CM wishes it to be).  This mapping 
is used when creating callbacks as a result of RPCs during normal 
operation, and the PrAuthName<> being looked up is one that was cached in 
the server connection state, since the name vector comes from the token, 
which is only seen in the rx response.  This is the important part, that 
data from the response  must be cached in the server connection state.

But there's no real reason to involve an extra lookup -- the (key, token) 
pair could itself be stored in the server connection state, and all 
callbacks generated as a result of that connection would use that callback 
key.  It turns out that we have a built-in way to get application-specific 
data into a response packet -- the 'appdata' field of the authenticator. 
Currently rxgk-afs just sets that to the CM uuid, but it could also 
include a key/token (and also the uuid of the server we're trying to talk 
to, as an extra consistency check).  The file server can pull the 
key/token from the authenticator and cache it directly.

Alternatively, we could keep SetCallBackKey but require that it be called 
on a connection before any secure callbacks are issued on that connection, 
and have the key that is set apply only to that connection (again, being 
cached in the server connection state).  There would need to be some 
thought about when the key comes into effect and what sequencing 
guarantees are made, though, so this approach seems less interesting to 
me.

I plan for the next upload of draft-wilkinson-afs3-rxgk-afs to take the 
first approach, omitting RXAFS_SetCallBackKey and putting key information 
in the appdata field.  The token format will change back to having just a 
single list of identities (but the key combination portion will remain 
unchanged, for the same reasons it is currently present).

-Ben