Wrong type of TGS nonce?

[jnshao]

The environment is using samba lorikeet-heimdal which is forked from here and is patched for KDC. But the problem was found as kerberos client with a Windows AD. I thouth the bug might exist in both repo due to the same encode implmentation of kerberos TGS nonce.

Symptom

While using Kerberos authentication, the TGS process may fail on the client side due to a mismatched nonce.

Reproduce*

It is hard to reproduce because it relies on the random nonce value generated by the krb5_generate_random_block function within get_cred_kdc. However, it can still be reproduced by directly assigning the nonce value using gdb.

Bug

The nonce will be encoded in ASN1. And I found that if the nonce is greater than 4286578687 ( > 0xFF7FFFFF), the MSB 8 bits will be discarded.

Details

Based on the RFC4120, the nonce should be unsigned int, but the KDC-REQ-BODY in krb5.asn1 is still Krb5Int32 which is differ to Krb5UInt32 for ASN1 encode.

client side generated the nonce: 4286578688 (0xFF800000)
nonce after encoded in TGS-REQ will be: 8388608 (0x800000)

If the nonce type is Krb5Int32, it will call der_put_integer to encode the value. And if the nonce type is Krb5UInt32, it will call der_put_unsigned to encode the value. After I change the nonce type of KDC-REQ-BODY from Krb5Int32 to Krb5UInt32 in krb5.asn1, the issue was solved.

I wonder is there a compatibility issue with the kerberos implementation? I found that RFC1510 specifies the nonce as an INTEGER. However, RFC4120, which I previously mentioned, stipulates that it should be UInt32.

[nicowilliams]

You're correct, this is a bug in lib/asn1/krb5.asn1. Thank you for this excellent report!

[jnshao]

@nicowilliams Thansk for the prompt confirmation!