On 2 Mar 2013, at 19:34, Benjamin Kaduk <[email protected]> wrote: > On Sat, 2 Mar 2013, Simon Wilkinson wrote: > >> On 2 Mar 2013, at 18:30, Benjamin Kaduk <[email protected]> wrote: >> >>> I'm in a similar position as jhutz; I think I understand what the callback >>> protection mechanism should look like, and it doesn't involve protocol >>> level changes outside of SetCallBackKey. >> >> When a server receives a SetCallbackKey RPC, which set of callbacks does >> that RPC apply to? > > The flip answer is of course "those from the same client" [over connections > using the indicated security index].
I'm mobile at the moment, which makes sending detailed answers tricky. Sadly just saying "from the same client" is insufficient, as is your later suggestion of just using UUIDs. The crux of the problem is that there isn't necessarily any trust relationship between the fileserver and the cache manager. Even if a trust relationship exists (via a KDC, say) there's no binding between the client's GSSAPI identity and its UUID. We need to create a mechanism which allows a combined token to authenticate such a cache manager to a fileserver, in a way that doesn't allow an attacker (which may include the user who is party to the combine tokens call) to collect any of the contents of callbacks, to forge callbacks, or to cause a state change that causes the client to silently lose all callbacks. As I have already noted, the text in the document doesn't represent my current thinking on SetCallbackKey. I'm pretty sure that the the reply I sent to Andrew's comments about it goes into much more detail than I can type here at present - it might be worth dragging that out of the archives. I'll try to go into more detail on Monday. S._______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
