non-ascii password in kerberos authentication

[Xu Qiang]

> -----Original Message-----
> From: Ken Raeburn [mailto:raeburn at MIT.EDU]
> Sent: Saturday, September 15, 2007 5:45 AM
> To: Paul Moore
> Cc: Xu Qiang; krbdev at mit.edu
> Subject: Re: non-ascii password in kerberos authentication
> 
> 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.

Ken, you say "MIT code just alternates bytes from the input string with zero bytes", 
so if the input string is "0xAB 0x12", then MIT will change the byte sequence to 
"0xAB 0x00 0x12 0x00". Is my understanding correct?

If this is the case, i think i can just drop the "0x0" part in the resulting byte
sequence of my conversion to UCS-2LE.
 
> 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.