Proposal: Support for 32 bit version numbers in keytabs

[Douglas E. Engert]

How does this work with SEAM on Solaris or HP's Kerberos or any other
vendor?

Ezra Peisach wrote:

> 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
> 
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444