Ticket 5338: Race conditions in key rotation
elric at imrryr.org
Wed Jun 25 12:47:01 EDT 2008
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
>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
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/
More information about the krbdev