Jeremy requested that I get my NTLMSSP patch into CVS. He didn't request

the schannel code, but I've included that anyway. :-)

This patch revives the client-side NTLMSSP support for RPC named pipes
in Samba, and cleans up the client and server schannel code.  The use of the
new code is enabled by the 'sign', 'seal' and 'schannel' commands in
rpcclient.

The aim was to prove that our separate NTLMSSP client library actually
implements NTLMSSP signing and sealing as per Microsoft's NTLMv1 implementation,
in the hope that knowing this will assist us in correctly implementing
NTLMSSP signing for SMB packets.  (Still not yet functional)

This patch replaces the NTLMSSP implementation in rpc_client/cli_pipe.c with
calls to libsmb/ntlmssp.c.  In the process, we have gained the ability to
use the more secure NT password, and the ability to sign-only, instead of
having to seal the pipe connection.  (Previously we were limited to sealing,
and could only use the LM-password derived key).

Our new client-side NTLMSSP code also needed alteration to cope with our
comparatively simple server-side implementation.  A future step is to replace
it with calls to the same NTLMSSP library.

Also included in this patch is the schannel 'sign only' patch I submitted to
the team earlier.  While not enabled (and not functional, at this stage) the
work in this patch makes the code paths *much* easier to follow.  I have also
included similar hooks in rpccleint to allow the use of schannel on *any* pipe.

rpcclient now defaults to not using schannel (or any other extra per-pipe
authenticiation) for any connection.  The 'schannel' command enables schannel
for all pipes until disabled.

This code is also much more secure than the previous code, as changes to our
cli_pipe routines ensure that the authentication footer cannot be removed
by an attacker, and more error states are correctly handled.

(The same needs to be done to our server)

Andrew Bartlett
(This used to be commit 5472ddc9eaf4e79c5b2e1c8ee8c7f190dc285f19)

1 files changed, 31 insertions, 0 deletions

diff --git a/source3/libsmb/smbencrypt.c b/source3/libsmb/smbencrypt.c
index c1b3880299..7a1a2d7d18 100644
--- a/source3/libsmb/smbencrypt.c
+++ b/source3/libsmb/smbencrypt.c
@@ -271,6 +271,8 @@ void SMBOWFencrypt_ntv2(const uchar kr[16],
 void SMBsesskeygen_ntv2(const uchar kr[16],
 			const uchar * nt_resp, uint8 sess_key[16])
 {
+	/* a very nice, 128 bit, variable session key */
+	
 	HMACMD5Context ctx;
 
 	hmac_md5_init_limK_to_64(kr, 16, &ctx);
@@ -286,6 +288,9 @@ void SMBsesskeygen_ntv2(const uchar kr[16],
 void SMBsesskeygen_ntv1(const uchar kr[16],
 			const uchar * nt_resp, uint8 sess_key[16])
 {
+	/* yes, this session key does not change - yes, this 
+	   is a problem - but it is 128 bits */
+	
 	mdfour((unsigned char *)sess_key, kr, 16);
 
 #ifdef DEBUG_PASSWORD
@@ -294,6 +299,32 @@ void SMBsesskeygen_ntv1(const uchar kr[16],
 #endif
 }
 
+void SMBsesskeygen_lmv1(const uchar lm_hash[16],
+			const uchar lm_resp[24], /* only uses 8 */ 
+			uint8 sess_key[16])
+{
+	/* Calculate the LM session key (effective length 40 bits,
+	   but changes with each session) */
+
+	uchar p24[24];
+	uchar partial_lm_hash[16];
+	
+	memcpy(partial_lm_hash, lm_hash, 8);
+	memset(partial_lm_hash + 8, 0xbd, 8);    
+
+	SMBOWFencrypt(lm_hash, lm_resp, p24);
+	
+	memcpy(sess_key, p24, 16);
+	sess_key[5] = 0xe5;
+	sess_key[6] = 0x38;
+	sess_key[7] = 0xb0;
+
+#ifdef DEBUG_PASSWORD
+	DEBUG(100, ("SMBsesskeygen_lmv1:\n"));
+	dump_data(100, sess_key, 16);
+#endif
+}
+
 DATA_BLOB NTLMv2_generate_names_blob(const char *hostname, 
 				     const char *domain)
 {