Master key migration and the stash command

Will Fiveash William.Fiveash at Sun.COM
Wed Jan 28 16:50:36 EST 2009

On Wed, Jan 28, 2009 at 01:53:14PM -0500, Greg Hudson wrote:
> Currently, "kdb5_util stash" does the following:
>   1. Open the database (or fail out)
>   2. (If there is an existing stash file, read in the master key and
>      forget about it; this is odd but unimportant)
>   3. Prompt for the master key
>   4. Verify the entered key against the database (or fail out)
>   5. Write out the stash file
> There are two issues here.  First, you can't stash the password before
> creating the database, which complicates the setup of slave DBs.
> Second, part of the master key migration project plan requires a "sync
> the stash" operation to update the stash file with all master keys.
> (
> I was thinking of creating a "grand unified stash" command, which
> handles all of the use cases:
>   * If there's a database but no valid stash file, prompt for the
>     master password, use it to retrieve all master keys, and write out
>     a stash file containing all master keys.
>   * If there's a database and a valid stash file, use the stashed
>     master key to retrieve all DB master keys, and write out a stash
>     file containing all master keys.
>   * If there's no database and no stash file, prompt for the master
>     password and stash it without verifying it.
> Does this plan seem reasonable, or would people rather see separate
> kdb_util operations for "prompt and stash" and "update existing
> stash"?

A couple issues:

1. Will it completely overwrite the existing stash, thus destroying any
   keys in the stash not found in the master princ?  I'm okay with the
   answer being yes as the master princ better have all mkeys in use.

2. The kdb5_util create code may need to be modified to read the stash
   when it creates the KDB entries.

BTW, when I look at the current code in krb5_def_store_mkey() I think
that it is a shortcoming that the code does not preserve the existing
stash keys in the new keytab (my bad).  Sounds like your mods above will
take care of this in a reasonable way (see item 1).

Will Fiveash
Sun Microsystems Inc.

More information about the krbdev mailing list