krb5 commit: Modernize UTF-8/UCS-2 conversion code

[Stefan Metzmacher]

Am 25.04.2017 um 19:31 schrieb Simo Sorce:
> On Tue, 2017-04-18 at 10:32 +0200, Stefan Metzmacher wrote:
>> Am 17.04.2017 um 21:53 schrieb Greg Hudson:
>>> On 04/17/2017 03:24 PM, Stefan Metzmacher wrote:
>>>> is there a reson why you still limit this to USC-2 and not use full UTF16
>>>> support?
>>>
>>> This commit was just trying to eliminate warnings, not change the
>>> functionality.
>>
>> Ok, "Modernize UTF-8/UCS-2 conversion code" indicated a more or less
>> rewrite of the code to me. As it's not you may just ignore this topic
>> for now.
>>
>>> This code originally came from OpenLDAP's utf-8-conv.c, and was
>>> incorporated with the goal of Windows compatibility (for PACs and RC4
>>> string-to-key).  If Windows now supports UTF-16 then we could consider
>>> extending it, but I wouldn't want to do so without confirmation of that.
>>
>> I think Windows always supported UTF-16 instead of USC-2, at least it
>> did for the last 10 years (at least for passwords).
>>
>>>> We had a lot of trouble with the limited unicode support of krb5 libraries
>>>> in Samba recently, see https://bugzilla.samba.org/show_bug.cgi?id=12262
>>
>> The core of the problem is that Windows uses an random buffer as machine
>> password,
>> and interprets it as UTF16 (which is not always valid UTF-16).
>> The MD4 of the raw buffer is the NTHASH/RC4-key.
> 
> Would it make sense to provide an alternative interface to calculate the
> RC4-key that takes a random buffer instead of utf-8, so we do not have
> to deal with awkward conversions or restricting how we generate this
> buffer ?

I think using a client side keytab is the way to avoid the conversation.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20170426/af44d841/attachment.bin