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: 1241

It appears that the kadmin protocol also only supports kvnos up to 
255.  xdr_krb5_kvno() truncates the kvno to 8 bits and marshals it 
using xdr_u_char().

It may be possible to fix this in a backwards-compatible fashion, 
because xdr_u_char() still uses 32 bits to marshal the value and 
doesn't do any bounds checking on decode.  But of course even if we 
do that, keytab code can't assume it's not interacting with an old 
kadmind which truncates kvnos.

There are pivot heuristics in krb5_ktfile_get_entry() to make key 
rotations continue to work across the 8-bit boundary.  The heuristics 
are:

* When getting the highest kvno, if we see any entries with kvno > 
240, we start comparing kvno values with ((kvno + 128) % 256) so that 
values from 1-127 are assumed to refer to 256+N instead.

* When getting a specific kvno, we compare only the low eight bits of 
the kvno.

My original plan had been to get rid of these heuristics, believing 
the kvno problem to be local to the FILE keytab code.  In light of 
the kadmin issue, we can't safely do that.  At the same time, those 
heuristics can yield the wrong result.  We may need to make the 
heuristics more clever--for example, by disabling them if we see any 
kvno values > 255.