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

[Russ Allbery]

Benjamin Kaduk <kaduk@MIT.EDU> writes:

> Jeff has described the current situation with regard to callbacks and
> information leakage and denial of service possibility.  Given that even
> with rxgk and a secure callback channel, we still have the problem of rx
> aborts being unauthenticated, I'm looking at a difference between rxgk
> now and rxgk later with secure callbacks.  Rxgk now gives me secure data
> transfer and authentication, but leaves me vulnerable to denial of
> service both at a per-RPC level and a refetching data level, as well as
> the information leakage about fids and such in use.  Rxgk later also
> gives me secure data transfer and authentication, and leaves me
> vulnerable to per-RPC denial of service attacks, but closes the data
> leakage channel and closes the denial of service attack that makes me
> refetch lots of data.

> To me, in the environment I work in, network is cheap, and I don't
> really care about this class of information leakage; I'd rather have the
> stronger crypto for authentication and data transfer sooner.  I'm
> interested in hearing why and how the tradeoff leans otherwise in
> different environments.

Whenever I hear anyone talk about a security framework when using the
phrase "I don't care about this class of information leakage," I feel like
they're waving a giant red flag.  The whole point of rxgk is to modernize
and fix the AFS security model, and callbacks are a key component of the
AFS protocol.  Leaving them unprotected feels to me like a substantial gap
in work that has been in scope for rxgk for as long as I've heard it
discussed.

I'm also quite uncomfortable with the idea of just omitting a part of the
protocol from the security design.  That is exactly the sort of design
decision that tends to result in unexpected negative security implications
later.  Giving attackers unprotected channels into the protocol should
always be scary.  Attackers are often quite a bit more creative than
protocol designers.  I realize this is a problem with rx aborts
regardless, but callbacks carry more substantial data.

I don't have a concrete attack that I can point at beyond what Jeff
already mentioned, but dropping this work is something that I think has a
bad architectural smell.

> I'm happy to make securing the callback channel be the next thing done
> after rxgk; I think it would give us secure callbacks at about the same
> time as blocking rxgk on secure callbacks, but we would get rxgk
> sooner.

I don't think this sort of timing in the protocol work is going to have
much, if any, real-world effect on the timing of availability of
deployable software.  The callback security work has to happen anyway and
you even agree that it's next; what specifically is being gained from
publishing rxgk without it?

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>