[cifs-protocol] Session keys are not always 16 bytes long

[Hongwei Sun]

Metze/Andrew,

  The subkey in the EncAPRepPart of the AP-REP should be used as the session key when the mutual authentication is enabled(as described in RFC 4121).    When DES and RC4 are used in Kerberos, the implementation is based on RFC1964 (instead of RFC4121).  According to RFC1964, you can pick the subkey in AP_REQ as the session key as it is the same as the subkey in AP_REP, but this is not true when AES is used because both subkeys are different (again AES means RFC4121 being used, not RFC1964).       This explains what you observed.   We will add the information to [MS-KILE] to describe how the session key is selected.

   The session key returned from  Kerberos package can be used for SMB signing as described in the section 4.3 of  [MS-SMB].  You have to truncate the keys to 128 bits in your code  because SMB does the truncation on the windows side.

   I ran the similar testing as you did.  I had one Vista machine connected to Windows 2008 DC/KDC and configured AES256-CTS-HMAC-SHA1-96 as Kerberos encryption type with mutual authentication enabled.  I cannot duplicate your SMB signing problem(see the network capture attached). It is working between Windows servers and clients.


Thanks

----------------------------------------------------------
Hongwei  Sun - Sr. Support Escalation Engineer
DSC Protocol  Team, Microsoft
hongweis at microsoft.com
Tel:  469-7757027 x 57027
-----------------------------------------------------------


-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze at samba.org]
Sent: Thursday, August 14, 2008 10:36 AM
To: Hongwei Sun
Cc: Andrew Bartlett; pfif at tridgell.net; cifs-protocol at samba.org
Subject: Re: [cifs-protocol] Session keys are not always 16 bytes long

Hongwei Sun schrieb:
> Stefan,
>
>>> I just found that the session key used to decrypt the password attributes in the DsGetNCChanges() is not truncated.
>
>   Do you have network trace for this case ?

See the attached capture and keytab.

>>> And I need to use gsskrb5_get_subkey() instead of gsskrb5_get_initiator_subkey(), when aes keys are used.
>
>   Does this happen only when you use AES keys

Yes, as for AES the acceptor subkey is different from the initiator one.
Windows servers seem to just use the same subkey as acceptor subkey and the inititor subkey for rc4 and des keys.

For me the remaining unsolved problem is smb signing with AES keys.
If I disable mutual auth is works using the initiator subkey, but if mutual auth is used I'm getting a NT_STATUS_ACCESS_DENIED on the tree connect after the session setup. Both initiator and acceptor subkey doesn't work. And truncating the session key to 16 bytes also doesn't help. I attached 2 capture of it.

SMB2 signing works fine with the 32byte acceptor subkey.

Could it be a bug in windows? Or does smb signing works for you with AES keys and mutual auth?

metze
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AESSinging.cap
Type: application/octet-stream
Size: 17994 bytes
Desc: AESSinging.cap
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20080905/a5e0249c/AESSinging-0001.obj