[16350] in Kerberos_V5_Development
Re: Removing old keys
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Mon Sep 20 17:00:42 2010
Date: Mon, 20 Sep 2010 15:59:54 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Tom Yu <tlyu@mit.edu>
Message-ID: <20100920205953.GY7695@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ldvsk14maz1.fsf@cathode-dark-space.mit.edu>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>, Jonathan Reams <jr3074@columbia.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:11:30PM -0400, Tom Yu wrote:
> Greg Hudson <ghudson@MIT.EDU> writes:
>
> > On Mon, 2010-09-20 at 15:31 -0400, Jonathan Reams wrote:
>
> >> Is there a mechanism for pruning old keys in the same way that
> >> kdb5_util lets you purge old master keys that are no longer being
> >> used?
>
> > To the best of my understanding, there is not, short of dumpfile
> > editing. This is a long-standing shortcoming in the kadmin system,
> > which we simply haven't gotten around to correcting.
>
> What would people prefer in terms of an interface for this capability?
>
> * delete all old kvnos
> * delete one specific kvno
> * something else
>
> We would probably implement this as a new kadmin RPC.
While an RPC may be useful by itself, I think it what's needed is a
policy such that sufficiently old keys are deleted on next key change.
The safest policy, ISTM, is delete kvno-3 or kvno-2 on key change. It'd
be nice too to have a way to flag keys as having been "replicated", as
may be necessary in cluster situations. (Though clusters also have to
worry about replay caches, and that's a different topic.)
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
