need project review

Will Fiveash William.Fiveash at
Mon Apr 7 20:50:09 EDT 2008

On Mon, Apr 07, 2008 at 05:32:58PM -0400, Jeffrey Hutzelman wrote:
> --On Monday, April 07, 2008 01:43:29 PM -0500 Will Fiveash 
> <William.Fiveash at> wrote:
>> On Fri, Apr 04, 2008 at 11:20:17AM -0400, Jeffrey Hutzelman wrote:
>>> --On Thursday, April 03, 2008 07:47:41 PM -0500 Will Fiveash
>>> <William.Fiveash at> wrote:
>>>> The KDC must be able to access the most recent master key in the
>>>> masterkey keytab given a principal name
>>> I'm afraid this doesn't make sense to me.  What does a principal name
>>> have  to do with retrieving the master key?  While a copy of the master
>>> key is by  convention stored in the KDB as the keys for a particular
>>> principal, and  the same convention might be followed here, the master
>>> key does not have a  "principal name".
>> As you point out currently the masterkey in the stash file is the same
>> as the key associated with the K/M principal.  Given krb5_kt_get_entry()
>> and krb5_kt_add_entry() will be used to access and modify the masterkey
>> keytab and require a principal argument, my thought is that the
>> krb5_db_def_fetch_mkey and krb5_def_store_mkey() will use the K/M
>> principal name as the argument to the krb5_kt*_entry() functions.
> That certainly makes sense as an implementation strategy, but I don't think 
> "given a principal name" makes any sense as part of a design constraint. 
> The actual requirement is "the KDC must be able to access the most recent 
> master key in the masterkey keytab<period>".

I see your point.  I'll modify the Functional Requirements to remove
mention of the principal.

>>> I think it is important that storing a new master key version be done
>>> safely, such that failure does not result in the old stash file being
>>> destroyed, even if it was old format.  Further, it might be argued that
>>> attempting to add a new master key to an old-format stash file should
>>> result in a keytab containing both the previous key and the newly-added
>>> one.
>> How about I modify the design to create a temp masterkey keytab and then
>> moving it to it's standard filename?
> I think this is slightly better than moving the old stash file aside first, 
> because it doesn't have any points where failure would leave us with no 
> stash file.  On the other hand, if the system crashes it's always possible 
> the filesystem will screw us, and if you're changing the key you want to 
> move the new database in "at the same time", which is impossible, so maybe 
> I'm worrying too much.

Well, a full filesystem error is a real concern so it's a good idea to
make sure the keytab is created properly before replacing the original
stash file.

> Mostly I was concerned that the old stash not be destroyed while it is 
> still needed, because it's possible the admin does _not_ know the key (he 
> doesn't know he needs to, or the password was forgotten by soemone who left 
> a few years ago), and losing your master key is bad.

True but given disks have been known to go bad you have to think the
admin is playing Russian roulette if they don't have a backup.

>>> IMHO there needs to be a tool to convert back to the old stash format.
>>> Managing a transition is much harder when you can't back out the change
>>> if  there is a problem.
>> Understand that I am not proposing that upgrading the KDC code will
>> automagically change the stash file format.
> No, but Nico was.  As long as you don't do automagic conversion, the 
> rollback tool is merely a nice-to-have, rather than essential.

That's cool, I just wanted to make sure people weren't confused about my

Will Fiveash
Sun Microsystems Inc.

More information about the krbdev mailing list