KDC Hardware

Jeffrey Hutzelman jhutz at cmu.edu
Mon Jan 9 18:10:55 EST 2006



On Saturday, January 07, 2006 11:38:47 AM +0100 Turbo Fredriksson 
<turbo at bayour.com> wrote:

> Security? Nah, both need _extra ordinary security_ so it's easier to
> safegard ONE machine than two (* nr of slaves of course :).

On the contrary, depending on what you are using your LDAP directory for, 
it may not require any more security than any other application.  Even if 
this is not the case, traditional operational practice dictates extreme 
paranoia where KDC's are concerned, because of the massive impact of a 
compromise.

If your LDAP server is compromised, you reinstall the machine, restore the 
database from backups, and get on with life, just like for any other 
service.  Depending on what you store in the directory, it's possible the 
intruder obtained sensitive information, but that's also true of other 
services, such as a mail server.

Again, depending on what you store in the directory, it's possible that an 
intruder who gains the ability to modify the LDAP database has used that to 
gain access to other services.  Such things might be annoying to track down 
and fix, but they can be fixed.  Any changes the intruder made can be 
rolled back; any deleted data can be restored from backups, etc.


If a KDC is compromised, it becomes necessary to assume that the intruder 
has a complete copy of the Kerberos database, including the keys for every 
principal.  Recovering from such a compromise requires issuing new 
passwords to _every_ user and re-keying _every_ service -- and doing it in 
such a way that someone who knows the old keys does not discover the new 
ones.  Any service which has not been re-keyed is vulnerable to the 
attacker; since he knows the service's key, he can impersonate any user, 
EVEN IF THE KDC IS SHUT DOWN.  A similar problem applies in the reverse 
direction; an attacker can impersonate the KDC and any service to a user 
whose key he knows, EVEN IF THE REAL KDC IS SHUT DOWN.

This is such a massively bad situation that it is worth taking every effort 
to protect the Kerberos database from compromise.  Running other services 
on the same machine is simply not worth the potential pain.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA




More information about the Kerberos mailing list