On Tue, 12 Feb 2013 20:04:37 -0500 Jeffrey Hutzelman <[email protected]> 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 [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
