"revoking" a TGT?

Greg Hudson ghudson at mit.edu
Mon Aug 8 01:35:07 EDT 2016


On 08/05/2016 09:51 AM, Jerry Shipman wrote:
> I am trying to do something like this:
>  - I identify a user whose password is known to an attacker by some other process
>  - I scramble the user's password and tell him he that needs to reset it by some outside process (e.g. a trip to the helpdesk with his ID)
>  - When the user resets his password, then he can authenticate again.
>  - But, there is a little gap... after I scramble the password, the attacker can no longer get new TGTs... but he might still have an old TGT for a few hours until it expires, which he can use to get new service tickets. Is there a way to prevent that? (He could also already have some active service tickets, but I don't think there is anything I can do about that.)

Currently there is no way to prevent that.  The TGS code path in the KDC
doesn't perform any policy checks on the client principal entry, so even
if the client principal is disabled, the KDC will continue issuing
service tickets for existing TGTs until they expire.  I think the
historical viewpoint was that, because the attacker could have acquired
service tickets at the time the tickets were stolen, there isn't much
point in going to extra effort to make it possible to close the barn
door after the horse has escaped.  (Also, if the client principal is in
another realm, the TGS server doesn't usually have access to its
database entry.)  We have considered reversing this position at times,
but haven't implemented any changes to date.

For this specific scenario, we would need more than to examine the
client principal entry for the usual policy checks; as you surmised, we
would need a way (perhaps a principal flag) to express that old kvnos
are invalid for this principal entry.


More information about the Kerberos mailing list