New proposal (Re: Ticket 5338: Race conditions in key rotation)
raeburn at MIT.EDU
Thu Jun 26 09:52:04 EDT 2008
> 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
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.
More information about the krbdev