Re: Should krbtgt be in a keytab, rather than hdb?

["Henry B. Hotz" <hotz@jpl.nasa.gov>]

On Dec 1, 2005, at 5:38 AM, Love Hörnquist Åstrand wrote:

> Andrew Bartlett <abartlet@samba.org> writes:
>
>> I'm working on Samba4's KDC, and it occurs to me that when the KDC is
>> receiving a TGS-REQ, it should be checking the incoming packet  
>> against a
>> keytab, rather than hdb.
>>
>> It seems that the receipt of the TGS-REQ is much more like an
>> application server than the issuing of tickets.
>>
>> In particular, I was thinking about the issue of key changes.  With a
>> keytab, both kvno and kvno-1 can be stored, allowing the krbtgt  
>> and more
>> importantly the inter-realm trust keys to be changed.
>
> Its true, but I think they should be stored in the database since  
> in the
> common case, the database is propagated to slavesl. I've been thinking
> about adding extra keys in the hdb extension thingy for the krbtgt's.

I'd like to put in a request for multiple key versions in the DB.

Independent of cross-realm you might want to rotate the single-des  
keys for your main krbtgt without invalidating all the tgt's that  
user's are holding at the time.  (We can do it for service keys, like  
afs, why not for tgt's?)  (Also need the appropriate management  
functions to delete old keys, which is where MIT falls down.)

>> I don't fully understand how inter-realm trusts work, but I think  
>> this
>> would also allow different keys in each direction, something that I
>> think Microsoft does.
>
> inter-realm already allow multiple keys, the name of the keys are
> krbtgtg/REALM1@REALM2 and krbtgtg/REALM2@REALM1, and they both (or  
> just one
Presume that was krbtgt/REALM1@REALM2 and krbtgt/REALM2@REALM1.
> of them if its not a transitive trust) are stored in the database  
> on both
> sides. So you can have diffrent keys in each direction.
>
> Love
>