[35836] in Kerberos
Re: Request to change MIT Kerberos behavior when principal is expired,
daemon@ATHENA.MIT.EDU (Russ Allbery)
Fri Mar 7 19:45:24 2014
From: Russ Allbery <eagle@eyrie.org>
To: "kerberos\@mit.edu" <kerberos@mit.edu>
In-Reply-To: <CAK3OfOhNG20Ycu9m3xN7BkZcgDndMm-vP7maCCUO1MvAEdHtmw@mail.gmail.com>
(Nico Williams's message of "Fri, 7 Mar 2014 18:38:02 -0600")
Date: Fri, 07 Mar 2014 16:45:12 -0800
Message-ID: <87fvmtv7qf.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Nico Williams <nico@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@eyrie.org) <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
