NTLM authentication with NTLM2 session security

[Andrew Bartlett]

On Wed, 2003-07-30 at 23:13, eglass1 at comcast.net wrote:
> Hello,
> 
> I work with Chris Hertel and Michael Allen on the jCIFS project.  As a sidebar
> to this, I have been putting together documentation on NTLM authentication:
> 
> http://davenport.sourceforge.net/ntlm.html
> 
> I just figured out something that had been confounding me for awhile, and I
> hadn't found this documented anywhere, so I figured I'd post it here
> (as well as adding it to my own documentation).  For all I know this could
> be well-known information that I just wasn't able to locate, so I apologize
> in advance if this is the case.
> 
> When the client and server have agreed upon the "Negotiate NTLM2 Key"
> NTLMSSP flag (0x00080000), but LMCompatibilityLevel is set to 0 (i.e., *not*
> using NTLMv2 authentication), the LM and NTLM responses in the Type 3 messages
> are changed as follows:
> 
> The LM Response contains an 8-byte client nonce, null-padded to 24 bytes.
> 
> The NTLM response is still calculated "normally" (i.e., using keys derived
> from the NT hash to DES-encrypt a value three times); but instead of encrypting
> the server challenge, it uses:
> 
> head(MD5(challenge + nonce), 8)
> 
> That is, it concatenates the server challenge with the 8-byte client nonce from
> the LM response, takes the MD5 digest, and uses the first 8 bytes of the result
> as the data in the encryption operation.
> 
> The intent of this is presumed to be prevention against server-based
> precomputed dictionary attacks on the NTLM response (similar to the LMv2
> response).

This is *very* interesting news!  

I'll get this coded into Samba as soon as I get a chance.   What we need
to know is:

What challenge is sent to the DC over the netlogon pipe?  Is it the
challenge that the server sent, or the result of the MD5 calculation? 

Also, does it change the session key that is generated?  (One would hope
so, but that could be the sticking point in implementing on all of
this).

With all these recent advances, Samba 3.0 is taking massive leaps in
network security protocols over what Samba 2.2 could support, and I
think that is just great!

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030730/9bcef345/attachment.bin