V4 tickets expiring too soon

[Jeffrey Hutzelman]

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