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

[Jeffrey Hutzelman]

On Tue, 2013-02-12 at 17:39 -0600, Andrew Deason wrote:
> On Mon, 4 Feb 2013 18:42:07 -0500 (EST)
> Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> 
> > 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?
> 
> What you're saying makes sense to me. This was initially a little
> confusing for me to read because the term 'token' seems a little
> overloaded. In the base rxgk you have a 'token' which is an opaque
> application-specific identifier. And in rxgk-afs, that opaque identifier
> is a struct TokenContainer, which contains the encrypted struct Token.
> So, the 'token' is a TokenContainer, and a Token in rxgk-afs is
> something else. blegh.
> 
> But yes, anyway. I believe you are correct in what you wrote above... to
> put it another way:
> 
> The fileserver here is acting as an rxgk client. Normally an rxgk needs
> a 'token' from the application negotiation service, which for AFS
> involves the 'struct RXGK_Token' encrypted with the cell-wide key
> (assuming we're dealing with a cell-wide key server). And we also need
> our K0, the session key. And of course, the client knows its K0 as it
> derived it during negotiation.
> 
> When the fileserver acts as an rxgk client here, the 'per-cell key'

Except the cache manager isn't a cell, and its clients don't have the
same sorts of identities that an AFS cell's clients have.  So the format
of its tokens is opaque, like those of any other rxgk service, does not
need to be standardized, and likely does not look like the tokens that
rxgk-afs uses.  Thus, the notion of "per-cell key" doesn't apply -- it's
just the CM's key, period.



> It doesn't even seem like the server needs the whole RXGK_Token (it just
> needs K0 and the enctype in order to encrypt the RXGK_Response
> authenticator, right?). But I see no problem with doing that.

The server needs the whole token because it must be able to provide it
in a response to an rxgk challenge.  I suppose the cache manager could
just remember what keys it has issued to each fileserver and look up the
right key based on the source of an incoming RPC.  But that would be a
terribly layering violation and wouldn't work well with multi-homed
servers.

-- Jeff