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

[Jeffrey Hutzelman]

On Fri, 2013-03-01 at 18:11 -0500, Benjamin Kaduk wrote:

> 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'm looking at a difference between rxgk 
> now and rxgk later with secure callbacks.  Rxgk now gives me secure data 
> transfer and authentication, but leaves me vulnerable to denial of service 
> both at a per-RPC level and a refetching data level, as well as the 
> information leakage about fids and such in use.  Rxgk later also gives me 
> secure data transfer and authentication, and leaves me vulnerable to 
> per-RPC denial of service attacks, but closes the data leakage channel and 
> closes the denial of service attack that makes me refetch lots of data.

I prefer to look at things slightly differently.  Today, callbacks are
not protected at all, and forward RPCs are protected by a 20+ year old
security class based on single DES, pieces of krb4, and <shudder>
fcrypt.  With rxgk, callbacks will still not be protected at all, but at
least the forward direction will be modern.  That's important, and
something people have been waiting for for a very long time.

Protecting callbacks would be nice, but it is _orthogonal to rxgk_.  We
do not need rxgk for callback protection.  We do not need callback
protection for rxgk.  We don't need to do them at the same time, let
alone in the same document.  It is not necessary for every use of rxgk
even remotely related to AFS, now or in the future, to be defined in
this one document.  Rather, I see rxgk-afs's purpose being to specify
the details that _have_ to be nailed down in order for AFS to use rxgk
in place of rxkad.


Russ wrote:

> The whole point of rxgk is to modernize
> and fix the AFS security model

No, I don't think the point of rxgk is to solve all of AFS's security
woes.  Rather, its point is to replace a bad security mechanism with a
better one, behind an existing, perfectly adequate abstraction.  It is
certainly a _part_ of a project to improve AFS's security model, but it
is not synonymous with that project.

Note:  We're not discussing whether rxgk should protect part of the
connection or not.  We're talking about whether we should, in the same
document that describes the specific linkages between AFS and rxgk, also
talk about securing perfectly ordinary rx connections which currently
always use rxnull.  In other words, adding a new feature that AFS did
not have before and which is not rxgk-specific(*).

> what specifically is being gained from
> publishing rxgk without it?

Deployment of rxgk!
That is, instead of "encrypting" traffic in transit with fcrypt, barely
integrity-protecting it at all, and using the same key over and over and
over again on every packet with large chunks of the same plaintext, not
to mention numerous other sins, we can do something reasonable.

The incremental gain from replacing rxkad with rxgk is huge.
The incremental gain from adding callback protection is tiny.


Tom writes:

> Although we could potentially get to market
> sooner with an afsint-only solution, this does not feel like an
> advisable
> tradeoff.

First of all, we're not talking about an "afsint-only solution".  We're
talking about a _complete_ solution which replaces all current uses of
rxkad with rxgk, across the board, in every place where AFS uses a
secured connection.  In fact, it includes exactly as much support for
using rxgk on callback connections as there currently is for using rxkad
on such connections.

Secondly, I think you're wrong.  In particular, I think you are arguing
that extended callbacks and thus callback protection are so important
and valuable that getting something deployed which deprecates rxkad but
does not include those new features is less desirable than not getting
anything deployed at all.  There's a name for that fallacy: "letting the
perfect be the enemy of the good".

Getting rxkad replaced soon is extremely important.


Matt writes:

> If you just wanted RPC security sooner, you could have deployed rxk5
> in 2007.
> The point of waiting for rxgk was to get compelling features like a
> secure
> callback channel.

False.  rxk5 was never integrated, and by that I don't mean merely that
the code doesn't appear in the OpenAFS mainline, but that the sort of
integration work we're doing _right now_ to define how things are
supposed to interoperate and how a non-flag-day transition works were
never done.  For most sites, the notion that one has to upgrade every
server in the entire cell before beginning to do any testing to see if
the new code is desirable is a total non-starter.  There was also
nothing like standardization work or even a public development process;
I don't recall reading or being involved in any sort of design
discussion.

And no, since securing callbacks does not depend on rxgk, that was not
the reason for waiting.  Personally, my reason for not wanting to adopt
rxk5 in 2007, other than the ones I already mentioned, was that doing so
looked very likely to insure that rxgk would _never_ happen.  And in
fact, it was my opinion at the time that deploying rxk5 and never
getting rxgk out the door was in fact worse than deploying nothing.

The same argument does not apply here, because once rxgk is out the door
(or even without it(*)), callback protection can be added incrementally,
without throwing out any of the work already done, either in
standardization or in implementation.  Incremental development and
deployment is _good_; it keeps you from never getting anywhere because
you're always waiting for the next feature before doing anything.

-- Jeff



(*) Note -- I've been thinking about this lately, and it is quite clear
to me that callback protection need not and should not be specific to
rxgk.  It is possible to use a similar model with pretty much any rx
security class -- the CM makes an RPC to the fileserver telling it what
class to use and handing it credentials for that class.  The interface,
in fact, should look much like an RPC version of the same interface that
is needed in OpenAFS to pass credentials to the KTC, once you have more
than one security-class.