Proposal: Support for 32 bit version numbers in keytabs

[Ezra Peisach]

I have examined the format of the keytab file and how it is implemented
in both the MIT and the Heimdal code base. I believe we can insert a 32
bit version number in the keytab file - without a flag day, and be
compatible with older code.  The short answer is to store both an 8 bit
vno and a 32 bit one. Heimdal is already doing this.

How to do this?

The format of the keytab file is rather simple.
<file format vno>
<record length>
principal timestamp vno key
<record length>
principal timestamp vno key
...

The format of the principal is not really relevant - but there are
subtle differences in version 1 vs 2 of the keytab. Also in version 1,
lengths are in host byte order, and in version 2 - they are in network
byte order.

I can draw the following conclusions about the code:
a) MIT and Heimdal appear to be using the same format
b) The keytab is positioned for each subsequent read by offsetting
<record length> from the end of the previous record.
c) This means - that extra information may be stored after the key in
the keytab - provided the record length is correct.

This is exactly what Heimdal has done.  In reading a keytab entry - if
there is room at the end, between the key and the next record for 4
bytes - then they contain a 32bit version number.

I believe this can be implemented in the MIT code with relatively few
changes:

a) When reading a keytab entry - check for - a full 32bit version
number. If set, and non-zero - then this is the real version number -
otherwise use the 8bit form.

b) When writing a keytab - add the extended vno afterwards. [Question -
should this be done if kvno will fit in 8 bits?]

c) When comparing version numbers, if the version number > 255, then
don't play the games of version numbers > 140 game.  My view is that
keytabs with entries added from here on out - should always have higher
version numbers than the old ones - and will probably be okay. If vno <=
255, do the masking game of requested vno & 0xff (i.e. no change).

>From what I can see, the only deficiency in this design is that if one
were to write code to copy an old keytab to a new one, and a key version
number is > 255, the extended vno will be wrong - but then we are still
falling back on old heuristics - so no change needed.  The code will
read the old 8 bit flavor, and then assume that it is the full 32 bit
one. I believe this will be okay - as the code would fallback on the old
case then.

I am willing to make the required code changes if people think this is
the correct way to go about it.


Ezra