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  
>> addressed
>> well, so that the clients don't have to do any of this sort of thing.
>> Incremental propagation support will help, though Sun's  
>> implementation
>> that I'm looking at integrating uses a periodic polling model, not an
>> instantaneous push model.  However it should cut down the delay  
>> needed
>> 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
> exists.
> 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  
than solution.

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 mailing list