[AFS3-std] rxgk-afs: moving SetCallBackKey to a separate document?
Thomas Keiser
tkeiser@gmail.com
Fri, 1 Mar 2013 21:38:50 -0500
--f46d04426eda2558d704d6e8060c
Content-Type: text/plain; charset=ISO-8859-1
On Mar 1, 2013 8:51 PM, "Jeffrey Hutzelman" <jhutz@cmu.edu> wrote:
>
> 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
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
> AFS3-standardization@openafs.org
> http://lists.openafs.org/mailman/listinfo/afs3-standardization
--f46d04426eda2558d704d6e8060c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Mar 1, 2013 8:51 PM, "Jeffrey Hutzelman" <<a href=3D"mailto=
:jhutz@cmu.edu">jhutz@cmu.edu</a>> wrote:<br>
><br>
> On Fri, 2013-03-01 at 13:13 -0800, Russ Allbery wrote:<br>
> > Benjamin Kaduk <<a href=3D"mailto:kaduk@MIT.EDU">kaduk@MIT.EDU=
</a>> writes:<br>
> > > On Fri, 1 Mar 2013, Jeffrey Altman wrote:<br>
> ><br>
> > >> Extended callbacks cannot be fully implemented until the=
re are<br>
> > >> protected callback channels. =A0That does not mean there=
are not benefits<br>
> > >> to protecting the callback channels in a world without e=
xtended<br>
> > >> callbacks.<br>
> ><br>
> > > I believe the question at hand is whether those benefits are=
sufficient<br>
> > > to delay standardizing rxgk. =A0Do you have an opinion on th=
is question?<br>
> ><br>
> > Personally, I think an rxgk standard that didn't protect the =
callback<br>
> > channel would be absurd.<br>
><br>
><br>
> I don't. =A0rxgk is a new security class, period. =A0The rxgk-afs =
document<br>
> provides additional details you _need_ to use rxgk with AFS. =A0You do=
n't</p>
<p dir=3D"ltr">Hi Jeff,</p>
<p dir=3D"ltr">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.=
=A0 If we're now falling back on the rxk5 methodology (out of the inter=
ests of time), then fine.=A0 However, I think such a decision needs to be e=
xplicit and well considered.</p>
<p dir=3D"ltr">Personally, I don't agree with the premise that the rxka=
d-afs bindings are necessary and sufficient.=A0 We have well over twenty ye=
ars of new literature and operational experience with which to refine our p=
osition.=A0 I have never been satisfied with the argument that securing the=
callback channel is only needed by XCB: that a rogue client can drasticall=
y impact the liveness of the distributed system with a few carefully crafte=
d datagrams is, imho, wholly unacceptable.=A0 My big concern is that separa=
bility of the specifications effectively makes callback channel security an=
OPTIONAL component of the protocol, which does not feel right to me...</p>
<p dir=3D"ltr">Regards,</p>
<p dir=3D"ltr">-Tom</p>
<p dir=3D"ltr">> _need_ callback protection to replace rxkad with rxgk i=
n AFS. =A0You do<br>
> sort of need it for parts of extended callbacks, but that doesn't =
mean<br>
> it needs to be married to rxgk. =A0In fact, there's no particular =
reason<br>
> why you can't do callback protection with rxkad. =A0The approach i=
s the<br>
> same -- the CM makes up a token and hands it to the fileserver, which<=
br>
> uses it to make authenticated callback RPCs.<br>
><br>
> It seems clear to me that callback protection is not nearly as<br>
> completely fleshed out as either rxgk or rxgk AFS integration. =A0I se=
e<br>
> nothing that makes rxgk depend on callback protection, or that justifi=
es<br>
> holding up rxgk until callback protection is done. =A0Therefore, I thi=
nk<br>
> it would be better to split the latter into a separate document.<br>
><br>
> -- Jeff<br>
><br>
><br>
> _______________________________________________<br>
> AFS3-standardization mailing list<br>
> <a href=3D"mailto:AFS3-standardization@openafs.org">AFS3-standardizati=
on@openafs.org</a><br>
> <a href=3D"http://lists.openafs.org/mailman/listinfo/afs3-standardizat=
ion">http://lists.openafs.org/mailman/listinfo/afs3-standardization</a></p>
--f46d04426eda2558d704d6e8060c--