non-ascii password in kerberos authentication

Xu Qiang Qiang.Xu at fujixerox.com
Sun Sep 16 23:33:28 EDT 2007


> -----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.

Yes, Ken. Just as you guess, the cryptosystem is RC4. And when 
we find input password is ASCII or ISO-8859-1, we convert it to UTF-8. 
>From your explanation, the failure is expected, coz what Windows wants is 
UCS-2LE format, right?
 
> 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).

Yes, the algorithm to encode both principal name and password is the same, 
with the purpose to convert chars from ASCII to UTF-8.
  
> 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.

Unfortunately, it is RC4. 

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

Is there any walk-around in this scenario? Or there is no way at present to 
authenticate a password with non-ASCII password against Windows Kerberos 
server?

Thanks a lot for your analysis,
Xu Qiang




More information about the krbdev mailing list