Recreating Master Key

[Marcus Watts]

> Date: Mon,  3 Feb 2003 14:07:42 -0800
> To: kerberos at mit.edu
> Subject: Recreating Master Key
> 
> I found this in regard to the ability (or lack ther of) to recreate the master key:
> 
> http://mailman.mit.edu/pipermail/kerberos/2002-September/001827.html
> 
> What do you do when the angry Kerberos Admin leaves the company?  Can you Dump the DB, Recreateit with a new Master Key then Restore?
> 
> Thanks.

The master key does 2 things:
	encrypt the database proper
	most likely serves as secret used in random number entropy
In particular, the master key
	does *NOT* participate in any form of active on-the-wire authentication
		or authorization.
Hopefully you have a stash file with the master key, and weren't
relying on your old angry kerberos administrator to restart the
database by hand each time the machine crashed.  If you were,
your best resort is probably the court system.

For the database proper, that's only an issue if you actually do
"split" backups - ie, if you back up the master key stash file
*separately* from the kdb itself.  If you put both in the same place,
there's no reason to worry about the angry kerberos administrator, the
encryption of the database of the database is already trivially
undoable using the stash key.  However, if you wanted to encrypt under
a different master key, you could certainly dump and restore the
database, and use that to change the master key.  Looks like the
"-mkey_convert" option to dump can do just this.  At one point, there
was some issue that dump/restore didn't actually save *everything* -
hopefully that's fixed now.

For the random number entropy, yes, knowing the master key *might* make
it easier for an attacker to compromise the random number generation
There's certainly no reason the random number generation couldn't be
based on some other secret instead or as well.  It is already based on
some extra entropy (time of day at least) but that's not sufficient.
Perhaps this code has already been updated, although I can't find any
code right off that does better here.

If you're really worried about your kerberos administrator gone bad,
you should also consider doing something about krbtgt.   The option
"-keepold" on cpw will cause "cpw" to add a new key without deleting
old keys and kvnos.  There should also be a purge operation that you
could use to remove old keys after the max lifetime has gone by and no
valid tickets can be left for the old key.  Actually, changing the
krbtgt should is something you should be doing periodically anyways
(AFS kaserver does this automatically, but I'm not sure there's
anything in k5 to do the same.)

There are also various internal admin instances you should update like
krbtgt, and needless to say, you should update or purge any principals
or acls which your rogue kerberos administrator used or had access.
If you were truely paranoid, you might also consider making everybody
change their password.

					-Marcus Watts
					UM ITCS Umich Systems Group