<On Fri, 1 Mar 2013, Thomas Keiser wrote:
On Mar 1, 2013 6:47 PM, "Benjamin Kaduk" <[email protected]> wrote:
Thanks for these comments, they are very helpful.
(more inline)
On Fri, 1 Mar 2013, Russ Allbery wrote:
Benjamin Kaduk <[email protected]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
