revocation feature in Kerberos

[Benjamin Kaduk]

On Thu, 31 Jul 2014, Chris Hecker wrote:

> Unless things have changed, the KDC doesn't check for account lock if the
> tgt is valid.  There's a thread from a couple years back where I asked
> about this and then patched it, but I haven't submitted patches for the
> current revision.  I need to do this at some point.  Or maybe it got fixed?

Well, for the MIT KDC at least.
There was a more recent thread a few months ago where this came up again: 
http://mailman.mit.edu/pipermail/kerberos/2014-March/thread.html
(it looks like you did post your patch there)

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

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.

>> You can get many of the benefits of a revocation system by simply
>> vending service tickets with a shorter lifetime than the TGT used
>> to obtain them.  If you, e.g. vend service tickets with a 15 minute
>> lifetime, then the client will need to contact the KDC once every
>> 15 minutes to continue to connect to a service.  The KDC, of course,
>> will validate that the client's account has not been locked at this
>> point.
>>
>>> 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.

-Ben