non-ascii password in kerberos authentication

[Paul Moore]

3961 may say but 1510 does not. 

Of course this may not be the original emailer's problem. 

-----Original Message-----
From: Ken Raeburn [mailto:raeburn at MIT.EDU] 
Sent: Friday, September 14, 2007 2:45 PM
To: Paul Moore
Cc: Xu Qiang; krbdev at mit.edu
Subject: Re: non-ascii password in kerberos authentication

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