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

[Matt W. Benjamin]

Hi Ben,

If you just wanted RPC security sooner, you could have deployed rxk5 in 2007.
The point of waiting for rxgk was to get compelling features like a secure
callback channel.

It is my impression that the YFS implementation implements callback
channel security today.  I'm not sure quite when the community should make time
to get an -interoperable- secure callback channel, but, isn't it, arguably,
now?

Regards,

Matt

----- "Benjamin Kaduk" <kaduk@MIT.EDU> wrote:

> On Fri, 1 Mar 2013, 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.
> 
> While I am happy to hear an opinion expressed, merely saying that 
> something would be "absurd" does not really give me a technical
> argument 
> whose merits I can weigh and consider.  At best, I can weigh the
> position 
> against your personal reputation, which is admittedly quite strong.
> 
> 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.
> 
> 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 just don't see that rxgk itself has an inherent dependency on
> secure
> callbacks; in my mind, secure callbacks are a thing that use rxgk.
> 
> -Ben
> _______________________________________________
> AFS3-standardization mailing list
> AFS3-standardization@openafs.org
> http://lists.openafs.org/mailman/listinfo/afs3-standardization

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309