non-ascii password in kerberos authentication

[Ken Raeburn]

On Sep 14, 2007, at 17:13, Paul Moore wrote:
> DES or HMAC?
>
> DES does not define the password behaviour for non-ascii, MSFT has  
> implemented in such a way that it is basically impossible to  
> interop with (they translate the the unicode to an OEM 8 bit char  
> set, but which one they use depends on the the language pack in use  
> on the DC - which you cannot discover remotely)
>
> HMAC does define the non-ascii behaviour so it should be OK (in my  
> experience)

Actually, the RFC 3961 spec for converting passwords to keys does  
indicate what should be done with non-ASCII input -- it's supposed to  
be passed in as UTF-8, and then the same algorithm is applied to the  
byte sequence.  The MIT code just uses whatever is passed to it.  It  
won't transform local 8-bit encodings to UTF-8, but if your input is  
already UTF-8, you may win there.

However, the RC4 cryptosystem spec (RFC 4757) wants the password  
converted to UCS-2LE (like UTF-16LE but limited to 0..65535), and the  
MIT code just alternates bytes from the input string with zero bytes,  
which is correct for ASCII or ISO-8859-1 input, but other input,  
including in UTF-8 form, won't be converted properly.

At a glance, it looked like the problematic characters were in the  
ISO-8859-1 set.  And given that they worked in the principal name, I  
expect the input encoding was probably UTF-8 (and I'm assuming it  
would be the same encoding for both principal name and password).  So  
I'd guess it's RC4, and Windows is properly converting to UCS-2LE,  
and MIT is not.  Or, if it's DES, perhaps Windows is doing the wrong  
thing with non-ASCII passwords.

UTF-8 or locale support is probably going to need some serious API  
changes, and some serious thought about the transition problems.

Ken