RX Kerberos 5 security class requirements of Kerberos library

[Sam Hartman]

>>>>> "Marcus" == Marcus Watts <mdw at umich.edu> writes:

    Marcus> 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.

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

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

I have no problem with using AFS as an application to motivate
requirements for K5.  But there needs to be an actual requirements
discussion.


What there has been and what I'm objecting to is an assertion that
Kerberos has new requirements because AFS does thing a certain way.

What would be great would be a discussion of potential new
requirements motivated both by AFS and other applications.

And I strongly believe that going through an additional level of
abstraction and making the requirements one step removed from AFS will
help us get there.  So I'm asking us to do that on this list.

--Sam