V4 tickets expiring too soon
jhutz at cmu.edu
Sat Nov 20 15:37:09 EST 2004
On Saturday, November 20, 2004 01:46:20 -0500 Peter DiCamillo
<Peter_DiCamillo at brown.edu> wrote:
> * This calculation is different than the same expiration
> * calculation in krb5. In krb5 the ticket lasts for
> * clock_skew seconds longer than its expiration; in krb4 it
> * lasts clock_skew seconds less. This difference is
> * necessary to avoid using an almost expired tgt to get a new
> * tgt that will last for another 5 minutes. This code
> * interacts with the login in src/kdc/kerberos_v4.c to
> * back-date tickets to avoid them expiring late. The
> * combination may be overly conservative, but I'm fairly sure
> * either removing the kerberos_v4 backdating or replacing
> * this check with the krb5 check is sufficient to create a
> * security problem.
> Is the back-dating intended to have the end result of making a krb4
> ticket also last clock_skew seconds longer than its expiration? If so,
> then it doesn't seem to be working correctly.
No. The backdating the comment refers to is related to what happens when
you use a TGT to ask the TGS for another ticket. As you know, lifetimes in
krb4 tickets are expressed in 5-minute intervals. So, when issuing a
ticket, the TGS needs to compute the remaining life on the TGT (that is,
the difference between the TGT's expiration time and the current time), and
then round to a multiple of 5 minutes so it can be expressed as a lifetime.
Simply rounding up would result in a ticket that expires later than a TGT.
It turned out that this led to a situation where you could keep an existing
TGT alive more or less forever, as long as you renewed it slightly more
often than every 5 minutes. Note here that we're talking about the
lifetime interval, not the clock skew.
Simply rounding down would solve the problem, but would mean that in the
last 5 minutes of a TGT's life, you couldn't use it to get any new tickets,
because the lifetime of such tickets would be zero. And you can't just
special case this situation, or you get into the same infinite-renewal
problem as above.
So what the TGS does is actually more complicated. It rounds the lifetime
_up_ to the next multiple of 5 minutes, and then backdates the issue date
of the ticket by up to 5 minutes, such that the resulting expiration time
is not later than that of the TGT. This means that you can get tickets up
to the last second of the TGT's lifetime, but no longer.
Note that this backdating happens only in the TGS, not when getting an
intial ticket. It is necessary only when the KDC needs to make sure the
ticket it's issuing does not expire later than the TGT.
Unfortunately, the code you quoted does have the effect of making a krb4
ticket (including a TGT) useless during the last CLOCK_SKEW of its
lifetime. I believe the need for this can be avoided, but I've not looked
at the KDC code to see if the required check is already in place.
I'm also not a member of the MIT krb5 development team, so I can't speak
for them on whether or when this will be changed. I would suggest that you
send mail about this issue to krb5-bugs at mit.edu so it makes it into the
bug-tracking system; things discussed on this list without also being
recorded there sometimes have a way of slipping through the cracks when
release time comes around.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
More information about the krbdev