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.