[AFS3-std] rxgk-afs: moving SetCallBackKey to a separate document?
Thomas Keiser
tkeiser@gmail.com
Fri, 1 Mar 2013 19:38:42 -0500
--bcaec554025a8bf05304d6e658be
Content-Type: text/plain; charset=ISO-8859-1
On Mar 1, 2013 6:47 PM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
>
> Thanks for these comments, they are very helpful.
> (more inline)
>
>
> On Fri, 1 Mar 2013, Russ Allbery wrote:
>
>> Benjamin Kaduk <kaduk@MIT.EDU> writes:
>>
>>> 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.
>>
>>
>>> To me, in the environment I work in, network is cheap, and I don't
>>> really care about this class of information leakage; I'd rather have the
>>> stronger crypto for authentication and data transfer sooner. I'm
>>> interested in hearing why and how the tradeoff leans otherwise in
>>> different environments.
>>
>>
>> Whenever I hear anyone talk about a security framework when using the
>> phrase "I don't care about this class of information leakage," I feel
like
>> they're waving a giant red flag. The whole point of rxgk is to modernize
>> and fix the AFS security model, and callbacks are a key component of the
>> AFS protocol. Leaving them unprotected feels to me like a substantial
gap
>> in work that has been in scope for rxgk for as long as I've heard it
>> discussed.
>
>
> I was trying to say that in the environment I currently work in, these
concerns are subsidiary to other concerns. I realize that other
environments will have different risk profiles, and was not trying to say
that we should discount the leakage entirely.
>
> That said, modernizing and fixing the AFS security model is a huge task,
and we're unlikely to get it perfect the first time around.
>
I tend to agree with Russ. Although we could potentially get to market
sooner with an afsint-only solution, this does not feel like an advisable
tradeoff. While I'm sympathetic to your argument that we are unlikely to
get this right the first time, I do think a document entitled rxgk-afs
should specify the binding semantics for at least afscbint and afsint.
>From my perspective, cache invalidation DoS attacks are potentially quite
dangerous: their amplification factor is conceivably enormous, and the
potential for causing outages is well understood. I would like to see the
callback channel protected in the initial draft, if at all feasible.
>
>> I'm also quite uncomfortable with the idea of just omitting a part of the
>> protocol from the security design. That is exactly the sort of design
>> decision that tends to result in unexpected negative security
implications
>> later. Giving attackers unprotected channels into the protocol should
>> always be scary. Attackers are often quite a bit more creative than
>> protocol designers. I realize this is a problem with rx aborts
>> regardless, but callbacks carry more substantial data.
>
>
> So you are arguing that we should consider AFS callbacks as a first-class
part of its use of the rx protocol when we are upgrading the security
class, even though they currently only use the null security class? I
don't have an obvious counter to that; it is good food for thought.
>
>
>> I don't have a concrete attack that I can point at beyond what Jeff
>> already mentioned, but dropping this work is something that I think has a
>> bad architectural smell.
>
>
> Sure, this is a good sort of input to get from experienced implementors.
>
>
>>> I'm happy to make securing the callback channel be the next thing done
>>> after rxgk; I think it would give us secure callbacks at about the same
>>> time as blocking rxgk on secure callbacks, but we would get rxgk
>>> sooner.
>>
>>
>> I don't think this sort of timing in the protocol work is going to have
>> much, if any, real-world effect on the timing of availability of
>> deployable software. The callback security work has to happen anyway and
>> you even agree that it's next; what specifically is being gained from
>> publishing rxgk without it?
>
>
> My understanding is that none of the code I currently have can go into
the openafs tree until there is a final standard. I think it would be
healthiest to get ongoing review and integration of rxgk code, having the
core framework pieces in the tree even before all of the integration work
is finished. (Maintaining a huge branch out of tree is a substantial
effort just on its own!) Integration of the core code would also make it
easier for integration work to proceed in parallel for the various
services; I believe that there are other people who have volunteered to
help with development once it becomes reasonable to do so. Such
collaboration could certainly be done out-of-tree, but that seems
suboptimal to me. Of course, I could be wrong that integrating the core
would make parallel development easier. As it is, I am reluctant to even
bring up broad architectural questions on openafs-devel without a spec in
hand.
>
Yes, it is unfortunate that longer development times lead to greater code
integration headaches. However, giving this argument significant weight is
difficult--because acceding to it can negatively impact our judicious
deliberation.
Cheers,
-Tom
--bcaec554025a8bf05304d6e658be
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On Mar 1, 2013 6:47 PM, "Benjamin Kaduk" <<a hr=
ef=3D"mailto:kaduk@mit.edu">kaduk@mit.edu</a>> wrote:<br>
><br>
> Thanks for these comments, they are very helpful.<br>
> (more inline)<br>
><br>
><br>
> On Fri, 1 Mar 2013, Russ Allbery wrote:<br>
><br>
>> Benjamin Kaduk <<a href=3D"mailto:kaduk@MIT.EDU">kaduk@MIT.EDU<=
/a>> writes:<br>
>><br>
>>> Jeff has described the current situation with regard to callba=
cks and<br>
>>> information leakage and denial of service possibility. =A0Give=
n that even<br>
>>> with rxgk and a secure callback channel, we still have the pro=
blem of rx<br>
>>> aborts being unauthenticated, I'm looking at a difference =
between rxgk<br>
>>> now and rxgk later with secure callbacks. =A0Rxgk now gives me=
secure data<br>
>>> transfer and authentication, but leaves me vulnerable to denia=
l of<br>
>>> service both at a per-RPC level and a refetching data level, a=
s well as<br>
>>> the information leakage about fids and such in use. =A0Rxgk la=
ter also<br>
>>> gives me secure data transfer and authentication, and leaves m=
e<br>
>>> vulnerable to per-RPC denial of service attacks, but closes th=
e data<br>
>>> leakage channel and closes the denial of service attack that m=
akes me<br>
>>> refetch lots of data.<br>
>><br>
>><br>
>>> To me, in the environment I work in, network is cheap, and I d=
on't<br>
>>> really care about this class of information leakage; I'd r=
ather have the<br>
>>> stronger crypto for authentication and data transfer sooner. =
=A0I'm<br>
>>> interested in hearing why and how the tradeoff leans otherwise=
in<br>
>>> different environments.<br>
>><br>
>><br>
>> Whenever I hear anyone talk about a security framework when using =
the<br>
>> phrase "I don't care about this class of information leak=
age," I feel like<br>
>> they're waving a giant red flag. =A0The whole point of rxgk is=
to modernize<br>
>> and fix the AFS security model, and callbacks are a key component =
of the<br>
>> AFS protocol. =A0Leaving them unprotected feels to me like a subst=
antial gap<br>
>> in work that has been in scope for rxgk for as long as I've he=
ard it<br>
>> discussed.<br>
><br>
><br>
> I was trying to say that in the environment I currently work in, these=
concerns are subsidiary to other concerns. =A0I realize that other environ=
ments will have different risk profiles, and was not trying to say that we =
should discount the leakage entirely.<br>
><br>
> That said, modernizing and fixing the AFS security model is a huge tas=
k, and we're unlikely to get it perfect the first time around.<br>
></p>
<p dir=3D"ltr">I tend to agree with Russ.=A0 Although we could potentially =
get to market sooner with an afsint-only solution, this does not feel like =
an advisable tradeoff.=A0 While I'm sympathetic to your argument that w=
e are unlikely to get this right the first time, I do think a document enti=
tled rxgk-afs should specify the binding semantics for at least afscbint an=
d afsint.</p>
<p dir=3D"ltr">From my perspective, cache invalidation DoS attacks are pote=
ntially quite dangerous: their amplification factor is conceivably enormous=
, and the potential for causing outages is well understood.=A0 I would like=
to see the callback channel protected in the initial draft, if at all feas=
ible.<br>
</p>
<p dir=3D"ltr">><br>
>> I'm also quite uncomfortable with the idea of just omitting a =
part of the<br>
>> protocol from the security design. =A0That is exactly the sort of =
design<br>
>> decision that tends to result in unexpected negative security impl=
ications<br>
>> later. =A0Giving attackers unprotected channels into the protocol =
should<br>
>> always be scary. =A0Attackers are often quite a bit more creative =
than<br>
>> protocol designers. =A0I realize this is a problem with rx aborts<=
br>
>> regardless, but callbacks carry more substantial data.<br>
><br>
><br>
> So you are arguing that we should consider AFS callbacks as a first-cl=
ass part of its use of the rx protocol when we are upgrading the security c=
lass, even though they currently only use the null security class? =A0I don=
't have an obvious counter to that; it is good food for thought.<br>
><br>
><br>
>> I don't have a concrete attack that I can point at beyond what=
Jeff<br>
>> already mentioned, but dropping this work is something that I thin=
k has a<br>
>> bad architectural smell.<br>
><br>
><br>
> Sure, this is a good sort of input to get from experienced implementor=
s.<br>
><br>
><br>
>>> I'm happy to make securing the callback channel be the nex=
t thing done<br>
>>> after rxgk; I think it would give us secure callbacks at about=
the same<br>
>>> time as blocking rxgk on secure callbacks, but we would get rx=
gk<br>
>>> sooner.<br>
>><br>
>><br>
>> I don't think this sort of timing in the protocol work is goin=
g to have<br>
>> much, if any, real-world effect on the timing of availability of<b=
r>
>> deployable software. =A0The callback security work has to happen a=
nyway and<br>
>> you even agree that it's next; what specifically is being gain=
ed from<br>
>> publishing rxgk without it?<br>
><br>
><br>
> My understanding is that none of the code I currently have can go into=
the openafs tree until there is a final standard. =A0I think it would be h=
ealthiest to get ongoing review and integration of rxgk code, having the co=
re framework pieces in the tree even before all of the integration work is =
finished. =A0(Maintaining a huge branch out of tree is a substantial effort=
just on its own!) =A0Integration of the core code would also make it easie=
r for integration work to proceed in parallel for the various services; I b=
elieve that there are other people who have volunteered to help with develo=
pment once it becomes reasonable to do so. =A0Such collaboration could cert=
ainly be done out-of-tree, but that seems suboptimal to me. =A0Of course, I=
could be wrong that integrating the core would make parallel development e=
asier. =A0As it is, I am reluctant to even bring up broad architectural que=
stions on openafs-devel without a spec in hand.<br>
></p>
<p dir=3D"ltr">Yes, it is unfortunate that longer development times lead to=
greater code integration headaches.=A0 However, giving this argument signi=
ficant weight is difficult--because acceding to it can negatively impact ou=
r=A0 judicious deliberation.</p>
<p dir=3D"ltr">Cheers,</p>
<p dir=3D"ltr">-Tom</p>
--bcaec554025a8bf05304d6e658be--