PGP SIGNED MESSAGE
Hash: SHA1
Hi Andrew, Jeremy and Steve,
I haven't followed your discussion in detail yesterday, but this morning
I thought a bit about the problem while I couldn't sleep anymore:-)
First I think we should learn from what we have learned about SMB2:
1.) TreeConnects are only valid on the UserSessions that creates them.
2.) SMB2 signing depends on the UserSession.
Then I'm with Andrew that we should use a standard framing for the
encryption, but I think the comparing with LDAP seems wrong to me
as LDAP can only have one UserSession at a time!
So I think DCERPC would much better match what we need, as it also
allows multiple contexts and the DCERPC header is always transmited
unencrypted and only the payload is encrypted, but the signature also
takes the header in account.
I think we should implement something like this:
1.) create a new SMB dialect "Samba 3.0.24" and let the client send that
by default. When the server also supports it can tell the client
the connection will be used with this dialect.
2.) because client and server know that they're not talking to windows
the session setup could contain some flags to say if the client
wants plain, sign or sing/seal for the new UserSession.
3.) on further packets we would do the following depending whether
plain, sign or sign/seal was selected on the UserSession:
- then we would call gensec_seal() on the SMB payload data
(maybe mutliples times depending on the gensec_max_input_data()
and gensec_max_wrapped_data()) and append the resulting signatues
behind the buffer. We could may use SMB signiture field 2 * uint32
for storing the offset to the first GSSAPI signature and the count
chunks
4.) The new dialect would also force that only the NT session setups are
supported, using raw NTLMSSP or GSSAPI/SPNEG Also the server could
force the usage of a TreeConnect is only allowed on the correct
UserSession and as the client proposed the new dialect it knows
about this.
Comments are welcome:-)
metze
PGP SIGNATURE
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
8heSg4VMlIWHTy35+w=
=RMzW
PGP SIGNATURE

Tue, Sep 19, 2006 at 06:14:46PM +0200, Stefan (metze) Metzmacher wrote:

I think we should implement something like this:

1.) create a new SMB dialect "Samba 3.0.24" and let the client send that
by default. When the server also supports it can tell the client
the connection will be used with this dialect.

I don't want to make this dialect specific. It fits better into
the UNIX capabilities bitmask as it's UNIX CIFS specific.

2.) because client and server know that they're not talking to windows
the session setup could contain some flags to say if the client
wants plain, sign or sing/seal for the new UserSession.

Again, I think this is better done on UNIX capabilities "set".

3.) on further packets we would do the following depending whether
plain, sign or sign/seal was selected on the UserSession:
- then we would call gensec_seal() on the SMB payload data
(maybe mutliples times depending on the gensec_max_input_data()
and gensec_max_wrapped_data()) and append the resulting signatues
behind the buffer. We could may use SMB signiture field 2 * uint32
for storing the offset to the first GSSAPI signature and the count
chunks

I actually like Volker's idea of just doing this on the data
portion of the packet, before the signing is done on the header.

It's simple, and fits easily into the way the signing is already
done.

Jeremy.