On Mon, 4 Feb 2013, Jeffrey Hutzelman wrote:
On Fri, 2013-02-01 at 17:02 -0500, Benjamin Kaduk wrote:
The RXAFS_SetCallBackKey RPC MUST be called over an rxgk-secured
connection (when being used with rxgk), and one of its arguments is an
XDR-encoded token. There is also a token used to secure the rx connection
over which the RPC is made. Do we expect these tokens to always be the
same? (The phrase "protected with a different cache manager identity" is
used, which is a little ambiguous which token's identity would be
relevant.)
No; in fact, they are expected never to be the same.
This RPC allows a cache manager to give the fileserver a token to be
used when authenticating callback RPCs made by the fileserver to that
cache manager. This allows callbacks to be authenticated.
Since the callback token is used in the reverse direction, from rxgk's
point of view, the fileserver will be acting as client and the CM as
server. So, it can't be the same token, ever.
Ah, it's an RXGK_Token, not an RXGK_TokenContainer, so the K0 is still
available.
The expectation is that the CM will construct a callback token,
protected by a service key that only it knows. Since it only needs to
be usable for the life of the CM, it can be generated at startup and
kept in memory. Of course, a CM should issue new callback tokens from
time to time, as the old ones expire.
Okay.
This does not seem to resolve the question of which identity is to be
used, though. It almost seems like we should consider the token passed as
mech_data to be a printed token with empty identity (and thus use the
token securing the rx connection over which the RPC is made for the
identity comparison). We probably want more text about what goes in this
RXGK_Token, regardless.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
