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