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

[Andrew Bartlett]

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

-------------- 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/20080809/3c45b309/attachment.bin