On 4 Mar 2013, at 17:27, Benjamin Kaduk wrote: > > 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 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
