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

[Jeffrey Hutzelman]

On Fri, 2013-03-01 at 13:13 -0800, Russ Allbery wrote:
> Benjamin Kaduk <kaduk@MIT.EDU> writes:
> > On Fri, 1 Mar 2013, Jeffrey Altman wrote:
> 
> >> Extended callbacks cannot be fully implemented until there are
> >> protected callback channels.  That does not mean there are not benefits
> >> to protecting the callback channels in a world without extended
> >> callbacks.
> 
> > I believe the question at hand is whether those benefits are sufficient
> > to delay standardizing rxgk.  Do you have an opinion on this question?
> 
> Personally, I think an rxgk standard that didn't protect the callback
> channel would be absurd.


I don't.  rxgk is a new security class, period.  The rxgk-afs document
provides additional details you _need_ to use rxgk with AFS.  You don't
_need_ callback protection to replace rxkad with rxgk in AFS.  You do
sort of need it for parts of extended callbacks, but that doesn't mean
it needs to be married to rxgk.  In fact, there's no particular reason
why you can't do callback protection with rxkad.  The approach is the
same -- the CM makes up a token and hands it to the fileserver, which
uses it to make authenticated callback RPCs.

It seems clear to me that callback protection is not nearly as
completely fleshed out as either rxgk or rxgk AFS integration.  I see
nothing that makes rxgk depend on callback protection, or that justifies
holding up rxgk until callback protection is done.  Therefore, I think
it would be better to split the latter into a separate document.

-- Jeff