[linux-cifs-client] signature generation of ntlm (ntlmssp spnego) incorrect in cifs client?

[Shirish Pargaonkar]

I sure could use some pointers/suggestions.  I am implementing ntlm
mechanism in ntlmssp spnego
in cifs client and almost there but just can't get past the error
NT_STATUS_ACCESS_DENIED
on a tree connect andx request (session setup andx succeeds).

I am suspecting Windows server does not like the signatures.

But the same singature calculation function works fine with ntlm,
ntlmv2, and kerberos
mechanisms with packet signing in cifs against Samba as well as
Windows servers and
yet it (apparently) fails with ntlm in ntlmssp spnego against Windows servers.
With the same signature calcuation function, cifs client succesfully can mount a
Samba share using ntlm mechanism within ntlmssp spnego negotiation
with packet signing ON.

Even though the calculated signature could_be/is wrong (because I do
get signature mismatch
during the comparison of signature sent by the server and the
signature cifs generates on response to
 session setup andx (negTokenResp (ntlmssp-auth)), but somehow Winodws
2003 server allows upto
 session setup andx (negTokenResp (ntlmssp_auth)) request/response but
not beyond.
Apparently Samba server is lenient, it allows mismatches or
mis-signatures as tree connect andx succeeds.
I tried resetting sequene number before sending session setup andx
(negTokenResp (ntlmssp_auth))  request
but that did not help.

To calculate signature, cifs has been using md5 hash of concatenated
mac key (for ntlm) and payload
(cifs_calculate_signature() function).  That is working for all the
security mechanisms with
packet/smb signing except for the ntlmssp.

I looked at smbclient but smbclient does not do tree connect andx.  I
also incorporated what it does
to calculate signature i.e. md5 hash of concatenated mac key, payload
before sequnce number,
sequence number, and payload after sequence number in cifs and that
did not help.
I also incorporated cifs signature calculation in smbclient and it
fails (I guess as expected) to connect
to the Windows 2003 share, so I strongly suspect signature is
calculated incorrctly but the same
function works for other mechanisms with packet signing, which is very puzzling.

Any pointers/suggestions are really appreciated.

Regards,

Shirish