| Date: | Tue, 5 Aug 2003 19:34:53 -0400 |
| From: | Cesar Garcia <Cesar.Garcia@morganstanley.com> |
| To: | krb5-bugs@mit.edu |
| Cc: | cesar.garcia@morganstanley.com |
| Subject: | minor bug in lifetime logic in krb524 |
Can someone confirm this?
There appears to be is a minor bug in the lifetime logic in
krb524/cnv_tkt_skey.c. It would appear that the intent of the code was
to generate a kerberos 4 ticket with the same expiration time as the
kerberos 5 ticket, adjusting the starttime such that it may be earlier
than the actual starttime. If so, then the current code is only an
appro does not give you these results. I could be wrong about the
intent, the comments a somewhat unclear, but this objective would make
sense, at least to me.
I'm submitting two patches for your review.
The first patch was tested with a build of krb524d and a piece of
client code that examines the sealed portion of an AFS token using
ktc_GetToken, afsconf_GetKey, tkt_DecodeTicket on the client side to
examine the sealed part of the AFS token. The second patch was
tested with an application that acquires AFS tokens by way of 524
using the second patch attached.
Thanks.
There appears to be is a minor bug in the lifetime logic in
krb524/cnv_tkt_skey.c. It would appear that the intent of the code was
to generate a kerberos 4 ticket with the same expiration time as the
kerberos 5 ticket, adjusting the starttime such that it may be earlier
than the actual starttime. If so, then the current code is only an
appro does not give you these results. I could be wrong about the
intent, the comments a somewhat unclear, but this objective would make
sense, at least to me.
I'm submitting two patches for your review.
The first patch was tested with a build of krb524d and a piece of
client code that examines the sealed portion of an AFS token using
ktc_GetToken, afsconf_GetKey, tkt_DecodeTicket on the client side to
examine the sealed part of the AFS token. The second patch was
tested with an application that acquires AFS tokens by way of 524
using the second patch attached.
Thanks.
*** cnv_tkt_skey.c.orig Tue Aug 5 19:23:21 2003
--- cnv_tkt_skey.c Tue Aug 5 19:24:32 2003
***************
*** 132,138 ****
if ((server_time + context->clockskew >= v5etkt->times.starttime)
&& (server_time - context->clockskew <= v5etkt->times.endtime)) {
lifetime = krb_time_to_life(server_time, v5etkt->times.endtime);
! v4endtime = krb_life_to_time(v5etkt->times.starttime, lifetime);
/*
* Adjust start time backwards if the lifetime value
* returned by krb_time_to_life() maps to a longer lifetime
--- 132,138 ----
if ((server_time + context->clockskew >= v5etkt->times.starttime)
&& (server_time - context->clockskew <= v5etkt->times.endtime)) {
lifetime = krb_time_to_life(server_time, v5etkt->times.endtime);
! v4endtime = krb_life_to_time(server_time, lifetime);
/*
* Adjust start time backwards if the lifetime value
* returned by krb_time_to_life() maps to a longer lifetime
--- cnv_tkt_skey.c Tue Aug 5 19:24:32 2003
***************
*** 132,138 ****
if ((server_time + context->clockskew >= v5etkt->times.starttime)
&& (server_time - context->clockskew <= v5etkt->times.endtime)) {
lifetime = krb_time_to_life(server_time, v5etkt->times.endtime);
! v4endtime = krb_life_to_time(v5etkt->times.starttime, lifetime);
/*
* Adjust start time backwards if the lifetime value
* returned by krb_time_to_life() maps to a longer lifetime
--- 132,138 ----
if ((server_time + context->clockskew >= v5etkt->times.starttime)
&& (server_time - context->clockskew <= v5etkt->times.endtime)) {
lifetime = krb_time_to_life(server_time, v5etkt->times.endtime);
! v4endtime = krb_life_to_time(server_time, lifetime);
/*
* Adjust start time backwards if the lifetime value
* returned by krb_time_to_life() maps to a longer lifetime
*** conv_creds.c.orig Tue Aug 5 19:29:09 2003
--- conv_creds.c Tue Aug 5 19:25:30 2003
***************
*** 127,136 ****
sizeof(C_Block));
/* V4 has no concept of authtime or renew_till, so ignore them */
! v4creds->issue_date = v5creds->times.starttime;
! v4creds->lifetime = krb5int_krb_time_to_life(v5creds->times.starttime,
v5creds->times.endtime);
! endtime = krb5int_krb_life_to_time(v5creds->times.starttime,
v4creds->lifetime);
/*
* Adjust start time backwards to deal with rounding up in
--- 127,138 ----
sizeof(C_Block));
/* V4 has no concept of authtime or renew_till, so ignore them */
! if (ret = krb5_timeofday(context, &(v4creds->issue_date)) {
! return ret;
! }
! v4creds->lifetime = krb5int_krb_time_to_life(v4creds->issue_date,
v5creds->times.endtime);
! endtime = krb5int_krb_life_to_time(v4creds->issue_date,
v4creds->lifetime);
/*
* Adjust start time backwards to deal with rounding up in
--- conv_creds.c Tue Aug 5 19:25:30 2003
***************
*** 127,136 ****
sizeof(C_Block));
/* V4 has no concept of authtime or renew_till, so ignore them */
! v4creds->issue_date = v5creds->times.starttime;
! v4creds->lifetime = krb5int_krb_time_to_life(v5creds->times.starttime,
v5creds->times.endtime);
! endtime = krb5int_krb_life_to_time(v5creds->times.starttime,
v4creds->lifetime);
/*
* Adjust start time backwards to deal with rounding up in
--- 127,138 ----
sizeof(C_Block));
/* V4 has no concept of authtime or renew_till, so ignore them */
! if (ret = krb5_timeofday(context, &(v4creds->issue_date)) {
! return ret;
! }
! v4creds->lifetime = krb5int_krb_time_to_life(v4creds->issue_date,
v5creds->times.endtime);
! endtime = krb5int_krb_life_to_time(v4creds->issue_date,
v4creds->lifetime);
/*
* Adjust start time backwards to deal with rounding up in