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