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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
