"revoking" a TGT?

[Nico Williams]

On Mon, Aug 08, 2016 at 01:35:07AM -0400, Greg Hudson 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

Heimdal's TGS does do such a check.  However, that doesn't help in
cross-realm cases.  A workaround in cross-realm cases is to tune down
the cross-realm TGT expiration times (which then limits service ticket
expiration times).

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

A revocation facility would require more infrastructure, and would
require careful design to protect confidentiality (e.g., during layoffs;
employers generally want to not publicize the names of employees being
laid off until after the event completes).

The simplest thing to do would be to have realms publish notBefore
timestamps representing barriers invalidating all tickets issued before
them.  Note that because RFC1964/4121 doesn't support multiple round
trips at this point, clients would see spurious failures unless they too
check the revocation log to get ahead of it (and even then, since this
would be racy), so this simplest thing may be too simple.  Making the
revocation log contain {H(name at REALM), notBefore} entries would get past
this, but there's a trivial offline dictionary attack on confidentiality
here that is difficult or impossible to counter (especially for realms
with few principals).

Even the simplest reliable revocation schemes beyond having TGSes check
the client principal's record presume a high-performance pub-sub
protocol and implementation(s).

You can see why we don't have a revocation facility.  The workaround is
-and always has been- tuning down ticket expiration times (but not
ticket renew lifetimes).

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

Just a timestamp before which all tickets are to be considered invalid
would go a long way, but that might be too big a hammer (see above).

I wouldn't want any revocation system to depend on monotonically-
increasing kvnos, BTW, and I'm sure others would agree, so using
notBefore timestamps should be it.

Nico
--