[AFS3-std] Thoughts on SetCallBackKey and token format

Benjamin Kaduk kaduk@MIT.EDU
Mon, 3 Feb 2014 17:24:34 -0500 (EST)


I got a chance to return to the rxgk-afs document and consider the issues 
surrounding SetCallBackKey again over the weekend.  I've uploaded a new 
revision (http://tools.ietf.org/html/draft-wilkinson-afs3-rxgk-afs-04) 
with some changes that I think should resolve the main issues, but I'll 
summarize my thinking here.

Some main points that helped guide my thinking:
* tokens for database servers are conceptually different things than 
tokens for file servers
* AFSCombineTokens is the only supported way to get tokens for file 
servers
* In order to have secure callbacks work properly, we need to know which 
identity (if any!) from the user's token was the cache manager token.

To fulfill the last point, we could potentially use a separate field in 
file server tokens to store the CM identity (and ~require different data 
structures for dbserver and fileserver tokens), but my proposal keeps a 
single identities list and uniform token data structure, calling out the 
last identity in the list as the cache manager identity.  To account for 
the case when the token1 argument to AFSCombineTokens is empty, I create a 
new kind of PrAuthName (PRAUTHTYPE_EMPTY) to use as a placeholder.
Since extended callbacks require a CM identity, it's easy to check what's 
where.

-Ben