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

[Jeffrey Hutzelman]

On Fri, 2013-03-01 at 18:22 -0800, Russ Allbery wrote:

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

Oh, it's certainly a problem with AFS.  But rxgk is a solution to a
specific part of the overall problem.  It lives below a well-defined
mechanism abstraction, and the callback protection part of the problem
lives almost entirely above that abstraction.

The rxgk-afs document describes the bits that need to straddle the
abstraction boundary in AFS.  If we already had callback protection,
then the rxgk-specific bits (specifically, how rxgk credentials fit into
whatever mechanism the client uses to convey credentials to the
fileserver) could reasonably belong here.


However, we don't already have callback protection, which means we also
need to define how that works on the whole, how we negotiate the
feature, agree on a security class(*), and convey credentials, and so
on.  IMHO, those things belong in a separate document which focuses on
callback protection.  Such a document can also describe how to integrate
with rxgk and, if we wish, rxkad; I expect the mechanism-specific parts
to be quite small.

I might feel less strongly about this if callback protection were
actually done.  But it's not, and rxgk is, and rxgk-afs very nearly is.
I don't see an advantage to defining this new feature in the same
document which justifies either the complication of having multiple
mostly-unrelated things in one document or the delay in getting the rxgk
mechanism out the door.


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

I've been talking about rxgk for years, and I certainly haven't meant
that term to mean anything other than a new rx security class, a drop-in
replacement for rxkad, but with better features.  Note: it is not a
failing in either rxkad or rx itself that callback connections are not
authenticated.  They run over the same ports as the forward connections,
but they are _not the same connection_ and are not related.  We're not
talking about magic to protect "reverse traffic" on an Rx connection(+);
we're just talking about applying security to entirely independent
connections from fileserver to client that are currently not protected
at all.



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

I don't expect that to be an issue, and if it were, it would be far more
likely to affect rxgk proper, not the rxgk-afs document from which we're
talking about splitting out callback protection.  And, as you note, I
think the risk is quite low in any event.  I have a fairly complete
notion in my head of how CB protection could be done, and while it might
be a challenge to apply it to some kinds of authentication mechanisms
available today, it doesn't require anything special out of rxgk (or
rxkad) at the protocol level.

Also note that our process is designed to let us declare something
"done", go off and implement it, and then tweak it later if necessary.
There can be all sorts of problems with scaling this approach to a large
number of implementors, but the SSH community has done effectively the
same thing with reasonable success, and besides, we don't _have_ a large
number of implementors.

-- Jeff



(*) Whether or not we think we ever want to support CB protection over
rxkad, it certainly must support security class negotiation, so that we
have the option to replace rxgk with something else in the future.

(+) Note that during the rxtcp design process, we did talk about
piggybacking a "reverse" rx connection on the same TCP connection, at
least partly as an approach to the NAT problem.  However, even there,
the two connections would have been completely independent above the
transport layer; they would _not_ have shared security context.