[OpenAFS-devel] afs/auth.h - ktc_token

[Marcus Watts]

Jeffrey Altman <jaltman@secure-endpoints.com> replied:
> Sean O'Malley wrote:
> > im looking at struct ktc_token in auth/auth.h or afs/auth.h
> > 
> > struct ktc_token {
> >     afs_int32 startTime;
> >     afs_int32 endTime;
> >     short kvno;                 /* XXX UNALIGNED */
> >     int ticketLen;
> >     char ticket[MAXKTCTICKETLEN];
> > };
> > 
> > Should the types of afs_int32's be changes to time_t's since they are time
> > values?
> > 
> > I am -assuming- since solaris is defining time_t as a long in part of the
> > code clean-up to get some of the 64-bit stuff working it was improperly
> > defined as an afs_int32 or it was declared that way for platforms that
> > don't have a time.h file defining time_t.
> 
> Absolutely not.  time_t is a 64-bit value on many systems.
> time within AFS is currently 32-bit and must remain that way because
> times are part of data structures that must remain platform agnostic.
> afs_int32 is used intentionally.
> 
> At some point OpenAFS and Kerberos will need to address 64-bit times.
> But that day is not today.

Here's some things to think about for this.

Firstly, I believe Sean will actually want to look at src/auth/auth.p.h
- auth.h is auto-generated (notice comment at start).

Secondly, I don't believe this *particular* structure is exported on
the wire.  This could probably be made 64 bits and still work.
There are almost certainly going to be local 64-bit rounding
issues, especially wherever this thing gets used with openafs &
kerberos times (as Jeff points out these have to remain 32-bit for
now).  Since this is a kerberos 4 specific structure and kerberos 4
itself is "going away" it's unlikely to have its 32-bit time issues
fixed - so there will probably never be anything that can make a
ktc_token that needs 64 bit timestamps.

3rdly, this structure is "going away".  With rxk5, there's a completely
different structure from kerberos 5 that logically replaces it (krb5_creds).
In fact, that could be a 64-bit quantity - kerberos 5 exports times
as some sort of evil asn.1 timestamp quantity so there's not actually
any k5 wire level issue with making this 64-bit.  Whether that's
really true depends entirely on the local kerberos library & asn.1 support.

4thly, this structure is today exported in at least one context it does
not belong.  The last parameter for vldbClientInit() (actually part
of the backup library) is a ktc_token*.  It should be an "expires" pointer
(the endtime is actually the only part used.)

5thly, the most interesting use of timestamps is probably in rx,
which worries a lot about timing, retries, and so forth.  It also
knows about when the ticket expires, so that's the common point
where ticket timestamps really matter.  In rx, performance also matters,
so it's not clear you want to be doing a lot of 64-bit math on 32-bit
platforms.  Eventually that won't matter (everyone will do 64-bit math
just as fast) but for now it probably does.

					-Marcus