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

[Benjamin Kaduk]

On Mon, 4 Feb 2013, Benjamin Kaduk wrote:

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

Sorry for replying to myself, but going back to Simon's mail of 7 June 
2012 makes it clear that the identity which authenticates the RPC is the 
identity which we are intended to use.

I'm not sure I'm reading the end of that mail properly, though (quoted 
below):
% Making all of this work complicates things significantly at the client,
% which must now maintain an rxgk token signing service, so that it can
% issue a proper token to the server for each key that it has in play,
% such that it can then pull the key out of that token.

Does this mean that we would need to change SetCallBackKey to give the 
server both a TokenContainer and a Token, so that the TokenContainer (with 
its encrypted token encrypted to a key known to the client) can be used to 
initiate an rxgk connection from the fileserver to the client, in order to 
deliver the ExtendedCallBack over a properly secured channel?

In the present form of the rxgk-afs draft we only give the (unencrypted) 
token, which is just enough to share a *key* between the two sides, but it 
would seem that extra magic would be needed to get both sides to use this 
key for the ExtendedCallBacks in the absence of a proper token to include 
in the RXGK_Response.

Am I completely off-track, here?

-Ben