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

[Jeffrey Hutzelman]

On Sat, 2013-03-02 at 08:47 +0000, Simon Wilkinson wrote:
> On 2 Mar 2013, at 03:15, Benjamin Kaduk wrote:
> 
> > 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.
> 
> On the contrary, as someone who has actually implemented this, you
> absolutely will need changes to rxgk to get secure callbacks to work.
> If you separate out secure callbacks from rxgk-afs, you will need to
> come back and constrain the behaviour of AFSCombineTokens (and the
> rxgk-afs combined token) at a later date. If you end up doing that once
> implementations of the old token format are in the wild, there will be
> a major interoperability headache.

Um.  I don't see AFSCombineTokens being involved in callback behavior
_at all_.  That's for producing tokens the CM uses to talk to a
fileserver.  In the reverse direction, we simply have the CM _print_ a
token and hand it to the fileserver.  There should be no need for
combine-tokens, either generic or AFS-specific, to be involved in this
operation at all.


> > Jeff has described the current situation with regard to callbacks and
> information leakage and denial of service possibility.  Given that even
> with rxgk and a secure callback channel, we still have the problem of
> rx aborts being unauthenticated,
> 
> I think you're misrepresenting the RX abort problem. RX aborts aren't a
> particular denial of service risk

Oh, no; they're far worse than that.  Since aborts are unauthenticated
one cannot rely upon them to be legitimate.  That means you can't rely
on RXGEN_OPCODE as a signal to downgrade to an older RPC if there's any
advantage to an attacker in forcing you to do so.  It means that Ubik's
voting protocol, which represents a "yes" vote as an abort with a
positive abort code indicating the duration the vote is valid, is
completely insecure.  IIRC there's another place where we rely on a
similar trick.  And, of course, there are plenty of opportunities for
the cache manager or individual applications to rely on error codes from
fileserver operations.

Callback protection doesn't defend us from either of these.  Neither
does rxgk.  In fact, neither of those components _can_, because the
problem lies in the Rx transport layer, below the RCP abstraction
(indeed, below the call channel abstraction) but above the
security-class abstraction.

So, should we hold up standardization, development, and deployment of
rxgk while we step back and redesign parts of Rx's transport layer to
authenticate aborts?  I don't think so.


> I'm quite happy to contribute language that describes what YFS is doing
> now for callback protection, but I will note (as mentioned above) that
> it does require changes outside of just the SetCallbackKey RPC. So, if
> we are to consider it, it needs to be considered as part of the main
> rxgk-afs document.

Why don't you start by just telling us what you're doing, in broad
terms?  Some people feel differently, but personally, I don't think an
I-D or a formal specification is required to get an idea across for
discussion.  If you do that, start a new thread, please?


-- Jeff