Subject: key changing and handling of authentication failures

From: Ken Raeburn <[email-masked]>
Date: Thu, 22 Feb 2001 14:52:55 -0500 (EST)

The mail from Sasha Medvinsky got me thinking...

If a client has tickets for a service, but using them gets a
bad-integrity error back from the server, what should happen?

I'm thinking in part about the PacketCable issue of a MITM attack on
the KDC-REP message, but also changing keys when key version numbers
aren't maintained, or repointing service principal and hostname
aliases in a sloppy fashion.

We do have explicit language in 3.2.2 saying:

	The client may re-use any tickets it holds until they expire.

But that's not the same as a strong recommendation that service key
management be done in such a way that the clients will actually be
successful at it.  I'd suggest something like this for sections
3.1.3 and 3.3.3:

	The maximum allowable lifetime for tickets for a service
	principal should be short enough that the ticket is expected
	to be valid until that time, even if an administrator chooses
	to change the service key or alter the canonicalization of the
	service principal.  Old keys should be retained by an
	application server until any issued tickets have expired,
	unless the reason for the key change is a compromise of the
	old key, in which case the administrator may decided that
	making the service unavailable to previously-authenticated
	clients is preferable to leaving it vulnerable to attack.

Section 3 isn't exactly the correct place for discussions of service
key management, but we don't have any other at the moment, and this
point does influence how client applications should be written.

(The existing language in 3.3.3 for endtime calculation should
probably be modified along the lines of the language of 3.1.3, so that
it imposes some bounds and suggests others, rather than mandating
exactly how the end time is calculated, and more to the point, the
specific set of factors that the KDC may use in that calculation.
Actually, it should probably be described in just one place and
referenced as needed.)

Also, I thought about suggesting that the client should handle
bad-key-version indications by contacting the KDC again, but that
assumes that at some level the application can simply retry the
authentication; with some of the protocols using Kerberos now, you
can't do that, so the only way to do that is to drop and reestablish
the connection, which may cause some difficulty for the application
writer.

But back to my main point:

If I recall correctly, during the name-canonicalization discussion,
someone from the Microsoft camp (I think) suggested that if
authentication failures result from changed aliases (and I think
bad-integrity is the only error likely to come up in the case of
contacting the new server but using old tickets, but I'm not sure),
the client should be "smart enough" to contact the KDC for new
tickets.  Which is why I'm not just sending the above text to Cliff,
since we might not have agreement...

Do people think the client should contact the KDC again on
bad-integrity errors with non-expired tickets?

Ken

---

From: "Booker C. Bense" <[email-masked]>
Date: Thu, 22 Feb 2001 12:53:47 -0800 (PST)

> bad-integrity errors with non-expired tickets?

- Hmm, my initial reaction is that this is a bad idea. I'm not
quite sure why. I guess the first question I have is :

	When do you stop asking for new service tickets?

- I support quite a few "middleware" kinds of things where if this
behavior was not implemented carefully you could potentially DOS the
KDC. These are daemon things like sendmail and web servers that are
using their service tickets from multiple processes hundreds of times
per minute 24 hrs a day.  If these get an error of any kind I would
much rather handle it in the application code rather than in the
library.

- Let's think about when this error is triggered. 999 times out of
1000 it's when there is a skew between the keytab key and the kdc
key, not when the keytab key changes and there are unexpired
service tickets. Let's consider what happens to something like
sendmail when that occurs.

	Stanford's sendmail does a kerberized LDAP lookup for
every piece of incoming email. An external process maintains
the tgt for the daemon.  If the ldap bind fails for any reason
the email is queued for a retry. Now if the bad-integrity error
is essentially hidden by the library, every time sendmail forks
and processes either an incoming or queued message the KDC will
get X number of service requests. While it takes a lot to hammer
a KDC, sendmail is remarkably good at creating tremendous loads
on supporting servers like DNS,etc...

	Thus you have the potential for one admin misconfiguration to
entirely cripple the authentication infrastructure. I don't think this
is entirely a bad idea, but you need to be quite careful in the
implementation to avoid the creating any potential cascading failure
modes. I much prefer language that puts the onus of keeping old
keys on the server rather than embedding smarts in the client.

- Booker C. Bense