need project review

[Jeffrey Hutzelman]

--On Monday, April 07, 2008 01:43:29 PM -0500 Will Fiveash 
<William.Fiveash at sun.com> 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 sun.com> 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 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.

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.

>> 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.

-- Jeff