On Fri, 2013-03-01 at 13:13 -0800, Russ Allbery wrote: > Benjamin Kaduk <[email protected]> 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 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
