Change in K4 ticket cache format

John Hascall john at iastate.edu
Tue May 17 07:25:42 EDT 2005



Jeffrey Altman <jaltman at columbia.edu> writes:
> 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.

Hey, it's been ignored since at least
  http://mailman.mit.edu/pipermail/krbdev/2002/001021.html
when I mentioned it.  If it's ignored long enough, maybe it'll
just go away, eh?  :)

John




> 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.
> > 
> 
> --------------ms040501030602000803010208--
> 
> --===============29211890769266979==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> --===============29211890769266979==--
> 



More information about the krbdev mailing list