Ticket 5338: Race conditions in key rotation

[Jeffrey Hutzelman]

--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
>>> KRB5_REALM_CANT_RESOLVE.
>>
>> 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".

-- Jeff