New proposal (Re: Ticket 5338: Race conditions in key rotation)

[Ken Raeburn]

>   Obviously,
> just having slaves turn themselves off if they haven't heard from
> the master for a while defeats one of the main purposes of having
> slaves: that they can respond when the master is not reachable.

True.  On the other hand, if slave propagations can be blocked (e.g.,  
an attacker sniffing packets sends a RST each time the propagation  
starts up), then the attacker can ensure that the slave won't see  
password changes, but will still issue tickets, giving an attacker  
more time for online attacks on users' keys.  Even if it's an old  
password by the time it gets cracked, and not directly useful on a  
server other than that slave, the attacker will still be able to get  
valid credentials, including password-changing credentials, from the  
slave.  The outdated slave will also fail to implement any new  
restrictions (shorter ticket lifetimes, changes to authorization data,  
etc) that may have been imposed, which may be bad from an  
administrative perspective.

So there are some arguments in favor of not running the slave on old  
data indefinitely, at least automatically.

> Given that failing on UDP to a lack of a response takes a bit of
> time, it would probably make sense to define an error which mandates
> the immediate failover.  That would require modifications to the
> client-side libraries.

KDC_ERR_SVC_UNAVAILABLE?