New proposal (Re: Ticket 5338: Race conditions in key rotation)

[Roland Dowdeswell]

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

> - Therefore I propose that you either make that change to the protocol
>   through normal channels (i.e., publis a new standards track RFC
>   updating the old one), or that you provide a KDC-side solution so
>   that other client implementors have a way out of having to implement
>   this behavior.

A poor man's solution to the TGS key issue would be:

	1.  if you receive a TGS_REQ with a TGT with a kvno higher than
	    you have, then you know:

		i.   the client has authenticated the KDC from which
		     it received the TGT,

		ii.  therefore, there exists a KDC which has the
		     key unless there is a client bug,

		iii. some client libraries will experience a fatal error
		     if you return KRB_ERROR, and

	2.  you can simply fail to respond with the knowledge that in
	    most cases the client will eventually find the correct KDC.

I'm less fond of this than client side logic but as you point out
it might be preferable to have a KDC-side solution.  It has
``issues''.

In conjunction with the aforementioned transactional logic, this
would be reasonable.  But, the transactional logic by itself begs
too many questions in my opinion to be robust.  I do not think that
there are reasonable semantics for network partitions.  Obviously,
just having slaves turn themselves off if they haven't heard from
the master for a while defeats one of the main purposes of having
slaves: that they can respond when the master is not reachable.

This is a very small subset of ``KDCs that have not been propagated
to stop responding''.  It is more ``KDCs fail to respond to exactly
one kind of request which they can demonstrate that they do not
have a good answer to''.

Given that failing on UDP to a lack of a response takes a bit of
time, it would probably make sense to define an error which mandates
the immediate failover.  That would require modifications to the
client-side libraries.

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