Question related to keytab entries upgrade

[Roland C. Dowdeswell]

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.

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.

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