[452] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Liftimes in tickets

daemon@TELECOM.MIT.EDU (Jerome H. Saltzer)
Wed Jul 20 16:15:01 1988

To: kerberos@ATHENA.MIT.EDU
Cc: Clifford Neuman <bcn%arctic.uit.uninett@tor.nta.no>,
In-Reply-To: Jim Bloom <jb%cs.brown.edu@RELAY.CS.NET>'s message of Mon, 11 Jul 88 15:53:11 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>



> I agree that the liftimes need a longer timeout.
  . . .
> What's the tradeoff of encrypting additional bytes versus having to
> convert time units (a multiplication or division)?

One way to expand the range of timeouts, yet avoid encrypting
additional bytes, is to notice that it isn't really important to
allow a timeout of every possible integer value.

If one allowed timeouts only of 1, 2, 4, 8, 16, etc. seconds, a
single byte could be used, interpreted as an exponent of 2.  That
would allow timeouts ranging from 1 second to several gazillion
years, but without very good resolution at the larger end.

A practical version of this idea could be to reinterpret one byte in
a rudimentary floating point: take the last three bits of the byte,
shift them left the number of bits indicated by the first five bits,
and consider the result to be the integer number of seconds wanted
for the timeout.  That would allow timeouts ranging from 1 second to
500 years, with good resolution.  (One might limit the shift value
to 29, so that the result would always fit in a 32-bit word.  That
would limit the upper end to about 100 years.)

					Jerry




home help back first fref pref prev next nref lref last post