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

[Benjamin Kaduk]

Thanks for these comments, they are very helpful.
(more inline)

On Fri, 1 Mar 2013, Russ Allbery wrote:

> 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 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