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

[Benjamin Kaduk]

On Mon, 4 Feb 2013, Jeffrey Hutzelman wrote:

> 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.

Ah, it's an RXGK_Token, not an RXGK_TokenContainer, so the K0 is still 
available.

> 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.

Okay.

This does not seem to resolve the question of which identity is to be 
used, though.  It almost seems like we should consider the token passed as 
mech_data to be a printed token with empty identity (and thus use the 
token securing the rx connection over which the RPC is made for the 
identity comparison).  We probably want more text about what goes in this 
RXGK_Token, regardless.

-Ben