Hello folks,
As you might know, I'm a Google SoC student implementing NTLMSSP
signing/sealing in Wine. I've worked on basic NTLM authentication for Wine
last year, using ntlm_auth. This road proved to be a dead end, though, as
ntlm_auth does not support signing or sealing packages.
Thus, after talking with Andrew Bartlett and Jelmer Vernooij on SambaXP 06, I
decided to give Samba4's GENSEC subsystem a try. (This is working pretty
well, and I have a set of patches[1] that make use of GENSEC to do client
side authentication and encryption.)
As it happens, the Wine project is using the LGPL license and Samba is using
the GPL license for this part of the code. The plan was to spin out GENSEC as
a seperate library under the LGPL. Unfortunately, it seems like this is not
as easy as we expected.
Today I was talking to Stefan Metzmacher in IRC and he asked me to give a list
of features I need from this GENSEC library on the mailing list, and here
goes:
* NTLM and, if possible Negotiate authentication client side and server side,
again if possible.
My use case would be 2003 talking to an MS Exchange 2003 server,
authenticating using NTLM. So the bare minimum I could work with would be
client side NTLM authentication. To have the server side would be a bonus in
the long run.
* Package signing/verifying for NTLM
* Package sealing/unsealing for NTLM
My use case here would be 2003 from the above scenario signing or
encrypting communication to the Exchange server.
* The chosen solution should ideally be working for Wine in the near future.
Looking at those requirements and talking to a couple of people in
#samba-technical, I see a couple of possible solutions and I depend on your
help for most of them.
1) Spin out the minimal functionality GENSEC library and find a method to
handle server side functionality later. This approach has the downside that I
will be deleting some of the functionality I currently have in Wine, as
ntlm_auth can do server side authentication. the plus side, it seems that
ntlmssp_server is the part that would be tricky to LGPL, client side seems
easier. I could also keep the old ntlm_auth code around for server side
authentication, which would add bloat to the Wine source, though.
2) Scratch the current approach using GENSEC and add handling of NTLMSSP blobs
to winbind. This would possibly go into Samba 3, and thus be part of a
distribution's Samba package sooner. It would also mean that there is a nice
IPC border between the GPL and the LGPL code, so no problems there. I would
need to rewrite that part of Wine yet again, though.
3) Extend ntlm_auth to also handle signing/sealing and extend the current Wine
code to use ntlm_auth for that, too. This would also keep the GPL and LGPL
code seperate and force me to ditch my current work, but at least I can keep
the stuff I did last year. It would add bloat to ntlm_auth, of course.
4) I could drop using Samba at all and try to extend libntlm[2]. I don't
particularly fancy this idea, but there's a couple of people on the Wine side
who would prefer not to add another dependency to Wine, so it might be easier
to convince Alexandre Julliard to accept that code. I would again mean to
rewrite all the Wine code I wrote so far, plus it smells of reinventing (and
maintaining) the wheel.
Now as I'd like to have some results besides a GPL fork of Wine to show for
this summer of code, I would be willing to pick the solution that will get me
a result first. For solutions 1)-3) I would need the support of the Samba
team, of course.
I am willing to put some work into this on the Samba side, but only if I can
be sure that my patches will get accepted (after a reasonable amount of time
and bug fixes, of course).
So, what would be the preferred solution from the Samba side of things?
Thanks for reading this far, this email got longer than I expected.
Kai
[1] (user and password
are "wine" without the quotes, to stop search engines from indexing the
patches, as they're not redistributable)
[2] http://josefsson.org/libntlm/

Mon, 2006-07-03 at 11:54 +0200, Stefan (metze) Metzmacher wrote:
PGP SIGNED MESSAGE
Hash: SHA1

Kai Blin schrieb:
Looking at those requirements and talking to a couple of people in
#samba-technical, I see a couple of possible solutions and I depend on your
help for most of them.

1) Spin out the minimal functionality GENSEC library and find a method to
handle server side functionality later. This approach has the downside that I
will be deleting some of the functionality I currently have in Wine, as
ntlm_auth can do server side authentication. the plus side, it seems that
ntlmssp_server is the part that would be tricky to LGPL, client side seems
easier. I could also keep the old ntlm_auth code around for server side
authentication, which would add bloat to the Wine source, though.

2) Scratch the current approach using GENSEC and add handling of NTLMSSP blobs
to winbind. This would possibly go into Samba 3, and thus be part of a
distribution's Samba package sooner. It would also mean that there is a nice
IPC border between the GPL and the LGPL code, so no problems there. I would
need to rewrite that part of Wine yet again, though.

I would vote for a combination of 1) and 2)

I think we should only pass authentification blobs to winbind,
so that ntlmssp_server.c works with a generic backend,
the current one to samba's auth subsystem.

and one that passes the blob's from gensec_update() to winbind

but the sign and seal should be part of the LGPL'ed library,
as asking winbind for each packet for en/decrypting would be bad!

I've been thinking about this, and talking with some other team members.
I think there is a lot of value is having winbindd as the local LSA-like
thing. That is, for other reasons we are starting to stash the password
at logon time. (And winbind is required for the server-side).

What has worked very well in the past has been ntlm_auth, as a long-term
interface. Being a binary has helped a lot, but this is impractical for
sign/seal interfaces.

Perhaps this is a solution: We extend ntlm_auth to simply spit out the
keys, and the negotiated flags. Then, a small library can turn that
into a signed/sealed stream, if required. That library could even be
GENSEC (without the normal modules, but with a glue-to-ntlm_auth
module).

ntlm_auth as a client would not require winbindd, unless you wanted
single-sign-on.

thing I should make clear: We should aim for solutions that don't
ask the Samba team to wholesale relicence code, but instead show maximum
bang-for-buck. That is, showing a working solution with doing
encrypted RPC to exchange is very valuable. Showing that 'we only need
these small parts' is even more valuable.

I don't want to lock up our authentication code, as it is valuable. It
has taken us many years to get here, and we should be able to show
exactly what we gained for relaxing any conditions on this.

Andrew Bartlett

Tuesday 04 July 2006 14:01, Andrew Bartlett wrote:

2) Scratch the current approach using GENSEC and add handling of
NTLMSSP blobs to winbind. This would possibly go into Samba 3, and thus
be part of a distribution's Samba package sooner. It would also mean
that there is a nice IPC border between the GPL and the LGPL code, so
no problems there. I would need to rewrite that part of Wine yet again,
though.

I would vote for a combination of 1) and 2)

I think we should only pass authentification blobs to winbind,
so that ntlmssp_server.c works with a generic backend,
the current one to samba's auth subsystem.

and one that passes the blob's from gensec_update() to winbind

but the sign and seal should be part of the LGPL'ed library,
as asking winbind for each packet for en/decrypting would be bad!

I've been thinking about this, and talking with some other team members.
I think there is a lot of value is having winbindd as the local LSA-like
thing. That is, for other reasons we are starting to stash the password
at logon time. (And winbind is required for the server-side).

What has worked very well in the past has been ntlm_auth, as a long-term
interface. Being a binary has helped a lot, but this is impractical for
sign/seal interfaces.

Perhaps this is a solution: We extend ntlm_auth to simply spit out the
keys, and the negotiated flags. Then, a small library can turn that
into a signed/sealed stream, if required. That library could even be
GENSEC (without the normal modules, but with a glue-to-ntlm_auth
module).

, my suggestion here would be this.

For the ntlm client mode of ntlm_auth, we extend it as follows:

YR [flags] <-- The requested flags from the application
K [flags and key] <-- negotiated flags and session key

(on a side note, should that go into the ntlmssp-client-1 helper mode or into
a new ntlmssp-client-2 mode that is like ntlmssp-client-1 but with those new
features?

I think I'll first have a go at encryption/signing from within Wine, and try
to spin it out as a separate library once I know what is needed.

Does this sound reasonable?

ntlm_auth as a client would not require winbindd, unless you wanted
single-sign-on.

We might want to look into that later, but I guess the correct way to do that
is to interface with whatever credentials cache we want to use from the LSA
code.

thing I should make clear: We should aim for solutions that don't
ask the Samba team to wholesale relicence code, but instead show maximum
bang-for-buck. That is, showing a working solution with doing
encrypted RPC to exchange is very valuable. Showing that 'we only need
these small parts' is even more valuable.

Unfortunately I neither have nor Exchange myself, but I'll see if I
can arrange for a test setup there, somehow.

I don't want to lock up our authentication code, as it is valuable. It
has taken us many years to get here, and we should be able to show
exactly what we gained for relaxing any conditions on this.

This doesn't fully parse for me, but I assume you don't want to open up the
authentication code

Cheers,
Kai

Wednesday 05 July 2006 12:26, Kai Blin wrote:

For the ntlm client mode of ntlm_auth, we extend it as follows:

YR [flags] <-- The requested flags from the application
K [flags and key] <-- negotiated flags and session key

a second thought, as the client returns the NTLMSSP reply on K/AF, that
would break backwards compatibility.

Mind if I add a GK command to get the session key and a GF command to get the
negotiated flags?

Cheers,
Kai

Mon, 2006-07-10 at 00:53 +0200, Kai Blin wrote:
Wednesday 05 July 2006 12:26, Kai Blin wrote:

For the ntlm client mode of ntlm_auth, we extend it as follows:

YR [flags] <-- The requested flags from the application
K [flags and key] <-- negotiated flags and session key

a second thought, as the client returns the NTLMSSP reply on K/AF, that
would break backwards compatibility.

Mind if I add a GK command to get the session key and a GF command to get the
negotiated flags?

Sounds good.

Andrew Bartlett