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

[Adam Bernstein]

This post is to inform the Kerberos community of an interoperability issue with MIT Kerberos and Active Directory 
Read-Only Domain Controllers.

This article describes some differences with read-only Domain Controllers.
   http://blogs.msdn.com/b/openspecification/archive/2011/05/11/notes-on-kerberos-kvno-in-windows-rodc-environment.aspx

At issue is the RodcId field. This field overloads the kvno field, splitting it into 2 2-byte fields: |RodcID|Kvno|

The problem is the range of the RodcId, 0x01 - 0xffff. For example, take the RodcId of 0xc26c0001 (3261857793 decimal). 
This is an example from in-house testing. The proper ASN.1 encoding for this field would be:
     0x020500c26c0001

However, through testing we have found that a read-only DC rejects a TGS-REQ that contains such an encoding. By changing 
the ticket -> enc-part encoding to force this field to be encoded as:
     0x0204c26c0001

The KDC accepts this request and issues a ticket. By the way, the KDC issued a TGT with a KVNO with the value of 
0xc26c0001, and it was ASN.1 encoded as 0x0204c26c0001, which is not a legal coding for this value.

Ironically, the above quoted document makes this statement:
"It should be noted that if the TGS-REQ is malformed, e.g. Kvno encoded with more than 4 bytes, it is possible that the 
KDC discards the request without an error indication, for the purpose of mitigating a security attack."

Given the current situation, the legal range of RodcIds that will work properly with modern MIT Kerberos releases is 
0x01 - 0x7FFF. I suspect (conjecture on my part) this field is encoded in this manner because RFC 4120 states the KVNO 
field is a uint32. There isn't an "unsigned integer" encoding for integers in ASN.1. However, of you ignore the 2's 
compliment requirement for this field, and just encode it as 4 octet values as-is, I suspect this will work with the 
RODC. However, this would introduce interoperability issues, as this isn't a legal ASN.1 integer encoding for compliant 
Kerberos implementations.

I don't see a good solution for this problem. The ASN.1 standard is pretty clear that integer values are represented in 
2's compliment. You can "force" this to be encoded as an int32, which gets you closer to solution, but this still has 
problems. Should the RodcId have the high-order bit set, then this will result in a valid ASN.1 encoding of 5 bytes, 
which the above document says would be rejected.

This is exactly the failure mode we observed during testing. Only after doing extensive packet capture analysis were we 
able to determine the kvno from the AS-REP was encoded as 4 bytes (when it should have been 5) and then using that same 
encoding for the kvno in a subsequent TGS-REQ was silently rejected by the RODC KDC.

Interestingly, this problem does not reproduce using Kerberos 1.6. This is either due to the change of ASN.1 
implementation in 1.7, or the kvno from the AS-REQ is copied into the TGS-REQ as-is, and works, even though it 
technically isn't a valid ASN.1 integer in this case.

Adam
-- 



*Adam Bernstein*
Software Developer


*BeyondTrust*
15395 SE 30th Place
Bellevue, WA, 98007


425-378-7887 (Main)

425-484-8200 (Fax)