revocation feature in Kerberos

[Nico Williams]

On Thu, Jul 31, 2014 at 5:47 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:
>> On Jul 31, 2014 3:15 PM, "Roland C. Dowdeswell" <elric at imrryr.org> wrote:
>>
>>> On Thu, Jul 31, 2014 at 04:34:42PM -0500, Nico Williams wrote:
>>>>
>>>
>>>> In general Kerberos doesn't need a revocation system because ticket
>>>> lifetimes should be short enough.
>
> The structure of a kerberos ticket doesn't include what key was used for
> the initial authentication that generated it.  That means that the only
> revocation hammer available is a big one, to disallow all tickets for that
> principal.  (As Chris notes, the MIT KDC does not at present even enforce
> that flag at renewal time.)

Or all tickets prior to the revocation event (e.g., password change,
if you thought your password was compromised).

> David Benjamin has an idea for how to work around this, and be able to
> only "revoke" tickets issued with a compromised password, while still
> allowing tickets issued from a newer password to be usable.  I should
> probably write this up and get some more eyes on it; it's been back-burner
> for a while.

For TGTs it's trivial: store a not-before timestamp in the KDB entry
and check it in the TGS.

For services it won't help you and you have to rely on ticket expiration.

>>>> Within a realm it's often the case that other methods are used for
>>>> revocation (e.g., lock the _account_, which will generally replicate
>>>> with less latency than tickets will expire).
>>>
>>> Right and by using different lifetimes for service tickets as their
>>> TGT, you can break apart the ``check that the user knows their
>>> passwd'' check from the ``check that the account is still valid''
>>> check.
>
> That requires all this checking to actually be done.  Per the above, it
> may not be how you think it is or want it to be, at present.

Roland and I were referring to things like Unix accounts.  In order to
login you need your tickets, yes, but also your account to not be
locked.  In many environments the name service update and cache entry
expiration times are such that revocation by locking the _account_ has
lower latency than the typical service ticket lifetime.

Nico
--