Request to change MIT Kerberos behavior when principal is expired, deleted or password changed

[Nico Williams]

On Fri, Mar 7, 2014 at 5:16 PM, Greg Hudson <ghudson at mit.edu> wrote:
> On 03/07/2014 05:17 PM, Edgecombe, Jason wrote:
>> I don't see how anyone can object to rejecting requests for expired or deleted principals.
>
> I don't think anyone has.  In the past I have mentioned performance as a
> [...]

+1.  No one has objected yet.

The problem with applying this to password changes is that if you're
logged in on multiple systems you'll have to kinit on each of them...
*or* have SSH cascading credential delegation going.  Now, if your
cascading credential delegation clients are using timers based on
ticket expiration... then your new tickets won't be forwarded soon
enough.  This could get annoying.

Password changes are annoying enough as it is, so I could see someone
objecting to that.  Preemptively making this configurable seems like a
win to me.

> The change may not be a trivial one to make safely, because there are so
> many edge cases in modern TGS request processing.

I don't think it's unsafe.  I do think it will annoy users as to
password changes.

> Be aware that:
>
> * We cannot generally do these checks for cross-realm TGS requests.

The MIT and Heimdal KDCs support multiple realms in the same DB.
(MIT's kadmind doesn't, but so what).  Such usage will surely be rare,
but if the TGS has the crealm's DB, then it should check it.

> * The KDC cannot revoke already-issued service tickets.

Right, we have no revocation protocol, and we almost certainly won't
develop one either.  This is a strong incentive to make all but start
TGTs fairly short-lived.  (In practice people tend to have something
like revocation via, e.g., marking user accounts locked in the Unix
passwd(4) name service.)

Nico
--