Ticket 5338: Race conditions in key rotation

[Roland Dowdeswell]

On 1214410730 seconds since the Beginning of the UNIX epoch
Jeffrey Hutzelman wrote:
>

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

It is true that it is not guaranteed that the master will not also
return an error.

Given that the KRB_ERROR message is not encrypted, all the client really
knows is that some random entity on the internet has just told them to
go away...

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

Really?  Are we talking about RFC 4120?  Please point me to the section
of that document where it specifies what the client behaviour should be
when it receives an error from a slave KDC?

I did find the following section in the RFC:

	3.1.6.  Receipt of KRB_ERROR Message

	   If the reply message type is KRB_ERROR, then the client
	   interprets it as an error and performs whatever
	   application-specific tasks are necessary for recovery.

I am not actually convinced that ``recovery'' does not preclude
trying another KDC just to make sure.  In fact, given that the MIT
Kerberos libraries currently do fail back to the master upon the
receipt of certain KRB_ERRORs in certain situations, I can be pretty
sure that it has at least in the past not been interpreted in such
a way.

So, how is this in violation of the standards again?

We also have:

	5.9.  Error Message Specification

	   This section specifies the format for the KRB_ERROR
	   message.  The fields included in the message are intended
	   to return as much information as possible about an error.
	   It is not expected that all the information required by
	   the fields will be available for all types of errors.
	   If the appropriate information is not available when
	   the message is composed, the corresponding field will
	   be left out of the message.

	   Note that because the KRB_ERROR message is not integrity
	   protected, it is quite possible for an intruder to
	   synthesize or modify it.  In particular, this means that
	   the client SHOULD NOT use any fields in this message
	   for security-critical purposes, such as setting a system
	   clock or generating a fresh authenticator.  The message
	   can be useful, however, for advising a user on the reason
	   for some failure.

So, now we know that we are not supposed to use the KRB_ERROR message
for security critical purposes.  That makes me a little less likely to
agree with you.

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