On Sat, 2 Mar 2013, Simon Wilkinson wrote:
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.
Clearly there is a lot of discussion left to be had about securing
callbacks. Are we at least confident that changes needed to secure
callbacks would be limited to the rxgk-afs integration document and that
the rxgk document will not need changes? You mentioned changes to
AFSCombineTokens, at least.
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 don't think anyone believes the current text of the document is fully
correct. I did get some useful pieces from your reply to Andrew's
comments when I was doing historical research; I suppose it's worth
reviewing that mail again.
I'll try to go into more detail on Monday.
Thanks.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
