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

[Jeremy Allison]

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.

> Of course, in the Kerberos case it mandates access
> to the underlying session key, something the MIT
> developers (at least) have been reluctant to expose
> at the API layer.

For the krb5 case I'm just going to call into the 
system provided gss_seal/gss_unseal entry points
and let that level sort it out :-). So for the
krb5 gss encryption case it'll probably only sign the
payload, not the header as there's no way to
tell gss to sign a different part of the packet
than it seals.

But as we'll just drop the connection on detecting
tampering anyway I don't see this as being too
much of a problem.

Jeremy.