Stablising the winbind interface for squid's NTLM code

[Henrik Nordstrom]

Andrew Bartlett wrote:

> Being a seperate execuable, licencing issues are overcome (not an issue
> for squid, but we
> can now allow the same thing for apache).  I hope that we can also use
> the same NTLMSSP implementation inside Samba - which should ensure its
> maintainence into the future.

The Squid ntlm helper protocol is effectively raw NTLMSSP exchanges plus
a status code telling the type of NTLMSSP message.

Any interface using NTLMSSP would be fine for us, preferably in a manner
that releases the application from having to understand anything about
NTLMSSP formats. Today the Squid ntlm authentication core needs to
understand a bit of  NTLMSSP to extract the username which is a pain as
there is many possible username formats, and may be problems for non-GPL
licensing..

> Conceptually, it would be a simple code import from squid's current
> helper's directory.  In practice, a lot of the code will need to be
> reoganised and rewritten (simply due to differences between the
> projects).  In particular, I would like to leverage tridge's RPC
> encoder/decoder, and try to get a relitivly simple code-path going.

I don't think there is much in Squid's helper directory to pick up,
except for some far from complete NTLMSSP decoding/encoding routines.

> One change I would make:  Allow one helper to issue a challange, and
> another to pick it up.  This could be done by sending the second helper
> the challange packet, with a tag to say 'pretend you sent this'.

Be careful to not block implementation of NTLMv2 NTLMSSP in such
approach.

We do not need such statelessness in Squid as we already have the code
to track which helper issued the challenge, needed for other backends.
And for things like Apache 1.X such interface would be overly complex I
think..

What you needs to decide upon is if the winbind interface should use
NTLMSSP exchanges, or just LM/NTLM/NTLMv2 challenge+response exchanges.

If it is decided that winbind is to use a basic LM/NTLM/NTLMv2
challenge+response interface, then it needs to be decided upon how
NTLMSSP is to be provided

  a) Not at all, having each application implement what they need
  b) Separate "reference" implementation
  c) Shared or link library shipped with Samba (static/dynamic linkage
to not bother us)
  d) Separate daemon acting as a NTLMSSP frontend to winbind.


What I think I would like to see is winbind to start with a simple
interface for verifying LM/NTLM/NTLMv2 response packets, optionally
including the MD4(NT#) for use by MS CHAPv2. Access to this interface
should be restricted to local pipes only. It is probably ok if different
interfaces is used for each of LM / NTLM / NTLMv2. The application
really should only care about the strongest provided so I don't see the
need of being able to verify a combined LM + NTLM reponse.

Then let a NTLMSSP implementation evolve ontop of this, starting out as
a reference implementation but with the ultimate goal of becoming a
official winbind interface, either directly in the winbind daemon, or as
a separate daemon, having a interface along the lines of MS SSP when
using the LM/NTLM SSP.