Subject: RE: key changing and handling of authentication failures

From: "Medvinsky, Sasha (SD-EX)" <[email-masked]>
Date: Thu, 22 Feb 2001 17:51:26 -0500

Ken,

On the updates to service keys, this issue was also considered by
PacketCable which is looking at a solution that is similar to what you
describe - the application server would be required to hold old versions of
service keys for a period of time within which all existing tickets for that
server are expected to expire.

Also (in PacketCable), in the case of a compromise the application server
would return KRB_AP_ERR_BADKEYVER error for tickets encrypted with a
compromised service key, but still send a KRB-ERROR message with an
encrypted checksum using that compromised service key.  This appears to be
safe because even though the service key was compromised - it would be
against the adversary's interests to send a BADKEYVER error back.

On the question if the client should contact the KDC after a message
integrity error: what if there is a bad link between a client and a server
with line noise?  In a particular architecture, the right behavior on such
an error might be to contact a backup application server instead of flooding
KDC with TGS requests.  In the case of a changed alias, can we add a new
Kerberos error code such as "client not trusted"?  (PKINIT has such an error
code, but we would need one with the KRB_AP_ prefix.)

Sasha.

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]]
> Sent: Thursday, February 22, 2001 11:53 AM
> To: [email-masked]
> Subject: key changing and handling of authentication failures
> 
> 
> 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
>