[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

windows interop


Over the course of this year we've ran into a number of interoperability 
issues between Windows and Heimdal. This message summarizes what it took 
to get Windows authentication "right." One of the reasons for writing 
this message is to "depict" backward compatibility "landscape" for 
developers to keep in mind when adopting new functionality.

W2K. Requires presence of PA-ENCTYPE-INFO structure in 
"pre-authentication required" reply with one of supported enc_type 
*first* on the list. Supported enc_types in W2K are limited to 
des-cbc-md5 and des-cbc-crc. Even though W2K can speak rc4-hmac, it 
effectively refuses to use this enc_type with foreign KDC. "Foreign" 
refers to KDC that is not known as domain controller for current domain 
W2K computer is joined to.

WXP/W2K3. It's not clear if WXP requires PA-ENCTYPE-INFO, but as it's 
apparently impossible to distinguish W2K and WXP requests, we can assume 
that it does. It was found that WXP has no problems negotiating rc4-hmac 
when talking to foreign KDC, though not to Heimdal in particular. Why is 
that? This is because WXP is willing to negotiate *unsalted* rc4-hmac 
key only, while Heimdal reports that rc4-hmac hash is salted. But is it 
really? As it turns out, the salt value in corresponding string2key, 
ARCFOUR_string_to_key to be specific, is simply disregarded. In other 
words, all rc4-hmac keys saved in key database are effectively 
*unsalted*. Note that this discrepancy was not reported earlier. There 
surely is/will be tension to address this, but then the question is how 
to approach it? Should existing database be fixed to reflect that 
rc4-hmac hashes are unsalted? Yes! I can actually confirm that omitting 
salt for rc4-hmac from PA-ENCTYPE-INFO allows WXP to use this enc_type 
and it actually works. Should new keys be generated with salt? No! This 
would break interoperability with Windows! One can generate two keys, 
with and without salt, but the sole reason for this enc_type existence 
is Windows interoperability, so why bother? In other words, [the way I 
see it] rc4-hmac should unconditionally go unsalted.

VISTASP1/W2K8. There were number of issues with this one, in particular 
with AES enc_type and referrals, both are addressed in upcoming 1.0.2. 
As far as backward compatibility goes, it's already implicitly discussed 
in my previous post with "referrals interop" subject in November, 

Cheers. A.