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

[Andrew Deason]

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' is
some CM-private key that's known only to the CM. The K0 is some key
generated by the CM and given to the fileserver, instead of it being
derived. So, in order for the fileserver to use a secured callbacks
channel, it needs to be told both K0, and it needs to encrypt a 'struct
RXGK_Token' with the CM private key (the analagous 'cell-wide key').
Since the fileserver doesn't know the CM's private key, the CM needs to
provide the encrypted RXGK_Token itself, so it needs to provide an
RXGK_TokenContainer.

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.

-- 
Andrew Deason
adeason@sinenomine.net