need project review

[Henry B. Hotz]

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  
>>> this
>>> 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.   
> The
> idea is that the KDC daemons will be able to read an older format  
> stash
> file.  Only when the admin runs a kdb5_util command that modifies the
> masterkey stash will the format change (along with a new masterkey  
> being
> stored).  I'm assuming that the old masterkey does not need to be  
> saved
> 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  
key versions.

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