[PATCH] NTLMSSP client updates (RPC pipes)

[Andrew Bartlett]

On Mon, Jul 14, 2003 at 12:21:29PM +1000, Tim Potter wrote:
> On Sun, Jul 13, 2003 at 05:50:01AM +0000, Andrew Bartlett wrote:
> 
> > This patch revives the client-side NTLMSSP support for RPC named pipes
> > in Samba.  Currently enabled by the 'sign' and 'seal' commands in 
> > rpcclient, this code is the result of a research effort on my part.
> >
> > The hope is that knowing this will assist us in correctly implementing 
> > NTLMSSP signing for SMB packets.
> > 
> > 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, but not seal, 
> > the pipe connection.  (Previously we were limited to sealing with the 
> > LM-password derived key).
> 
> Very nice!  As you may have discovered the various cryptographic bits
> and pieces are a collection of if statements.  Have you seen the way
> TNG has cleaned this up using the table of function pointers pattern?

I looked at that, and even considered bringing the code across - but 
I'm not sure I like the layer that was chosen.  Once I get this in, I'll
certainly look at it again.  (And I'll probably change the 'auth flags'
into a generic structure, rather than a bitmask)

> Ethereal is supposed to decode ntlmssp sign and seal over RPC.  The
> signing seemed to work OK (not sure whether the signature was checked
> against the data) but I couldn't get sealing working, even after hacking
> the client code to negotiate LM keys.  I doubt that NTLM keys are 
> supported.
> 
> It would be nice to be able to specify client side LM or NT here to
> facilitate testing the different signing methods.

I'll see about adding some rpcclient commands for that.

> > 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.
> 
> Heh.
> 
> > (The same needs to be done to our server)
> 
> Yes.
> 
> > +/* Generic flags to indicate signing or sealing of an RPC pipe */
> > +#define RPC_PIPE_AUTH_SIGN_LEVEL 0x5
> > +#define RPC_PIPE_AUTH_SEAL_LEVEL 0x6
> 
> These are actually the values used in the DCERPC header for the
> auth level field - packet integrity and packet privacy, respectively.
> They're not flags.

Yes (and I am using them like that) - I'll update the comment.

> > -void string_replace(char *s,char oldc,char newc)
> > +void string_replace(pstring s,char oldc,char newc)
> >  {
> >  	push_ucs2(NULL, tmpbuf,s, sizeof(tmpbuf), STR_TERMINATE);
> >  	string_replace_w(tmpbuf, UCS2_CHAR(oldc), UCS2_CHAR(newc));
> 
> Er, should this be a separate fix applied to 3.0?

Yes.  (it's just documentation)

Andrew Bartlett