Ticket 5338: Race conditions in key rotation

[Jeffrey Altman]

Roland Dowdeswell wrote:
> So, this is going to be a bit of a long e-mail so let me apologise
> in advance.  I think that I'm going to try to structure my thoughts
> into a few sections as there are a few rather distinct topics that
> are all intertwined.  Failing back to the master on failures is
> not simply about key rotation.  I have been thinking about just
> implementing the failover to the master at work but I have been
> holding off on it because I would rather see it implemented in the
> main release than maintain [yet another] independent patch.
> 
> It's a little late, so this e-mail may be a bit conversational.
> 
> Failing over the Master on all Failures
> ---------------------------------------
> 
> Failing over to the master on failures is an easy and seamless way
> to provide a consistent view of a completely up to date Kerberos
> database at any time when the master is reachable.  This is not
> merely an issue of solving a race here or there.  It is about
> designing a system which with as little state as possible can
> present a view to its client libraries that allows changes to be
> effective immediately [almost all the time] without having the
> master KDC have to block changes until each of the slaves has
> accepted it.
 >
 > ...  much deleted ...

In summary, failing over to the master is an easy stateless
way of addressing any number of potential errors that can be
the result of a configuration error, a software bug, a network
error, etc.  Many of the configuration errors that can occur
result in the Generic Error being sent to the client.  The
client therefore would have no ability to enumerate them even
if doing so was the right idea.   Enumerating specific errors
for which a client should fail over makes it impossible to
support fail over in older clients for new errors that may be
introduced in the future.

I am going to write a patch to introduce fail over to the master
for all tgs requests.   I will add it to ticket 5338 and it can
then be evaluated for inclusion.

Jeffrey Altman
Secure Endpoints Inc.