[AFS3-std] rxgk-afs SetCallBackKey: one token or two?

Jeffrey Hutzelman jhutz@cmu.edu
Mon, 04 Feb 2013 14:19:19 -0500


On Fri, 2013-02-01 at 17:02 -0500, Benjamin Kaduk wrote:
> The RXAFS_SetCallBackKey RPC MUST be called over an rxgk-secured 
> connection (when being used with rxgk), and one of its arguments is an 
> XDR-encoded token.  There is also a token used to secure the rx connection 
> over which the RPC is made.  Do we expect these tokens to always be the 
> same?  (The phrase "protected with a different cache manager identity" is 
> used, which is a little ambiguous which token's identity would be 
> relevant.)

No; in fact, they are expected never to be the same.

This RPC allows a cache manager to give the fileserver a token to be
used when authenticating callback RPCs made by the fileserver to that
cache manager.  This allows callbacks to be authenticated.

Since the callback token is used in the reverse direction, from rxgk's
point of view, the fileserver will be acting as client and the CM as
server.  So, it can't be the same token, ever.

The expectation is that the CM will construct a callback token,
protected by a service key that only it knows.  Since it only needs to
be usable for the life of the CM, it can be generated at startup and
kept in memory.  Of course, a CM should issue new callback tokens from
time to time, as the old ones expire.

-- Jeff