Sorry for being far, far too terse and abrupt in my original message. Benjamin Kaduk <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
