On Mon, 4 Feb 2013 18:42:07 -0500 (EST) Benjamin Kaduk <[email protected]> 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 [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
