Hi Hongwei, > The product team confirmed that Windows servers always truncate session > keys to 16 bytes for signing. As per previous e-mail, your SMB signing has > to use entire 32 bytes of AES session key for signing. Do your newly found > bugs affect this statement ?
No, I still believe that all 32 bytes of the session key are needed. metze > Thanks ! > > Hongwei > > -----Original Message----- > From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 17, 2008 10:57 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: >> Metze, >> >> When you tested SMB signing with 32 byte AES session key, did you test >> Vista with Samba server , Samba client with Windows server or both ? > > Samba as client and Windows 2008 as server. > > I found a few bugs in Samba's smb signing implementation. > > Windows only signs the last session setup response and samba also signs the > last session setup request. > > I have some hacks which fix samba, but I haven't done a clean implementation > yet. > > The key thing is that the client needs to process the last session setup > response first and then verify its signature after when the correct session > key is avaliable. > > metze > >> >> -----Original Message----- >> From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] >> Sent: Friday, September 05, 2008 3:25 PM >> 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: >>> 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. >> I got it working, the session key isn't truncated for the SMB signing. >> >> The problem was that we reseted the sequence number when updating the >> session key from the initiator subkey to the acceptor subkey between the >> session setup request and response. >> >> Also windows signs the response with the acceptor subkey, so that the client >> needs to check the signature after processing the response. >> >> metze >> > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
