Re: Kerberos on .debian.org?

[Sam Hartman <hartmans@mit.edu>]

>>>>> "Brian" == Brian May <bam@debian.org> writes:

>>>>> "Jason" == Jason Gunthorpe <jgg@debian.org> writes:
    >>> This sounds like a good argument to me. However, the LDAP
    >>> database is just as vulnerable... Isn't it?

    Jason> You cannot reverse a hashed password into something you can
    Jason> feed over the network to gain access. You can do that to a
    Jason> stolen KDC database.

First, this is not strictly speaking true; see
draft-ietf-cat-kerberos-pk-init-12.  This draft is not implemented in
the MIT KDC or Heimdal at this point, so it's not really worth
considering.  The MIT codebase does actually have a master key
intended to make this sort of attack much more complicated.  You can
choose to encrypt the keys in the database in a master key.  That
master key can for example be stored only in the  process of the KDC
requiring  an attacker to extract it from the running core image of
the KDC.  This does require a human to vet the KDC whenever an
interruption/reboot happens and to  rekey it.  With sufficient
replicas this can be acceptable.

But frankly, most environments assume the risk is acceptable and let
the KDC keep its master key.  So, far this seems to be a reasonable
environment.  Institutional memory at MIT (10 years with reasonable
certainty) doesn't recall a KDC database compromise.  I can certainly
check with administrators at other large Kerberos installations.  The
Most of this comes from running the KDC as the only service on a
computer and having reasonable physical security for the KDC.  

This seems especially true of Debian, where you could force invalidate
passwords since they can easily be reset using GPG keys.  It seems
even more true if we are talking about providing Kerberos as an
option, rather than replacing shadow entries entirely.

What I'm seeing here is not obvious reasons why a proposal to set up a
debian.org Kerberos realm is untennible.  I'm seeing reasonable
technical concerns about using Kerberos at all, and some fairly grave
concerns about replacing the LDAP shadow entries with Kerberos in the
current environment.  It seems clear that a reasonable proposal would
have to be fairly well thought out and would require some complexity
to implement.  As such, people would have to be found who could do the
work--people already trusted by the project or who the project decided
it could trust.  The proposal would probably have to include an offer
of hardware for a KDC and secure space where such hardware could be
hosted.  The proposal would probably also need to justify that such a
Kerberos realm was useful to enough developers to justify increased
complexity.