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

[Benjamin Kaduk]

On Fri, 1 Mar 2013, Russ Allbery wrote:

> Benjamin Kaduk <kaduk@MIT.EDU> 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