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

[Benjamin Kaduk]

<On Fri, 1 Mar 2013, Thomas Keiser wrote:

> On Mar 1, 2013 6:47 PM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
>>
>> Thanks for these comments, they are very helpful.
>> (more inline)
>>
>>
>> On Fri, 1 Mar 2013, Russ Allbery wrote:
>>
>>> Benjamin Kaduk <kaduk@MIT.EDU> writes:
>>>
>> That said, modernizing and fixing the AFS security model is a huge task,
> and we're unlikely to get it perfect the first time around.
>>
>
> I tend to agree with Russ.  Although we could potentially get to market
> sooner with an afsint-only solution, this does not feel like an advisable
> tradeoff.  While I'm sympathetic to your argument that we are unlikely to
> get this right the first time, I do think a document entitled rxgk-afs
> should specify the binding semantics for at least afscbint and afsint.

Per my previous mail, "binding semantics" for afscbint to use rxgk require 
completely replacing half of rxgk (the negotiation service), at which 
point it starts feeling less and less like actual binding semantics and 
more and more like a new, different, thing.

> From my perspective, cache invalidation DoS attacks are potentially quite
> dangerous: their amplification factor is conceivably enormous, and the
> potential for causing outages is well understood.  I would like to see the
> callback channel protected in the initial draft, if at all feasible.

There are surely environments where cache invalidation DoS attacks are 
quite dangerous, I agree.

I do not believe that callback channel protection is only possible with 
rxgk, though.  The SetCallBackKey RPC is structured as a security index 
and index-specific data to set a key for that mechanism.  Granted, the 
current text only describes the behavior for rxgk, but id need not be so. 
On a single-user machine/cache manager, it would be pretty straightforward 
to supply an rxkad token and key to be used for rxkad callback connections 
to that CM uuid/epoch+cid/whatever.  A multi-user machine is not quite as 
straightforward, but something better than rxnull could probably be worked 
out.  (This is jhutz's Note in his 21:46.)


I do not see a need to combine securing the callback channel in the same 
document as specifies the applications-specific portions of rxgk as 
specific to AFS; I think that securing the callback channel can stand on 
its own as a separate document.  We are still free to require both for an 
implementation to qualify as what has been bandied about as "rxgk" for the 
past N years.

-Ben