[16355] in Kerberos_V5_Development
Re: Removing old keys
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Mon Sep 20 19:37:35 2010
Date: Mon, 20 Sep 2010 18:36:35 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Russ Allbery <rra@stanford.edu>
Message-ID: <20100920233635.GH7857@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <87lj6wf10t.fsf@windlord.stanford.edu>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>, Jonathan Reams <jr3074@columbia.edu>,
Tom Yu <tlyu@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Mon, Sep 20, 2010 at 04:28:18PM -0700, Russ Allbery wrote:
> Nicolas Williams <Nicolas.Williams@oracle.com> writes:
>
> > Also, the kadmin client could delete old keys from keytabs
> > automatically, specifically removing keys whose kvnos are not listed as
> > valid by kadmind.
>
> You only want to do that if the maximum ticket lifetime has passed.
Of course. The idea is to set the kvno differential, principal re-key
interval, and ticket lifetime options so that you don't leave users with
not-yet-expired tickets encrypted in keys that are nowhere to be found.
Preferably the system should not let you shoot your foot off this way.
(And I really wish that the krb5 GSS mech allowed for multiple security
context token round-trips as a way to recover from recoverable errors,
such as having a ticket with an old kvno and needing to do user-to-user
authentication. But I digress.)
The point is: an automatic feature is easier to use than a manual one,
particularly if you'd be pressed to automate the manual one (which I
think we can agree, sites would). Why do something only half-way? Is
this a sysadmin employment project? :) :)
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
