[cifs-protocol] RE: Regarding [MS-KILE] 3.4.5.1 Three-Leg DCE-Style Mutual Authentication
Hello Andrew, Do you have any new status for this? Have you determined if this is still a problem for you? Thanks John -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2008 9:03 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; John Dunning Subject: RE: Regarding [MS-KILE] 3.4.5.1 Three-Leg DCE-Style Mutual Authentication On Fri, 2008-08-08 at 11:07 -0700, John Dunning wrote: Hello Andrew, I've received feedback from the Product team and they are requesting additional clarification. To start with I would like to insure we understand the issue. We understand the problem to be the following, please let me know if this is not correct. The behavior SAMBA is seeing is Client authenticates to Server using KILE and the following occurs: 1. Client sends RFC std AP_REQ to server 2. Server sends RFC std AP_REP to client in this message the sequence number is n 3. Client sends AP_Rep to server in this message the sequence number is n in XP and n+1 in Vista only when AES is used Metze: You seemed to finally get this all working, was the sequence number a red herring, or did we still need a special case there? Please clarify what GSSAPI you are using. From the Product team's investigation they don't see a difference in behavior with AES. They are also requesting possible repro steps and Kerberos logs. We use a patched version of Heimdal. Having Vista join Samba4 is the base case we were working on, but metze will be able to clarify the current status. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] Session keys are not always 16 bytes long
Stefan, For your SMB signing problem shown in the network traces attached, what is your configuration ? Are you using Vista client connecting to Samba server and KDC ?You also mentioned windows servers. How are they used in your configuration ? I just want to make sure we check the correct section of the code and create a testing environment that will be more helpful for finding the problem. Thanks! Hongwei -Original Message- From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2008 10:36 AM To: Hongwei Sun Cc: Andrew Bartlett; [EMAIL PROTECTED]; [EMAIL PROTECTED] 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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
