Ticket 5338: Race conditions in key rotation
Henry B. Hotz
hotz at jpl.nasa.gov
Tue Jun 24 13:04:36 EDT 2008
On Jun 23, 2008, at 11:30 PM, krbdev-request at mit.edu wrote:
>> In the long term, I'd rather see the synchronization problem
>> well, so that the clients don't have to do any of this sort of thing.
>> Incremental propagation support will help, though Sun's
>> that I'm looking at integrating uses a periodic polling model, not an
>> instantaneous push model. However it should cut down the delay
>> for propagation, so you can say, e.g., "after a new service is
>> registered, you may have to wait 30 seconds for the information to
>> propagate before you can authenticate to it". (Actually, in the long
>> term, I'd like to see a multi-master type arrangement where we don't
>> even have a distinguished "master KDC". But failing that, immediate
>> propagation of all changes seems like a very desirable substitute.)
> Incremental propagation does not solve race conditions. It just
> makes one runner a little faster but the underlying issue still
> I'm not convinced that I would like to have a multi-master scheme,
> it seems that it would add complexity for little additional value.
As a practical matter incremental propagation (a la Heimdal, sorry)
makes these issues moot, as long as it's reliable enough. If it
fails, it should most likely to be due to a network problem, which is
exactly what the slave is there to mitigate in my case. I would
imagine there are other institutions where you might want a
fail_if_stale threshold on a slave.
Fail-to-master seems reasonable, but it seems like mitigation rather
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
More information about the krbdev