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

[Andrew Deason]

On Tue, 12 Feb 2013 20:04:37 -0500
Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

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

To be clear, I meant it's analagous to the per-cell key in the normal
"client as an rxgk client" interaction. I didn't mean it's actually
shared in the cell; it is private to the CM. You may already know that;
just making sure we're on the same page.

Okay, but what is the 'token' that the fileserver uses to initialize the
callback connection? The given definition for SetCallBackKey just says
we provide an RXGK_Token. That is not opaque, since the fileserver needs
to extract the K0 to encrypt the authenticator for an RXGK_Response. We
cannot provide the plain RXGK_Token in the RXGK_Response 'token', since
it's transmitted in the clear, right? And it contains K0.

So, according to the description above, it still seems like there are
two pieces of information that need to be transmitted: the key (K0), and
a token opaque to the fileserver. Right now we don't seem to have that.

This kind of thing is why it sounds like the callback channel is a
separate rxgk-using service to me (with its own tokens), which is not
required for rxgk use pre-XCB. Which is why I have been suggesting it
could really be a separate draft, and we wouldn't have to worry about it
for now to get basic rxgk functionality through.

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

Well, how are we "currently" supposed to know what key to use for the
incoming callback connection? We can't transmit K0 in the plain token of
the response, so it seems like the opaque token we give to the
fileserver could/should be encrypted with a key known only to the CM.
So, when the callback connection comes in, we decrypt the token, find
inside either the fileserver UUID or K0 itself, and use that key to
check the authenticator. That's the "analagous per-cell key" I was
talking about; it serves the same role as the per-cell key for
non-callback-channel AFS connections.

-- 
Andrew Deason
adeason@sinenomine.net