Ticket 5338: Race conditions in key rotation
jhutz at cmu.edu
Tue Jun 24 12:41:44 EDT 2008
--On Wednesday, June 18, 2008 06:41:27 PM -0400 Jeffrey Altman
<jaltman at secure-endpoints.com> wrote:
> Ken Raeburn wrote:
>> On Jun 18, 2008, at 17:01, Jeffrey Altman wrote:
>>> In order to address this race condition I propose that krb5_send_tgs()
>>> be modified to retry against the master KDC whenever there is an
>>> error and the error is not one of KRB5_KDC_UNREACH or
>> What's the actual error that would be returned in such a case?
> KRB5KRB_ERR_GENERIC with the error text specifying a kvno not found.
>> Wouldn't it make sense to do the retry only for one specific error?
> I don't think so. I think that any misconfiguration of a slave kdc
> should result in the master being asked since the master's response is
> going to be definitive.
The presumption here is that there _is_ a "master" which is "more
definitive". IMHO, it is better here to fix the behavior of the KDC than
to introduce the expectation that in order to get proper results, clients
must implement a behavior which is not documented in any standard.
In the case of key rollover, whether it's the master key or the TGS key or
some other service's key, I believe the correct approach is to allow new
keys to be registered in the KDB without being used to issue new tickets
until the change has reached everyone that needs to know about it.
If I tell you "no", that means "no", not "go ask mommy and see if she gives
you an answer you like more".
More information about the krbdev