"Greg Hudson via RT" writes: > Here is what we know right now: > > 1. If you use a keyed checksum with RC4 keys and an authenticator subkey > in a TGS request, AD 2003 verifies the checksum using the subkey. It > turns out that RFC 4120 doesn't specify what key to use for AP-REQ > checksums, but Heimdal and MIT use the TGS session key. RFC 4757 > (Microsoft's own informational RFC about RC4-HMAC) says to use the TGS > session key, so MS is in conflict with its own documentation if not with > the binding standards. > > What we don't yet know for sure is whether this problem affects AES. We > need to find that out to know the appropriate scope of the fix. If the > problem affects only RC4, then the appropriate answer is probably "don't > use keyed checksums with RC4, it hurts." If the problem affects AES as > well, then it gets more involved. Confirmed that the keyed checksum problem does not appear on Windows Server 2008 SP1 with AES-256 keys. Also, the RC4 keyed checksum failure does not occur on Windows Server 2008 SP1, so I can infer that Microsoft considered it to be a bug and fixed it on Windows Server 2008 SP1 (or maybe even before SP1). > 2. RFC 4757 erroneously documents a key usage of 8 for a TGS-REP > encrypted part authenticated with a subkey; the value used by MS is > actually 9. Unfortunately, Heimdal and MIT both implement what is > documented. This means you can't interoperate with both {Heimdal or MIT > 1.6} and AD with RC4 TGS subkeys using a single key usage value. It's > easy enough to try both when decrypting the response, however. > > Sam has committed a change to switch from 8 to 9, fixing TGS RC4 subkey > interoperability with MS but breaking it with Heimdal and MIT 1.6. We > will need to amend this to try both usage values. Confirmed that Windows Server 2008 SP1 appears to use key usage 9 for TGS-REP encrypted part with RC4. (Fails before r22355 change, succeeds with r22355.)