[krbdev.mit.edu #2027] Premature error 32 (tickets expired) in K4 
    Ron DiNapoli via RT 
    rt-comment at krbdev.mit.edu
       
    Wed Nov 26 07:43:56 EST 2003
    
    
  
   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)) 
 > CLOCK_SKEW) {
         ret = RD_AP_EXP;
         goto cleanup;
     }
to better match the K5 code?
Let me know what you think...
--Ron D.
_________________________________________________________________
Ron DiNapoli
Programmer/Analyst, Lead
Cornell University, CIT/I&D
rd29 at cornell.edu
(607) 255-7605 
                                                             
    
    
More information about the krb5-bugs
mailing list