"revoking" a TGT?

[Chris Hecker]

I keep meaning to contribute my patch for this (not the kvno part, just the
allow_tix check and ability for services to check for bans).  It is
completely rotted relative to the latest rev though.  I need to update.

Chris
On Aug 7, 2016 10:40 PM, "Greg Hudson" <ghudson at mit.edu> wrote:

> 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.
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>