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

[Andrew Bartlett]

On Sun, 2007-03-25 at 22:48 -0700, Jeremy Allison wrote:
> 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 !

It's much better that what we were discussing at the CIFS conf. 

> > 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.

BTW, given that in this mode, we will need to do full GSSAPI, we will
want to avoid using the session key.  I suggest falling back to
"SystemLibraryDTC", to match other sealed transports (like DCE/RPC).

Also, how is this negotiated? 

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com
-------------- 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/20070326/1784fa1e/attachment.bin