[16352] in Kerberos_V5_Development
Re: Removing old keys
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Mon Sep 20 18:56:40 2010
Date: Mon, 20 Sep 2010 17:56:01 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Tom Yu <tlyu@mit.edu>
Message-ID: <20100920225601.GD7857@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ldvk4mgm3zs.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 06:42:15PM -0400, Tom Yu wrote:
> Nicolas Williams <Nicolas.Williams@oracle.com> writes:
>
> > 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.)
>
> We have explored some of these possibilities, such as "not valid
> before/after" timestamps on each kvno, or "validity" flags on kvnos.
> I would consider those alternatives as a longer-term solution in the
> evolution of our database abstraction, while the "purge old keys"
> capability is something that can be implemented in the short term.
Purging kvno-N keys on key change is as trivial to implement in the
short term, and much easier to use (no need to change any procedures at
all on the client side). All you need is a place to store the value of
N in question, such as the policy object, or krb5.conf, or a
per-principal TL_datum.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
