[cifs-protocol] SMB2 Session/Signing Key with NTLMv2 + SPNEGO

[Brad Fewster]

Hi everyone,

First off, I'm new to the list so excuse me if my mailing list etiquette is
not quite up to par.

I have a few questions regarding SMB2 and signing that I'm hoping someone
here can help me with.  Note that I'm only concerned with the client, not
the server, so all of my questions fall within the context of an SMB2
client.

Also I've done ALOT of reading of internet sources, Samba code, and MS
documentation which has left me in a thoroughly confused state as to which
methodologies apply to SMB, SMB2, NTLMv1, and NTLMv2.

My apologies if this isn't the right place for NTLM questions, but I am not
sure where else to ask since this is apparently directly related to the
SMB2 signing key.


Question 1: Signing Key Format with NTLMv2

I'm looking at a connection in which the session setup is occurring (with
regard to packet layout) using NTLMv2 inside NTLMSSP inside SPNEGO inside
GSS-API.

What I'd like to know is what exactly is used as the "session key" to sign
SMB2 packets?  I am confused by the signing key information contained
within [MS-NLMP] with regard to signing and sealing keys, some resources
seem to indicate that that has no bearing on the SMB signing key, but I'm
not sure that applies to SMB and/or SMB2 as the lines seem to be a bit
blurred.

The current routine I'm using to generate the key used to sign SMB2 packets
per [MS-SMB2] section 3.1.4.1 is:
  username = ASCIIZ username (i.e. "brad")
  domain = ASCIIZ target domain (typically the hostname from the
NTLMSSP_CHALLENGE, i.e. "WIN7-X64-01")
  password = ASCIIZ password (i.e. "secret")
  server_challenge = 8-byte challenge received from the server (from
NTLMSSP_CHALLENGE's NTLM Server Challenge field)
  client_challenge = random 8-byte nonce (generated by me)
  target_info = "target info" block from NTLMSSP_CHALLENGE from server
  v1Hash = MD4(UNICODE_LE(password))  [ as per heim_ntlm_nt_key ] (16 bytes)
  v2Hash = HMAC_MD5(UNICODE_LE(username)+UNICODE_LE(domain)) using all
16bytes of v1Hash as key
  ntlmv2_response = all but the first 16 bytes of the response that I am
SENDING to the client
  hmac = HMAC_MD5(ntlmv2_response) using all 16 bytes of v2Hash as the key
  signingKey = HMAC_MD5(v2Hash) using all 16 bytes of 'hmac' as the session
key

This isn't working for signing - my Windows 7 x64 Ultimate box rejects
packets signed using the above signingKey.  Simply an ACCESS_DENIED error
is returned; if I disable signing then the commands work so it's not a
legitimate permissions problem.  I've gone over the actual signing code
many times, which is simple compared to the NTLMv2 negotiation.  I'm
confident the signing code is OK and the key above is incorrect.

Authentication for NTLMv2 is woking correctly, so I also have access to all
of the various artifacts of that process.

I think I've gotten lost somewhere in the mountain of hashes and different
signing keys.  Does SMBv2 require some of the "magic signing keys" to be
used as documented in [MS-NLMP] to derive it's signing keys?  Various
scraping of information on the interwebs leads me to believe 'no', but I
can't be 100% certain.

Various other permutations have been tries using assorted keys from the
NTLMv2 process, the server and client challenge's, magic signing keys from
[MS-NLMP], etc to no avail.

BTW, the flags I'm using in my NTLMSSP_NEGOTIATE are 0x60088215 and the
ones returned by the server are 0x628a8215.



Question 2: Signing Key Retention

Assuming that Q1 is answered and I'm able to obtain the proper signing key
for SMB2 packets, is the key used to set the 'signature' field in the SMB2
header retained across SessionSetup/Logoff instances?

This appears to be the case in SMB1 and looking at [MS-SMB2] in section
3.2.5.3.2 it reads "The client MUST NOT regenerate Session.SessionKey.".  I
read this to mean that SMB2 behaves like SMB1 in that if a session key is
established during the initial SessionSetup exchange that it will remain
unchanged even if a Logoff is processed followed by another SessionSetup.



Thanks for anyone who can help,
B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20130220/39b6aca0/attachment.html>