Key derivation with non-ASCII characters

[Frank Taylor]

> Careful here.  The crypto document does require the use of UTF-8 encoding.
> However, in the updated specification (as in RFC1510), these strings are 
> actually restricted to 7-bit US-ASCII.  Implementations which use non-ASCII 
> characters (and most do) violate RFC1510.

I stand corrected. Indeed the UTF-8 mention is the in the crypto
draft. What status does this now have given that it has just expired?
The Kerberos clarification doc references the crypto draft for the
definition of the string_to_key function (and its expected input).

> Sam has explained what the existing (pre-kerberos-clarifications) Microsoft 
> implemenetation will actually do -- it will expect you to encode all 
> strings as UTF-8, and does not perform any normalization.

So, given that I can use UTF-8 password/salt I should get the right
values for MS AD... unfortunately I still don't get the right key.

Using ktpass on a windows machine I can generate the right key for the
account. If I hardwire that into my client code I can authenticate.
This implies that the client is choosing a valid enctype (DES-CBC-CRC)
and the AD supports this type and the related key.

This leaves two things (more?) that could go wrong... the
string_to_key code, or AD is using an alternative salt for passwords
with non-US-ASCII characters (possible?).

Note: the code works fine when the password consists of the only
US-ASCII characters. Also, I have verified the code with sample values
in the crypto draft (including the samples that use Unicode
characters). So I think the implementation is OK.

Thanks for the help so far... it is slowly becoming clearer!

Frank.