Ticket 5338: Race conditions in key rotation

[Jeffrey Hutzelman]

--On Tuesday, June 24, 2008 09:56:36 PM -0400 Roland Dowdeswell 
<elric at imrryr.org> wrote:

> On 1214346799 seconds since the Beginning of the UNIX epoch
> Nicolas Williams wrote:
>>
>
>> On Tue, Jun 24, 2008 at 01:56:20PM -0400, Roland Dowdeswell wrote:
>>> An example of a case which incremental propagation does not not
>>> mitigate is changing your TGS key if you round robin between KDCs
>>> in a random order.  If you get kvno 7 from the first slave and then
>>> present it to another slave which has only kvno 6 then you will
>>> get a failure.  A lot of environments will use the TGT immediately
>>> after it is obtained in order to get AFS tokens.  So, your window
>>> is a few milliseconds.
>>
>> IMO the correct way to handle this is to first add a new key _disabled_
>> TGTs but it's still available for decrypting TGTs encrypted in that key,
>> wait for replication, then mark the key enabled and replicate.
>>
>> This way when the first KDC (the master) starts using the new TGS key
>> all the other KDCs will have it already and will be able to decrypt the
>> new TGTs.
>
> Sure, that was my first thought as well.  It is the obvious answer.
> When I sat down and thought about it for quite a while, though,
> that didn't seem as good as failing back to the master.  Perhaps
> one could get a better system with a hybrid model...
>
> And a rather important point is that I am specifically talking about
> client behaviour here.  Not KDC behaviour.  Let's not make the mistake
> of assuming that either:
>
> 	1.  the client libraries versions are in sync with
> 	    the KDC version, or
>
> 	2.  that this decision should be made by the KDC
> 	    infrastructure.
>
> So, as a client here is your flow:
>
> 	1.  you got a TGT with kvno 7 from a slave,
>
> 	2.  there was mutual auth involved---so you know that you
> 	    got it from a _real_ slave,
>
> 	3.  you present it to another slave and it does not work,
>
> 	4.  now, you _know_ that there exists a slave for which this
> 	    request would actually work,


No, you don't.  The service principal may not exist.  It may be disabled. 
There may be no mutually-supported enctype.  _Your_ principal may be 
expired.  Or any of a number of other things might be wrong, which the KDC 
may tell you about with an appropriate error code.

"No, you are not allowed to have a ticket" means you are not allowed to 
have a ticket, not "go ask mommy if she will give you one".


The issue here is that you are proposing that the answer to a set of KDC's 
not presenting a consistent view of the realm is not to fix the KDC's, but 
to require clients to query multiple KDC's and compare their responses, 
which is not what the protocol specification says.

-- Jeff