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

[Simon Wilkinson]

On 2 Mar 2013, at 19:34, Benjamin Kaduk <kaduk@MIT.EDU> wrote:

> On Sat, 2 Mar 2013, Simon Wilkinson wrote:
>=20
>> On 2 Mar 2013, at 18:30, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>>=20
>>> I'm in a similar position as jhutz; I think I understand what the callba=
ck protection mechanism should look like, and it doesn't involve protocol le=
vel changes outside of SetCallBackKey.
>>=20
>> When a server receives a SetCallbackKey RPC, which set of callbacks does t=
hat RPC apply to?
>=20
> The flip answer is of course "those from the same client" [over connection=
s using the indicated security index].

I'm mobile at the moment, which makes sending detailed answers tricky.=20

Sadly just saying "from the same client"  is insufficient, as is your later s=
uggestion of just using UUIDs.

The crux of the problem is that there isn't necessarily any trust relationsh=
ip between the fileserver and the cache manager. Even if a trust relationshi=
p exists (via a KDC, say) there's no binding between the client's GSSAPI ide=
ntity and its UUID.

We need to create a mechanism which allows a combined token to authenticate s=
uch 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 col=
lect any of the contents of callbacks, to forge callbacks, or to cause a sta=
te change that causes the client to silently lose all callbacks.

As I have already noted, the text in the document doesn't represent my curre=
nt thinking on SetCallbackKey. I'm pretty sure that the the reply I sent to A=
ndrew'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.=