"revoking" a TGT?

[Jerry Shipman]

Hello,

Is there a way to invalidate or revoke "old" TGTs for a user that have not expired yet, or to prevent the KDC for issuing service tickets to TGTs that were issued with not-the-most-recent kvno?

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

I could perhaps set -allow_tix on the principal instead of scrambling the password, but I will need to remove that when the user resets his password, after which time the attacker can still use his old TGT (if it hasn't expired yet). (right?)

I thought that the TGT that the attacker has would be associated with the user's old kvno (I don't know if the kvno is in that ticket or not, just guessing). So maybe the KDC could check the kvno, and maybe there is a setting somewhere for "only give service tickets when he gives you a TGT with his most recent kvno" -- or something like that. (?)

Or maybe there is some better idea that I didn't think of?

Is there something I can do to plug this gap?
It's not an enormous gap, and the attacker has probably already done whatever he was going to do at this point anyway; maybe it doesn't matter. 
But I thought it was worth asking.

Thanks for your help,
Jerry Shipman