Ticket 5338: Race conditions in key rotation

Roland Dowdeswell elric at imrryr.org
Tue Jun 24 13:47:32 EDT 2008

On 1214326724 seconds since the Beginning of the UNIX epoch
Nicolas Williams wrote:

>On Tue, Jun 24, 2008 at 12:46:31PM -0400, Jeffrey Altman wrote:
>> Jeffrey Hutzelman wrote:
>> >The presumption here is that there _is_ a "master" which is "more 
>> >definitive".  
>> For MIT Kerberos the introduction of "master_kdc" says exactly that.
>> There is in fact a master and that master is more definitive.  That is
>> how the clients already work when it comes to AS requests.  Our
>> proposal is to extend that behavior to TGS requests.
>> If there is no defined master, then there is no master to fallback to.
>I think this has to default to off.  TGS requests usually outnumber AS
>requests by a fair amount.  I don't think the client should begin to
>behave in a way that seriously challenges the KDC infrastructure
>performance assumptions made by sysadmins in the past.

>From my quick analysis of our traffic, only 1.5% of the requests
will be retried on the master.  I'm reasonably convinced that our
master will be able to deal with a 1.5% usage spike, granted it
might slow down a bit but I'm not sure if it will be a measurable

My guess would be that most sysadmins provision master KDCs that
can deal with a 1.5% usage increase without falling over.

As I said in my previous e-mail, the 1.5% is only based on a few
days of usage.  And maybe it is a small site, we only get a few
million {AS,TGS}_REQs a day.  Are there any other examples that we
can consider where this would cause more than a few percentage
points of additional load?

    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/

More information about the krbdev mailing list