On Mar 1, 2013 8:51 PM, "Jeffrey Hutzelman" <[email protected]> wrote: > > 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
Hi Jeff, There is an implicit premise underlying your argument: that the security assumptions of the rxkad-afs binding design are necessary and sufficient for deciding completeness of an rxgk-afs binding specification. If we're now falling back on the rxk5 methodology (out of the interests of time), then fine. However, I think such a decision needs to be explicit and well considered. Personally, I don't agree with the premise that the rxkad-afs bindings are necessary and sufficient. We have well over twenty years of new literature and operational experience with which to refine our position. I have never been satisfied with the argument that securing the callback channel is only needed by XCB: that a rogue client can drastically impact the liveness of the distributed system with a few carefully crafted datagrams is, imho, wholly unacceptable. My big concern is that separability of the specifications effectively makes callback channel security an OPTIONAL component of the protocol, which does not feel right to me... Regards, -Tom > _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
