RX Kerberos 5 security class requirements of Kerberos library

[Marcus Watts]

Sam Hartman <hartmans at MIT.EDU> replied:
> From: Sam Hartman <hartmans at MIT.EDU>
> To: jaltman at secure-endpoints.com
> Subject: Re: RX Kerberos 5 security class requirements of Kerberos library
> References: <200701030711.CAA13655 at quince.ifs.umich.edu>
> 	<459BB609.2030107 at secure-endpoints.com> <tsllkkkdx4v.fsf at cz.mit.edu>
> 	<459BBB85.5040701 at secure-endpoints.com>
> 	<20070103165607.GJ26175 at binky.Central.Sun.COM>
> 	<459BE145.6030701 at secure-endpoints.com>
> 	<20070103172330.GP26175 at binky.Central.Sun.COM>
> 	<20070121225437.GG26891 at narn.hozed.org>
> 	<45B3F106.5040001 at secure-endpoints.com>
> Date: Sun, 21 Jan 2007 18:05:38 -0500
> 
> >>>>> "Jeffrey" == Jeffrey Altman <jaltman at secure-endpoints.com> writes:
> 
>     Jeffrey> Troy Benjegerdes wrote:
>     >>>> This way the function can only be used for localauth and
>     >>>> cannot be used to specify an arbitrary client name to the
>     >>>> service whose key is in the service keytab.
>     >>> Sorry, I find this lame.  And I still have yet to hear what is
>     >>> so wrong with using OS facilities for local auth.
>     >>  Having a single code path for *ALL* authentication that goes
>     >> to a standard library makes security auditing much easier. If
>     >> we have to use kerberos for network and OS facilities for local
>     >> auth, now we have the network code path, and the local OS code
>     >> path which will be different on every OS.
>     >> 
>     >> Now, maybe we can just have the OS provide a nice kerberos wire
>     >> or API protocol compatible local auth facility, we might have
>     >> something everyone likes.
> 
>     Jeffrey> Troy:
> 
>     Jeffrey> It is important to realize that when we discussion
>     Jeffrey> localauth with regards to AFS we are not discussing
>     Jeffrey> single machine authentication.  Instead we are discussing
>     Jeffrey> local authentication within an AFS cell.  We are not
>     Jeffrey> discussing the use of local OS facilities.
> 
> That's certainly the AFS community's position.  I don't think they
> have made a compelling case for localauth beyond a single machine.
> 
> 
> But can we please get this level of afs-specificity off of krbdev?
> Refine things to proposed requirements; bring those forward; then
> design in terms of general requirements.

I don't like this "us and them" business.  There's too much overlap
between the K5 & afs communities for that to be true.  Also it
dismisses arguments on grounds of tribalism which is not productive.

AFS is an example of a service where the server component is
distributed between multiple machines.  It is possible, useful, and
attractive to use the same security component between server components
just as it is to use a single common security component between client
& server components.  Yes, it should be possible to discuss this as an
abstract choice a service might make; so far people have used that as
an excuse to revive security paradigms that were discarded as
inadequate 20 years ago.  The problem with keeping such arguments
entirely in the abstract is they can be all too easily construed to
point to conclusions that violate real-life constraints.  A better way
for us to get less AFS specific would be to start exploring some of
those other systems people had in mind when they said "ooh, I can use
that localauth function for my thing too".  If we find commonality in
those other systems, then we have valid grounds to label that
abstraction as "important"; if we find real differences that seem to
matter, then we have valid grounds to require flexibility to allow that
difference.  If we can't find any other such systems to discuss,
then maybe we've found grounds to validate tribalism here.

				-Marcus Watts