[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
windows interop
Hi,
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,
http://www.stacken.kth.se/lists/heimdal-discuss/2007-11/msg00030.html.
Cheers. A.