[AFS3-std] draft-wilkinson-afs3-rxgk-afs-01 comments

Simon Wilkinson simon@sxw.org.uk
Mon, 4 Mar 2013 19:52:22 +0000


On 4 Mar 2013, at 17:27, Benjamin Kaduk wrote:
>=20
> My rough-sketch solution involved recording the CM uuid as well as the =
client identity (and key, of course) used to authenticate the =
SetCallBackKey RPC.

Whatever you do, implementation wise, you probably still need the UUID. =
The issue is that you can't rely upon the UUID as a secure
identifier - given a number of different tokens all calling =
SetCallbackKey for the same UUID, there's no way of telling which one is =
the one that's actually allowed to set the key for that UUID. So, you =
need to be careful to avoid both denial of service, and information =
leakage.

The easiest way of doing this is to use the CM identity that's held =
within the forward RPC's authentication token to identify the key to use =
for the callback leg. This means that you have to be able to identify =
which one of the identities within the combined token is that of the =
host. That, in turn, is the reason why you need to think about this in =
conjunction with AFSCombineTokens.

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.

Also, in a world with unkeyed cache managers, requiring that =
SetCallbackKey be called by a combined token with both user and cache =
manager parts, makes it much harder for an attacker to anonymously =
register a large number of bogus keys for a particular UUID, as the user =
portion can be logged, and traced. Again, doing this requires that we =
can identify which part of a combined identity belongs to the host.

Hopefully that makes the reasons why all of this is entwined together =
somewhat clearer.

It seems like my plane has finally turned up, so I'll have to stop here. =
If I get a chance tomorrow, I can fill in more details
.
Cheers,

Simon