RX Kerberos 5 security class requirements of Kerberos library
hartmans at MIT.EDU
Mon Jan 22 11:56:30 EST 2007
>>>>> "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> 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
>> 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
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.
More information about the krbdev