Current ideas on kerberos requirements for Samba4

[Jeffrey Hutzelman]

On Monday, May 23, 2005 11:18:00 AM -0400 Ken Hornstein 
<kenh at cmf.nrl.navy.mil> wrote:

>> My current feeling is that Samba may well ship it's own KDC (based
>> either on Heimdal, our own code or potentially some other codebase) for
>> some time into the future.  To whatever extent Samba includes a
>> derivative of another distribution of kerberos, the aim would be to keep
>> the 'diff' between the two projects as small as possible, while
>> integrating the code for minimum administrative and engineering pain.
>
> Just my $0.02:
>
> I already have a hacked KDC (based on MIT) that has a number of custom
> extensions that I need.  Running a Samba-supplied KDC is simply a
> non-starter.  I know plenty of people who are in the same boat.  Just
> as an aside - it seems when you do Kerberos for a while, you find that
> you need to do some number of changes to make it fit better at your
> site, so this sort of thing just tends to crop up.  This probably
> isn't an issue for smaller sites, or sites that just want to run a KDC
> to suppot Samba.
>
> If you provide a chunk of code and say, "You need to integrate this",
> then that's fine with me (if it's Heimdal-only, then that will be a
> pain, but I can deal).  I know, I could always do cross-realm ... but
> trust me, I have more experience with cross-realm than most people, and
> I'm not going to run a seperate realm just for Samba

"What he said".  Seriously, I have strong reservations about such an 
approach from three standpoints:


(1) From the point of view of a software engineer and protocol designer:

    Kerberos is not part of your (or any) application; it is a core
    infrastructure service which must be shared among many applications.

    Good design requires a certain amount of modularity, with separate
    tasks being performed by separate components communicating through
    well-defined interfaces.  This allows each component to be managed
    separately, and ensures that they will all interoperate.

    Including the KDC in Samba will likely result in the two becoming
    tightly coupled.  It will make it easier for smbd to violate all
    sorts of abstractions and to depend on private interfaces which make
    it fail to interoperate with standard KDC's.  If multiple applications
    had such a requirement, they would be unable to coexist in the same
    environment, because while a given Kerberos realm may support many
    applications, it can have only one set of KDC's.


(2) From the point of view of a Kerberos administrator:

    Like Ken, I run Kerberos and other infrastructure for a site with
    fairly complex requirements.  Like Ken, my KDC's run modified
    software with a number of local extensions (not the same ones).
    My KDC's are carefully managed and tightly secured.  They run on
    dedicated, locked-down machines in locked cabinets in locked rooms
    with video surveillance and direct-to-paper logging.  Both network
    and physical access to the machines is tightly controlled, and only
    about 5 people have the ability to log in to them.  The KDC software
    is based on a distribution signed by someone personally known to me,
    and most of the other code has been carefully analyzed as well.

    I'll admit that most sites probably aren't quite as paranoid as we
    are, and certainly most don't chat with their KDC vendor on a daily
    basis.  But a good number of people are that paranoid, or more, and
    even those who don't have custom KDC modifications are unlikely to
    want to run some application-specific KDC with unknown properties.

    As for Ken, that would be a total non-starter for me, due to both
    security and maintainability considerations.  I'm uninterested in
    incorporating into my KDC's a large pile of code which has nothing
    at all to do with Kerberos and serves only as a source of potential
    vulnerabilities.  I'm much more likely to run (or even port, if
    necessary) a small, easily-analyzed plugin which provides only those
    specialized Kerberos-related functions required by the application.


(3) From the point of view of someone who's faced similar issues before:

    The primary purpose of OpenAFS is to provide a scalable, cross-platform
    distributed filesystem.  Unfortunately, the OpenAFS distribution has
    traditionally included quite a number of tools which are not related
    to this purpose.  Among other things it includes an FTP server, inetd,
    login, an NTP server, rlogin/rsh, a software maintenance tool (package),
    and yes, an authentication service.

    All of these components are old, poorly maintained, and have been
    obsoleted newer, better software available elsewhere.  Some of them
    are downright dangerous, and building them requires the use of a
    special configure switch (--enable-insecure).  What's worse, most of
    these packages have _always_ been this way, since day one.  This
    stuff was in the Transarc distributions over a decade ago, and it
    was obsolete and insecure back then, too.

    We recently decided to remove nearly all of these independent packages
    from the OpenAFS tree, and concentrate more fully on our core purpose.
    Of the components I mentioned above, the only ones we haven't thrown
    away are package (which probably should be) and the kaserver, which
    we've kept around only because there are a few sites out there who
    still depend on it.  Note that anytime someone comes to us with a
    question of the form "we're running the kaserver and...", the answer
    is "don't do that; go get a real KDC".

    We want people to run a real KDC.  We've been in the business of
    supporting a KDC unique to our filesystem application, and we didn't
    like it one bit.  Just a friendly word of advice...


-- Jeff