Premature Error 32 (tickets expired) in K4?

[Sam Hartman]

[Jeff please note that the KFW behavior on this issue is wrong and
should not be migrated to the krb5 tree.  KFW 3.0 will have a change
in functionality.]

>>>>> "Ron" == Ron DiNapoli <rd29 at cornell.edu> writes:

    Ron> Hi All-- We recently stumbled onto a problem here at Cornell
    Ron> with short TGT lifetimes in a K4 environment.  Some public
    Ron> In the krb5-1.3.1 source tree, the file src/lib/krb4/rd_req.c
    Ron> has the following code at line 403 to help determine if a
    Ron> ticket is still valid...

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

    Ron> I've loosely interpreted this as

    Ron> if (ticket_end_time < current_time + CLOCK_SKEW)
    Ron> ticket_is_expired else ticket_is_valid

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

    Ron> 	end_time - CLOCK_SKEW

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

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

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

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

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

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

I believe that my previous mail to you also applies, but dinner
discussions with Mark Eichin revealed a technical reason not to make
the change you propose.

The problem is that K4 stores a ticket lifetime not an end time.  The
life time is (for these purposes) in increments of five minutes.  So,
let's say I have a ticket that is valid for 30 more seconds and I ask
the KDC for a new ticket.  The KDC can either issue me no ticket, or
it can issue me a ticket valid for five minutes.  If it issues me a
ticket valid for five minutes then I can continue renewing this ticket
for ever every five minutes.

According to Mark, the folks at Cygnus fixed this problem by changing
the krb4 boundary conditions such that tickets had five minutes less
lifetime than apparent instead of five minutes more lifetime than
apparent.


You could make a change to the code to revert the boundary conditions
back, but you'd need to make a corresponding change to the KDC to
avoid this attack.  In practice this would still make your library
machine TGTs useless.