Premature Error 32 (tickets expired) in K4?

[Ron DiNapoli]

Hi Sam--

   See comments below...

On Dec 10, 2003, at 2:26 PM, Sam Hartman wrote:

>
> [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.
>

I understand that, in this scenario, your service ticket would be good 
for 5 minutes, but that wouldn't change the fact that your TGT expires 
in 30 seconds right?   And once the TGT is expired (+ 5minutes if you 
are perfectly sync'd timewise with the KDC and have applied my proposed 
mod) doesn't that prevent you from obtaining/renewing more service 
tickets?

> 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.
>
>

Just to clarify, does this mean that the code in the krb5-1.3.1 tree in 
question was purposely made that way due to this Cygnus fix?

> 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.
>

thanks for continuing to think about this...
--Ron

> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>
_________________________________________________________________
Ron DiNapoli
Programmer/Analyst, Lead
Cornell University, CIT/I&D
rd29 at cornell.edu
(607) 255-7605