I realize I didn't not clearly explain the behavior currently
implemented in 1.3.1. The behavior of the current code is to issue
a kerberos 4 ticket whose lifetime exceeds that of the kerberos 5
ticket. The effective endtime for the derived K4 ticket will float
somewhat depending on the timing of the request - not by much, within
the limits one increment in the lifetime byte. This is because the
endtime of the K4 ticket it is not strictly bound to the endtime of
the K5 ticket.

These patches provide a stricter binding of K5 ticket endtime and K4
ticket endtime (they are equivalent). This may be insignificant and
perhaps intended.

>>>>> "Cesar" == Cesar Garcia <Cesar.Garcia@morganstanley.com> writes:

Cesar> Can someone confirm this?
Cesar> There appears to be is a minor bug in the lifetime logic in
Cesar> krb524/cnv_tkt_skey.c. It would appear that the intent of the code was
Cesar> to generate a kerberos 4 ticket with the same expiration time as the 
Cesar> kerberos 5 ticket, adjusting the starttime such that it may be earlier
Cesar> than the actual starttime. If so, then the current code is only an
Cesar> appro does not give you these results. I could be wrong about the
Cesar> intent, the comments a somewhat unclear, but this objective would make
Cesar> sense, at least to me.

Cesar> I'm submitting two patches for your review.

Cesar> The first patch was tested with a build of krb524d and a piece of
Cesar> client code that examines the sealed portion of an AFS token using
Cesar> ktc_GetToken, afsconf_GetKey, tkt_DecodeTicket on the client side to
Cesar> examine the sealed part of the AFS token. The second patch was
Cesar> tested with an application that acquires AFS tokens by way of 524
Cesar> using the second patch attached.

Cesar> Thanks.

Cesar> *** cnv_tkt_skey.c.orig	Tue Aug  5 19:23:21 2003
Cesar> --- cnv_tkt_skey.c	Tue Aug  5 19:24:32 2003
Cesar> ***************
Cesar> *** 132,138 ****
Cesar>        if ((server_time + context->clockskew >= v5etkt->times.starttime)
Cesar>   	 && (server_time - context->clockskew <= v5etkt->times.endtime)) {
Cesar>   	  lifetime = krb_time_to_life(server_time, v5etkt->times.endtime);
Cesar> ! 	  v4endtime = krb_life_to_time(v5etkt->times.starttime, lifetime);
Cesar>   	  /*
Cesar>   	   * Adjust start time backwards if the lifetime value
Cesar>   	   * returned by krb_time_to_life() maps to a longer lifetime
Cesar> --- 132,138 ----
Cesar>        if ((server_time + context->clockskew >= v5etkt->times.starttime)
Cesar>   	 && (server_time - context->clockskew <= v5etkt->times.endtime)) {
Cesar>   	  lifetime = krb_time_to_life(server_time, v5etkt->times.endtime);
Cesar> ! 	  v4endtime = krb_life_to_time(server_time, lifetime);
Cesar>   	  /*
Cesar>   	   * Adjust start time backwards if the lifetime value
Cesar>   	   * returned by krb_time_to_life() maps to a longer lifetime
Cesar> *** conv_creds.c.orig	Tue Aug  5 19:29:09 2003
Cesar> --- conv_creds.c	Tue Aug  5 19:25:30 2003
Cesar> ***************
Cesar> *** 127,136 ****
Cesar>   		 sizeof(C_Block));
  
Cesar>        /* V4 has no concept of authtime or renew_till, so ignore them */
Cesar> !      v4creds->issue_date = v5creds->times.starttime;
Cesar> !      v4creds->lifetime = krb5int_krb_time_to_life(v5creds->times.starttime,
v5creds-> times.endtime);
Cesar> !      endtime = krb5int_krb_life_to_time(v5creds->times.starttime,
v4creds-> lifetime);
Cesar>        /*
Cesar>         * Adjust start time backwards to deal with rounding up in
Cesar> --- 127,138 ----
Cesar>   		 sizeof(C_Block));
  
Cesar>        /* V4 has no concept of authtime or renew_till, so ignore them */
Cesar> !      if (ret = krb5_timeofday(context, &(v4creds->issue_date)) {
Cesar> !          return ret;
Cesar> !      }
Cesar> !      v4creds->lifetime = krb5int_krb_time_to_life(v4creds->issue_date,
v5creds-> times.endtime);
Cesar> !      endtime = krb5int_krb_life_to_time(v4creds->issue_date,
v4creds-> lifetime);
Cesar>        /*
Cesar>         * Adjust start time backwards to deal with rounding up in