Change in K4 ticket cache format

Jeffrey Altman jaltman at columbia.edu
Mon May 16 22:14:43 EDT 2005


Russ:

There are clearly 64-bit issues with the Kerberos 4 code.   The
CREDENTIALS data structure in the older krb4 library (as used on
Windows for example) shows the issue_date as a "long" and not a KRB4_32.

The krb_save_credentials() function in both the krb4-compat library and
the original krb4 library use a "long" for the issue_date parameter.
The ccache-glue.c code uses a "long", the memcache uses a "long", as
well as everything else in the krb4-compat library.

The declaration of the CREDENTIALS struct in the krb4-compat version of
krb.h as KRB4_32 goes back at least to the 1.0 release.   Clearly there
was an intention to convert from the use of "long" to KRB4_32 at some
point which was never followed through.

I do not believe that this is worth fixing at this point other than to
perhap change the KRB4_32 back to "long".   MIT has already announced
the end of life for Krb4 support.   Between the end of life statement
and the 64-bit compatibility issues MIT has concluded that new 64-bit
platforms such as KFW for 64-bit Windows will not contain krb4 support.

Jeffrey Altman


Russ Allbery wrote:

> [ Sending this from the correct address -- please feel free to reject the
>   duplicate in the moderation queue. ]
> 
> I *think* this was already discussed here at some point in the past, but I
> wanted to bring it up again since I just got bitten by it.
> 
> The comments in lib/krb4/tf_util.c about the ticket format have always
> said:
> 
>  *      Where "CREDENTIAL_x" consists of the following fixed-length
>  *      fields from the CREDENTIALS structure (see "krb.h"):
>  *
>  *              char            service[ANAME_SZ]
>  *              char            instance[INST_SZ]
>  *              char            realm[REALM_SZ]
>  *              C_Block         session
>  *              int             lifetime
>  *              int             kvno
>  *              KTEXT_ST        ticket_st
>  *              long            issue_date
> 
> However, that last data type has been wrong for a long time.  If one looks
> at krb.h, the definition of the CREDENTIALS struct includes:
> 
>     KRB4_32 issue_date;         /* The issue time */
> 
> Now, in the code in lib/krb4/tf_util.c to read the ticket cache, it has
> always done the equivalent of:
> 
>     tf_read((char *) &(issue_date), sizeof(issue_date));
>     c->issue_date = issue_date;
> 
> but in Kerberos v5 1.2.8, issue_date was defined as a KRB4_32, the same as
> is specified in krb.h.  However, at some point in the 1.3.x series (and
> apparently without a mention in the ChangeLog that I can find), the
> definition of issue_date in tf_get_cred() and also in tf_save_cred() was
> changed from KRB4_32 to a long.
> 
> The practical impact of this change is to break ticket file compatibility
> with KTH Kerberos on 64-bit platforms, since KTH Kerberos continues to use
> an int32_t for the issue date as stored in the ticket cache on disk.
> 
> This is largely our fault for not having realized this far, far sooner, as
> we've been horribly behind in our local Kerberos installation for quite a
> while and not been involved in beta testing.
> 
> This problem has now been around for a while, so I'm not sure what
> problems would now be caused by switching back.  In the abstract, I think
> changing the K4 ticket cache format is a very bad idea, even if it gives
> better timestamp support on those platforms, since K4 is essentially dead
> anyway and really should just be frozen in place.  However, the change
> already happened a while back and this would be another change to undo it.
> It would, however, be really nice to stay compatible with KTH Kerberos, as
> that's the best source for an aklog program that works with K4 for those
> of us who are still in the process of migrating.
> 
> Regardless of what approach is taken, the comment in lib/krb4/tf_util.c
> really should be changed, as I bet the code was modified to be consistent
> with the comment.
> 


More information about the krbdev mailing list