Re: kadmin: failing dump/load
"Roland C. Dowdeswell" <[email protected]> Tue, 7 Nov 2017 11:21:45 -0500
| Newsgroups | gmane.comp.encryption.kerberos.heimdal.general |
|---|---|
| Message-ID | <20171107162144.GA11718@fedora-23-dvm> |
On Tue, Nov 07, 2017 at 10:55:08AM +0100, Patrik Lundin wrote:
>
> Additionally, I see that the prune code basically figures out the most
> recent keyset timestamp that is older than the ticket maximum lifetime and
> then removes all keysets with a timestamp older than that one. This
> means that this too old but most recent keyset will be kept, but since
> it was calculated to be older than max-lifetime, shouldnt it be removed
> as well? As it stands now there will always remain at least one keyset
> (depending on if there are more than one keyset with the same timestamp)
> too old to be useful.
>
> Would it make sense to alter the code to also remove that most recent
> (but too old) keyset? The only functional difference of the diff below
> is the "<" to "<=" change at the bottom, but it felt like it would
> warrant a more fitting variable name as well:
It isn't too old, however. What we are trying to achieve here is
that we keep all of the keys which might have outstanding tickets in
someone's ccache.
An example is illustrative:
KDC has kvno 1 it was set ten weeks ago.
You rotate the service keys.
The KDC now has kvno 2 and it was issued seconds ago.
You rotate the service keys.
The KDC now has kvno 3 and it was issued seconds ago.
Should the KDC now clean up kvno 1 because it was set ten weeks ago?
No, because it was valid up until the time that kvno 2 was set which is
a few seconds ago. And there may be outstanding service tickets for
kvno 1 that live for another 10 hours. And so, you must keep kvno 1
until kvno 2 is at least as old as the max ticket lifetime.
--
Roland C. Dowdeswell