svn commit: samba r21903 - in branches/SAMBA_3_0/source/libsmb: .

[Jeremy Allison]

On Mon, Mar 26, 2007 at 01:21:30PM +1000, Andrew Bartlett wrote:
> On Tue, 2007-03-20 at 21:34 -0700, Jeremy Allison wrote:
> > On Wed, Mar 21, 2007 at 03:27:17PM +1100, Luke Howard wrote:
> > > 
> > > I'd love to see/review the spec.
> > 
> > I'll definately include you.
> > 
> > > Are you going to
> > > keep the SMB signature even if you use GSS
> > > encryption? This could be a cheap way to get AEAD
> > > (integrity protecting the entire PDU whilst only
> > > encrypting the payload).
> > 
> > I wasn't planning to. In fact the current code
> > turns off the SMB signature once you've got
> > the transport encryption on. Current SMB
> > signatures have lots of problems as they're
> > mid-based, so the current server encryption
> > code (the NTLM base) insists on sign+seal
> > (the same way it's done on RPC packets)
> > and will drop the connection if you try
> > and NTLMSSP negotiate anything less than
> > sign+seal at the transport layer.
> > 
> > Currently the signature is done over the
> > <len>0xFF SMB header + entire packet, whereas the
> > encryption is only done on the part of
> > the payload following the <len>0xFF SMB
> > header.
> 
> That sounds almost sane...

Why thankyou !

> I presume this is strictly one NTLM packet per SMB request?

Yep.

> Given this much is being encrypted, I would have preferred the way SASL
> does things, which is <len><<sig><blob>>, where <sig><blob> is defined
> by the encryption mech.  (And encrypted packets may or may not line up
> with underlying packets).

It's essentially <len><blob><sig>. I think that's cleaner as it allows
in-place enc. then adding the blob at the end. Note that <len> isn't
signed.

> But I hope to work with you to get Samba4 compatible with this, it
> shouldn't be hard at all.

Indeed, the main effort (once I've finished the gss and gss-spnego
setup) is to get as many clients done as possible.

Jeremy.