Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
RT-Send-CC:
X-RT-Original-Encoding: iso-8859-1
Content-Length: 633

My understanding is that the krb5 keytab format was based loosely on 
Kerberos 4's srvtab format, and in an error of omission, the kvno field 
was left at 8 bits.

We have several heuristics to work around this mistake.  
krb5_ktfile_get_entry() tries to detect wraparound when looking up the 
highest kvno in the keytab, for instance.

There is a path away from this mistake if we look at Heimdal and Shishi.  
They both support a 32-bit kvno value located after the existing keytab 
fields, overriding the 8-bit value.  This is documented at:

http://www.gnu.org/software/shishi/manual/html_node/The-Keytab-Binary-
File-Format.html