Thanks for these comments, they are very helpful.
(more inline)
On Fri, 1 Mar 2013, Russ Allbery wrote:
Benjamin Kaduk <[email protected]> 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 was trying to say that in the environment I currently work in, these
concerns are subsidiary to other concerns. I realize that other
environments will have different risk profiles, and was not trying to say
that we should discount the leakage entirely.
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'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.
So you are arguing that we should consider AFS callbacks as a first-class
part of its use of the rx protocol when we are upgrading the security
class, even though they currently only use the null security class? I
don't have an obvious counter to that; it is good food for thought.
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.
Sure, this is a good sort of input to get from experienced implementors.
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?
My understanding is that none of the code I currently have can go into the
openafs tree until there is a final standard. I think it would be
healthiest to get ongoing review and integration of rxgk code, having the
core framework pieces in the tree even before all of the integration work
is finished. (Maintaining a huge branch out of tree is a substantial
effort just on its own!) Integration of the core code would also make it
easier for integration work to proceed in parallel for the various
services; I believe that there are other people who have volunteered to
help with development once it becomes reasonable to do so. Such
collaboration could certainly be done out-of-tree, but that seems
suboptimal to me. Of course, I could be wrong that integrating the core
would make parallel development easier. As it is, I am reluctant to even
bring up broad architectural questions on openafs-devel without a spec in
hand.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
