Ticket History #2027: Premature error 32 (tickets expired) in K4

We recently stumbled onto a problem here at Cornell with short TGT
lifetimes in a K4 environment. Some public library machines are
setting TGT lifetimes to 5 minutes assuming the students are getting up
and leaving their ticket enabled. While I'm not trying to debate that
issue, we noticed a potential bug in the kerberos server code when
investigating further.

In the krb5-1.3.1 source tree, the file src/lib/krb4/rd_req.c has the
following code at line 403 to help determine if a ticket is still
valid...

else if (krb_life_to_time((KRB4_32)ad->time_sec, ad->life)
< t_local + CLOCK_SKEW) {
ret = RD_AP_EXP;
goto cleanup;
}

I've loosely interpreted this as

if (ticket_end_time < current_time + CLOCK_SKEW)
ticket_is_expired
else
ticket_is_valid

That means that if the client and server are perfectly time sync'd, the
ticket will start to "fail" EARLIER than it's actual end time... to be
more precise at

end_time - CLOCK_SKEW

which happens to be defined to be 300 seconds (5 minutes).

Sure enough, when a TGT (K4) has less than 5 minutes of life left, we
can no longer obtain service tickets. This is a problem in the
situation mentioned above with public library machines.

Now, I compared this code to code that seems to test for when K5
credentials are no longer valid. In src/lib/krb5/krb/valid_times.c,
about line 58, we see the following code:

if ((currenttime - times->endtime) > context->clockskew)
return KRB5KRB_AP_ERR_TKT_EXPIRED; /* ticket expired */

Which obviously only becomes true when currenttime is more than
context->clockskew seconds PAST the endtime! If context->clockskew is
300 (5 minutes) then you wouldn't see ticket expired errors until more
than 5 minutes passes beyond the endtime of the ticket. This seems to
be in conflict with the K4 version, but also seems to be the desired
behavior.

Is there any reason not to change the K4 code to this?:

else if ((t_local - krb_life_to_time((KRB4_32)ad->time_sec, ad->life))
ret = RD_AP_EXP;
goto cleanup;
}

to better match the K5 code?

Let me know what you think...

--Ron D.

Sam--

When you get a chance, can you email me an explanation of what the
security issue is? You started to explain it a few months ago, but
when I raised a question regarding the difference between renewing a
ticket with 5 minutes left and one with 4 hours and 5 minutes left, you
stated you needed to think about it and would get back to me. The
email I just received is the first communication I've seen on the
subject since then, so I'd just like some clarification. I believe
I've kept up on watching the krbdev traffic, but, again, I haven't seen
this issues discussed any further.

Thanks,
--Ron D.

On Mar 15, 2004, at 3:26 PM, Sam Hartman via RT wrote: