"revoking" a TGT?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

"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
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: "revoking" a TGT?

Greg Hudson
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: "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" <[hidden email]> 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           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: "revoking" a TGT?

Nico Williams
In reply to this post by Greg Hudson
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@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
--
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: "revoking" a TGT?

Nico Williams
On Wed, Aug 10, 2016 at 11:05:43AM -0500, Nico Williams wrote:
> 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).

Reliable multicast type protocols would be nice for this, though a
unicast (TCP-based, no doubt) protocol should be needed as well.

I've tested a C10K tail-f service to 20k concurrent connections on
loopback just fine, and that could be part of a unicast protocol.
Modern async I/O APIs make this easy enough.  Such a thing can scale by
fanout too, so it's plenty scalable, though multicast would generally
scale best in many networks.

A revocation pub-sub protocol wouldn't be too difficult to design and
implement.  But it is work that would have to be done.

Nico
--
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos