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