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

Reply via email to