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

[John Dunning]

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

Thanks
John

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Friday, August 08, 2008 7:28 PM
To: John Dunning
Cc: cifs-protocol at samba.org; pfif at tridgell.net
Subject: Re: Regarding String2key for random trust keys ([MS-ADTS] 7.1.6.8.1.2)

On Fri, 2008-08-08 at 08:48 -0700, John Dunning wrote:
> Hello Andrew,
>
>     I received feedback from our Product team and they have some
> questions to help in clarification.
>
>
>
> Your original question:
>
>
>
> "In MS-ADTS 7.1.6.8.1.2, it states:
>
>
>
> This flag indicates that the information stored in the attribute is a
> Unicode plaintext password. If this auth type is present, Kerberos can
> then use this password to derive additional key types needed to
> encrypt and decrypt cross realm TGTs:
>
>
>
>     DES-CBC [RFC4120] section 8.1
>
>     DES-CRC [RFC4120]
>
>     RC4HMAC [RFC4757]
>
>
>
> Other derivations of the plaintext password are possible using string
> to key functionality defined in [RFC3961].
>
>
>
> However, it is not stated here or in MS-KILE how to translate between
> the 'Unicode' strings used in windows trusts (for example, see the
> trustAuthIncoming, decrypted and decoded, between two of my domains)
> and the expected input encoding for AES and other non-MD4 keys.
>
>
>
> Converting these from UTF16 to UTF8 (I'm assuming this is the intended
> translation) fails as the randomly created string cannot be translated
> into UTF8."
>
>
>
> Questions from the Product team:
>
>
>
> 1.       Does the Unicode strings in the request only refer to the
> plaintext password as the section referred to indicated?

It refers to any unicode string expected to be used as a kerberos key,
but the particular example of the string found in trustAuthIncoming is a
particular problem (as this is the first example I have found of purely
random strings being used).

> 2.       What does the "translation" refer to? Does it mean how the
> password is used in the hash function?

How a UTF16 password is converted into the input expected for the
string2key functions listed above.

> 3.       What section does the example refer to and how is it related?

These are decoded trustAuthIncoming blobs, obtained by DRSUAPI
replication.

> 4.       What makes AES and non-MD4 keys stand out on the expected
> input encoding in this request?

the arcfour-hmac-md5 string2key function is defined as
md4(unicode-UTF16(password)), and therefore no conversion of character
set is required (as we already have the UTF16 password).

No definition has currently been provided for preparing the UTF16
strings into the input expected for other string2key functions.

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