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

[Russ Allbery]

Sorry for being far, far too terse and abrupt in my original message.

Benjamin Kaduk <kaduk@MIT.EDU> writes:
> On Fri, 1 Mar 2013, Russ Allbery wrote:

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

That's a good point.

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

That's the way that I've been thinking about it.  We know that the
existing security model for AFS has numerous serious flaws, so the fact
that it currently isn't doing something isn't, to me, a strong argument
against that protection being necessary.

However, I see that jhutz considers it reasonably separable, and it's
possible that I am thinking about it in the wrong way.  I'm certainly far
from an AFS security expert.  I'm just leery of protocols that mix
protected and unprotected channels; I think it's a red flag for possible
leaks and exploitable flaws in the security model.  But that is a
theoretical concern, not a specific analysis of AFS.

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

Ah!  I see now the problem that you're trying to solve.

What I am specifically concerned about is viewing rxgk as a deployable
security system meeting its design goals without having protected
callbacks.  I think rxgk without protected callbacks is certainly an
*improvement* over the current rxkad situation, but I don't think it has
the properties of the thing that we've been calling "rxgk" for years, and
I wouldn't want people deploying it under that belief.

However, I suppose that doesn't inherently mean that protected callbacks
necessarily have to be in the same *document*, and I can understand the
goal of declaring consensus on a portion of the work so that we can move
on to the implementation discussion for that portion of the work.

The primary concern that I'd have with moving piecemeal from a document
standpoint is if, once we did move on to callback protection, we
discovered that there was something missing from rxgk that turned out to
be required for callback protection and we had to re-open the rxgk spec to
resolve that issue.  That would obviously be unfortunate and potentially
cause interoperability problems for anyone with partially-deployed rxgk.
But I'm not at all in a good position to judge the risk of that, and my
impression of jhutz's message is that he believes that risk is quite low.

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