[AFS3-std] rxgk-afs: moving SetCallBackKey to a separate document?

[Benjamin Kaduk]

On Sat, 2 Mar 2013, Simon Wilkinson wrote:

> On 2 Mar 2013, at 19:34, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
>> On Sat, 2 Mar 2013, Simon Wilkinson wrote:
>>
>>> On 2 Mar 2013, at 18:30, Benjamin Kaduk <kaduk@MIT.EDU> 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