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

Russ Allbery eagle at eyrie.org
Fri Mar 7 19:45:12 EST 2014


Nico Williams <nico at cryptonector.com> writes:

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

Yeah, I don't think we could enable the password change invalidation here.
It's a neat idea, and it's a clear win from a security perspective, but
it's one of those things that devilishly hard to explain to users.  Most
users aren't even aware they *have* a Kerberos ticket cache; it's some
detail that software manages for them.  So when it suddenly breaks, it's
hopelessly confusing to them.

-- 
Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>


More information about the Kerberos mailing list