non-ascii password in kerberos authentication

[Ken Raeburn]

On Sep 16, 2007, at 23:33, Xu Qiang wrote:
> 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?

Yes.

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

I can think of some workarounds, none especially pretty.

* If your initial attempt with a UTF-8 password fails, convert it to  
UCS-2LE and try again.  This would result in doubled queries to the  
KDC, and if preauth is used, would report the first attempt as a bad  
password or equivalent.  This could be problematic for auditing  
purposes or if bad passwords can cause accounts to be locked out.

* If you can be sure that RC4 is being used, convert to UCS-2LE  
before calling into the library in the first place.

* Modify the MIT code you're using to be aware that you're always  
passing in UTF-8, and in the RC4 string-to-key code, always convert  
to UCS-2LE.  Because of the transition issues and possible existing  
deployments using other approaches, I'm not sure if we would be able  
to incorporate a patch for this, but we can discuss it.  I think it  
would get the job done for you, though.

* Modify the MIT code at a slightly higher level, to first try the  
password as passed in, and if it fails (and, maybe, if RC4 is the  
encryption type), run it through a UTF-8-to-UCS-2LE conversion and  
try again if the conversion works.  With preauth, this has the same  
bad-password problem as described above.

Do any of these sound helpful?

Ken