I have made an update to the rxgk-afs integration document, but the
internet-draft submission tool is not letting me finish the submission,
at the moment. In particular, the update has the SetCallBackKey now
providing both a token and a key (and some other details for the
connection).
For now, I've put the rendered copy up at
http://web.mit.edu/kaduk/Public/draft-wilkinson-afs3-rxgk-afs-03.txt
On Mon, 4 Mar 2013, Simon Wilkinson wrote:
On 4 Mar 2013, at 17:27, Benjamin Kaduk wrote:
There are other approaches, but they involve you either having to store
a key for every user who is accessing the fileserver (rather than just
every CM), or having to store which FID was last accessed by which key
in order to determine how to encrypt the callback. Neither of these are
desirable from an implementation stand point. Using CM identities has
the big advantage that the volume of information being tracked by the
fileserver for each client isn't dramatically larger, or more complex,
than it is today.
I have mostly convinced myself that the server does need to associate a
key/token with the host entry for a given callback, and in particular the
callback list for a given fid could contain multiple entries for the same
host with different keys.
The scenario is: legitimate cache manager calls SetCallBackKey and then
acquires a callback for the fid, then an attacker spoofs the host/uuid to
call SetCallBackKey and (re-)acquire a callback for that fid. The
fileserver can either break the existing callback when the new
SetCallBackKey call is made, or store a list of keys for the host and
accept the new callback. Clearly, in the latter case, we need to have two
callback entries for the fid, one for the real host and one for the
attacker. The former case is less clear-cut, but having the key handy
might make breaking just those callbacks easier. The latter case might
limit the scope of damage an attacker could perform, though I'd need to
think about it more.
In any case, I am inclined to require that calls generating extended
callback promises must be performed using a combined token including the
cache manager identity, and only the cache manager identity (a
single-identity token) should be used for the SetCallBackKey. We may need
to adjust the AFSCombineTokens text slightly to enforce this; I think we
currently only say that cache managers with multiple users SHOULD provide
token1 as a CM token, but do not restrict other uses of token1. Requiring
that token1's identity be a single host-based name seems like a matter for
application policy, not a protocol-level constraint, so I did not add
any text of that nature.
A solution that required an exact match between the identities for
SetCallBackKey and XCB-generating calls (that is, one which requires a
combined token to be used for SetCallBackKey when combined tokens are in
use, so that there would be as many XCB connection keys as users on the
machine) should be functional, but seems to add a potentially large amount
of overhead for minimal (if any?) benefit.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
