[cifs-protocol] RE: Regarding String2key for random trust keys ([MS-ADTS] 7.1.6.8.1.2)

[Andrew Bartlett]

On Tue, 2008-08-19 at 22:30 +1000, Andrew Bartlett wrote:
> On Tue, 2008-08-19 at 14:48 +1000, Andrew Bartlett wrote:
> > On Fri, 2008-08-15 at 09:32 -0700, John Dunning wrote:
> > > Hello Andrew,
> > >     I wanted to ask you if you have taken a look at Section 3 of RFC
> > > 3629 which may be of help for this problem. 
> > 
> > Is that the expected target string format for string2key operations?
> > 
> > > If you have and it didn't help then we need to get more information on
> > > how you are actually doing the conversion. For example are you using
> > > your own function or a canned one?
> > 
> > We use our own implementation of iconv() for the UTF16 -> UTF8
> > translations.
> > 
> > http://gitweb.samba.org/?p=samba.git;a=blob;f=source/lib/charset/iconv.c;h=4f4bc8fd2da70c9f9d5bb75b2ee0f946516c996a;hb=v4-0-test#l589
> > 
> > It (rightly) rejects the random data as not being valid UTF16 input.  
> > 
> > As far as I can tell, it is not possible for random bytes to simply be
> > described as UTF16 (and then converted to another charset), so I suspect
> > we will need a filter or modified function.
> 
> Talking with tridge about this problem, perhaps the problem is that
> these buffers are not really 'Unicode' (by the convention of this
> document, ie UTF-16).  If the buffers were instead UCS2 and rules about
> illegal and reserved ranges were ignored, then the standard UTF8 Huffman
> encoding were applied, would this result in the same UTF8 string as
> Micorsoft uses for it's input into the AES and DES string2key functions?
> 
> For reference, MS-ADTS 7.1.6.8.1.1 describes it this way:
> 
> TRUST_AUTH_TYPE_CLEAR AuthInfo byte field contains a cleartext password,
> encoded as a Unicode string.

I just wanted to try and see where this has got to, as I've not seen any
communication on the issue for over a month.  This is currently one of
my two top priority issues, along with the failure to join trusted
domain.

The problem is that if Microsoft treats this buffer as 'UCS2' when
converting to UTF8 (for kerberos keys), then any random buffer is valid
input.  However, where that buffer to contain UTF16 sequences (as typed
by a user as a password), it would not map to the correct UTF8 sequence
for conversion into the kerberos key.  

Similarly, if the buffer is UTF16, then what should we do when windows
machines set a random stream of bytes as the password?

This is a critical interopability issue, as AES keys become more used.  

Similarly, this affects the creation of ARCFOUR keys from UTF8 input on
non-windows machines (should the characters be expanded to UCS2 or UTF16
prior to the MD4?)

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20080923/e07e0f07/attachment.bin