Support for 32 bit version numbers in keytabs

[Jeffrey Altman]

Seema:

The krbdev discussion stalled when we discovered that this would be an
problem for existing Java implementations.  I think the first step is
to make sure that the Java implementation uses the record length field.
This would have to be available for some period of time before we could
consider breaking existing applications with an incompatible change.

However, I do believe that if we were to go ahead with this that the
32-bit kvno at the end of the record would supercede the value stored
in the 8-bit kvno slot.

Jeffrey Altman


Seema Malkani wrote:

> We are looking into fixing this issue with keytab.
> 
> If a 32-bit kvno is appended at the end of the record, the previous
> 8-bit kvno value is ignored. Do we need to perform any checks on the kvno ?
> 
> Seema
> 
> Jeffrey Altman wrote:
> 
> 
>>On krbdev at mit.edu there is currently a discussion underway to extend the 
>>current MIT keytab format to append the kvno as a 32-bit value at the 
>>end of each record.  This is to be done because the current file format
>>only allocates a single byte for the kvno and this is being more 
>>frequently exceeded.
>>
>>We are attempting to determine if this change will more adversely
>>affect compatibility with the Java classes which manipulate keytabs.
>>In particular, we would like to know if you use the record length
>>field to seek to the subsequent record; or do you assume that each
>>record contains a fixed number of fields and is therefore immediately
>>following the last known field of the current record?
>>
>>Jeffrey Altman
>>
>> 
>>