Question related to keytab entries upgrade

[Matthieu Hautreux]

2013/1/15 Roland C. Dowdeswell <elric at imrryr.org>

> On Mon, Jan 14, 2013 at 11:14:24PM -0600, Nico Williams wrote:
> >
>
> > Or just use the setkey RPC instead of randkey.  That's what
> > krb5_admin/krb5_admind do.
>
> It is also interesting to note that using setkey as I do is effectively
> almost identical to having an active kvno.  To see the similarity, consider
> how the KDC behaviour will change when you add a new key and do not update
> the active kvno:
>
>         TGS     no change.
>         AS      no change (except see below)
>         kadmin  no change (unless you allow clients to fetch keys)
>
> And hence, the process:
>
>         1.  add new inactive key to KDC (which then propagates to slaves),
>
>         2.  write key into keytab, and
>
>         3.  set new key to be active on KDC (which then propagates to
>             slaves).
>
> is currently identical to what krb5_admin{,d} do as step (1) does not
> introduce a functional change to KDC behaviour.
>

I do not exactly see how you manage to simulate the active logic with MIT
krb5 implementation. Is it possible or is this description only available
for heimdal KDC ?


> You could alter the AS to allow the new key to be used in AS-REQs
> but I haven't seen that change implemented.  I may have missed it.
> There is an issue with the krb5_admin{,d} behaviour which is that
> when krb5_keytab writes the new key into the keytab there is a
> window where kinit -k will fail.  This is a less serious problem
> that the service ticket race condition, however.  And I think that
> the appropriate solution to the problem would be to fix get_init_creds*
> to be able to use older keys in the keytab if later ones fail---I
> implement this [locally] in krb5_admin, actually, to avoid failing
> if the host keytab has corrupt or incorrect entries.
>

Thanks for that information, this is clearly an issue that I missed in my
thiking about that as I am also doing regular "kinit -k" on the server
nodes... bad news ! If I use the current logic, get the new keytab entries
from the KDC and then push them to the node, I get the initial race window,
If I generate the keytab on the management node, I need to synchronize the
push to the KDC and the server or I will get this one :(

I saw that there is a unit-test for setkey in the krb5 source code, so I am
thinking about just adding that logic in a local version of kadmin. It
would however require to generate properly key material on the client
side...

Well, I think I need to think about that a little bit more before choosing
the proper way for the targeted need. I could just move to cold-add instead
of hot-add of entries.

Thanks again. I may contact you again in a near future.

Regards,
Matthieu


> --
>     Roland Dowdeswell                      http://Imrryr.ORG/~elric/
>