need project review
Henry B. Hotz
hotz at jpl.nasa.gov
Mon Apr 7 18:59:56 EDT 2008
On Apr 7, 2008, at 12:01 PM, krbdev-request at mit.edu wrote:
> Date: Mon, 7 Apr 2008 13:48:55 -0500
> From: Will Fiveash <William.Fiveash at sun.com>
> Subject: Re: need project review
> To: MIT Kerberos Dev List <krbdev at mit.edu>
> Message-ID: <20080407184855.GB6624 at sun.com>
> Content-Type: text/plain; charset=us-ascii
> On Fri, Apr 04, 2008 at 03:18:57PM -0500, Nicolas Williams wrote:
>> On Fri, Apr 04, 2008 at 03:00:41PM -0500, Nicolas Williams wrote:
>>> IMO we should deprecate stash files altogether. That should make
>>> issue go away -- what's the point of having a stash file if
>>> nothing will
>>> read it?
>> I should clarify. I think that the only thing that reads stash files
>> should be the tool that migrates them to keytab file entries. That
>> could be built-in to krb5kdc and kadmind, or it could be a standalone
>> tool. Either way the stash file should be read once, migrated, and
>> removed or ignored thereafter.
> The design does not auto-migrate the stash file to a keytab format.
> idea is that the KDC daemons will be able to read an older format
> file. Only when the admin runs a kdb5_util command that modifies the
> masterkey stash will the format change (along with a new masterkey
> stored). I'm assuming that the old masterkey does not need to be
> since this does not happen with the current stash code.
> Will Fiveash
> Sun Microsystems Office x64079/512-401-1079
> Austin, TX, 78727 (TZ=CST6CDT), USA
My presumption (based on experience with Heimdal, so take it with a
grain of salt) is that the newly-created keytab file would contain
both the old and the new keys. Database entries include a master key
kvno to indicate which key version from the keytab to use. The KDC
can run with a database which contains entries with a mix of master
I thought I saw some mention of master key kvno per entry which
implied the above.
The above is nice flexibility, but it doesn't help as much as you'd
like, if you need to recode the database to eliminate use of an old
master key. Even if you didn't shut down during the recode, the KDC
wouldn't be responding as fast as normal.
You have two design possibilities:
1) keep old key around in the new keytab file and make the KDC handle
multiple master keys.
2) When you write a new master key, you recode the entire database.
This could be a very big operation, so you may want to just shut down
the KDC for the duration. In turn this means you are depending on
client failover to other KDC's to maintain service availability.
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
More information about the krbdev