Question related to keytab entries upgrade

[Roland C. Dowdeswell]

On Tue, Jan 15, 2013 at 11:40:25PM +0100, Matthieu Hautreux wrote:
>

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

I'm not simulating the active logic.  I am just noting that it doesn't
actually make a difference.  I'll explain with a few more words than
last time.  We have two processes:

PROCESS 1:

	a.  we are in the unmodified state,

	b.  we are in the unmodified state,

	c.  client writes new key into keytab, and

	d.  client tells KDC about the new key via setkey and the
	    KDC writes it into the KDB (which then propagates to slaves).

or

PROCESS 2:

	a.  we are in the unmodified state,

	b.  client and KDC negotiate new key and KDC writes in into the
	    KDC marking it as inactive,

	c.  client writes the key into the keytab, and

	d.  client tells the KDC that it has been written into its keytab
	    and the KDC marks it as being active (which then propagates
	    to slaves).

Now, if we think about it from a functional perspective, i.e. we think
about the behaviour of the KDC under both of these processes.  In 1.a
and 2.a, it is clear that the KDCs will behave identically.

In 1.b and 2.b, the KDC will respond in the same way to AS-REQs and
TGS-REQs.  Given that you can't read keys from the database via kadmin,
the kadmin service will also behave identically.

In 1.c and 2.c, the KDC behaviour changes in neither process but the
client behaviour changes in exactly the same way.

And in 1.d and 2.d, the KDC behaviour does change in both processes
but the change is again identical.

Given that the behaviour of both the client and server is the same
under both processes, we can say that even though the processes
appear to be very different under the covers, they have exactly
the same effect.  Process 2, however, involves twice as many writes
to the Kerberos database which with many database backends is a
limiting factor.  And so, it might be an idea to use process 1
instead.

What I do in krb5_admin{,d} is actually a little different than
process 1 or process 2, though.  I have the client and server use
ECDH to negotiate new keys, the client writes them into the keytab,
and then the client tells the KDC to write them into the KDB.  The
server, however, does not store intermediate state in the KDB as
it is useless if the client crashes in the middle of a transaction---so
I just keep it in memory.  No point in keeping state if it isn't
useful.

And to continue with the idea that state isn't useful, let us
examine what the intermediate state (the inactive key) in the
Kerberos DB gives us in process 2 if the client crashes between
2.b and 2.c.  Well, unless we relax the restriction that clients
can't read keys from the Kerberos DB (which I would argue is not
the correct decision), then the key written in 2.b is of no use to
the client when it tries to change the keys the next time.  This
leaves us with a bit of a question, which is why did we bother to
write it into the KDB in the first place?

>      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 :(

The kinit -k race is ``less bad'' than the TGS race, though, because
the client host can organise kinit -k to run at different times
than key rotation more easily given that it is a single host.

That said, I think that the Kerberos libs should try older kvnos in a
keytab if the most recent one fails as I mentioned above.

>    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                      [2]http://Imrryr.ORG/~elric/
> 
> References
> 
>    1. mailto:elric at imrryr.org
>    2. http://Imrryr.ORG/%7Eelric/


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