On Fri, 1 Mar 2013, Russ Allbery wrote:
Benjamin Kaduk <[email protected]> writes:
On Fri, 1 Mar 2013, Russ Allbery wrote:
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.
[...]
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.
That's the main motivation for wanting a separate document, yes. It feels
like all of both documents is pretty much done, except for the callback
question (and there are some details to work out over
VL_RegisterAddrsAndKey but I don't think there's anything fundamentally
hard there).
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.
The draft-wilkinson-afs3-rxgk document describes rxgk as having two
components: a negotiation service, and the actual operation of the
security class. In that document, the negotiation service must be used
out of band before the security class can be used. I think that the
security class itself -- the challenge/response, and packet handling --
are well-understood and very unlikely to change substantially.
The problem with securing extended callbacks is that the cache manager
acts as the rx server, but it would be absurd to require the fileserver to
perform a gss negotiation against the cache manager before a callback can
be made. As such, we must replace the negotiation portion of the "rxgk
spec" with some other mechanism for creating a shared key between cache
manager and fileserver, and token to be used for the rxgk security class.
The SetCallBackKey RPC is intended to perform this function; as jhutz
notes, it could also be used with other security classes, though they do
not have exactly the same problem as rxgk with respect to the negotiation
service.
This does seem like a fundamentally different thing than what's described
in draft-wilkinson-afs3-rxgk; it seems like draft-wilkinson-afs3-rxgk-afs
is intended to be how to apply the former to AFS (though we surely have
some wiggle room). As such, I am still okay with leaving the callback
channel to a different document, as stock rxgk with GSS negotiation
service is not really applicable to the callback channel. (This is why I
left the upper quoted chunk.)
I agree with jhutz that the risk of needing changes to rxgk in order to
get secure callbacks is quite low, as we only need a token and shared key
for the rxgk security class to work. Given a secure channel between cache
manager and fileserver in the form of CM-initiated rxgk connections, I
have high confidence that this can be done.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
