Kerberos 1.7 and later does not interoperate with AD Read-only DCs

Greg Hudson ghudson at MIT.EDU
Tue Feb 21 13:10:02 EST 2012

On 02/20/2012 09:54 PM, Adam Bernstein wrote:
> Interestingly, this problem does not reproduce using Kerberos 1.6.

In krb5 1.6 we encode by casting the kvno value (an unsigned int) to
int, then encode it as a signed value.  There is a comment saying
"krb5_kvno should be int".  We decode this field as a signed long and
then cast the result to an unsigned int.  (That means we reject
RFC4120-conformant kvno values >= 0x80000000 on platforms where long is

In krb5 1.7-1.10, as you noted, the encoder treats the field as an
unsigned 32-bit integer, which conforms better to RFC 4120 but generates
TGS requests which don't interoperate with RODCs using RodcIDs >=
0x8000.  The decoder behavior hasn't changed.

In the trunk, we encode and decode the kvno value as unsigned 32-bit
numbers, which means we would probably reject the AS reply from an RODC
with RodcID >= 0x8000.

I think the most practical solution is to restore the 1.6 behavior,
treating kvno as a signed 32-bit value when encoding and decoding.
Although this conflicts with RFC 4120, I think RODCs are the only case
where kvno values that large are likely to appear in the wild.  If
you're in a position to test patches, I will run them by you.

(As an aside, Heimdal appears to treat the EncryptedData kvno field as
unsigned 32-bit, conformant to RFC 4120.  It probably also doesn't
interoperate with RODCs with RodcID >= 0x8000.)

More information about the krbdev mailing list