Ticket 5338: Race conditions in key rotation

[Henry B. Hotz]

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