non-ascii password in kerberos authentication

Xu Qiang Qiang.Xu at fujixerox.com
Mon Oct 22 06:16:32 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.

Ken, 

Based on your suggestions, I have successfully authenticate passwords containing 
accented characters by not converting them to UTF-8. Although they are accented 
characters, they are still in the character set ISO-8859-1, so no problem in submitting 
them unchanged.

However, if the password contains the euro symbol, which is not in ISO-8859-1, and in 
ISO-8859-9 set, it replaces the currency sign 0xA4. But in most window-based system, 
euro symbol is added as 0x80 in win-latin1 set, whereas the currency sign is still kept 
unchanged.

In this case, the authentication fails when the password is submitted to the kerberos 
server, whether they are the primitive form or converted to UTF-8 first.

Any special handling is needed for this euro symbol?

TIA,
Xu Qiang




More information about the krbdev mailing list