Re: NTLMSSP and Squid

On Saturday 10 May 2003 13.49, Henrik Nordstrom wrote:
> On Saturday 10 May 2003 13.26, Robert Collins wrote:
> > The stateful helper logic was only ever a workaround for helpers
> > that *had* to maintain state across requests. We can keep the
> > logic for reuse, but it won't be needed once we switch to passing
> > everything through with no challenge reuses ever, and the
> > negotiate is given to the helper.
>
> Keeping state WILL be required somewhere.
>
> You cannot process an AUTHENTICATE packet without knowing the
> information used when generating the CHALLENGE packet.

To summarise the needs for state one more time:

wb_ntlmauth:
        Needs to keep the NTLM challenge value

ntlm_auth:
        Needs to keep the SMB connection who gave the challenge

Native win32 ntlm using Microsoft NTLM SSP AcceptSecurityContext()
function to process and generate NTLMSSP packets:
        Needs to keep the SSP context object who processed the NEGOTIATE
packet and generated the CHALLENGE packet.

hypothetical ntlmssp relay auth, for example if using a IIS server for
NTLMSSP processing:
        Needs to maintain the connection to the NTLMSSP server used.

Guido: I do not see how your win32 ntlm helper can work. From what I
can tell you generate and forget your own challenge, and then fakes
an authentication step with faked user credentails. This is not even
mathematically possible to work and I suspect your helper is not
acutally authenticating the user but in reality accepting mostly
anything as long as the Squid library can make sense of... The
challenge needs to be generated by AcceptSecurityContext() and the
context generated whem making the challenge packet remembered when
the helper later gets the AUTHENTICATE NTLMSSP packet.

The correct operation of a server accepting NTLMSSP using the Windows
SSP API is something like:

  1. Set up the server state
  2. Accept the NEGOTIATE packet and send this to
AcceptSecurityContext with a NULL context handle and a pointer to
where the new context handle can be returned.
  3. Send the returned BLOB back to the client (this is the CHALLENGE
packet).
  4. When receiving the AUTHENTICATE packet process this BLOB with
AcceptSecurityContext using the context returned in the new context
handle pointer in 2 above.
  5. Return success/failure to Squid, and free the context set up in
2.

Note about step 2: With the current state of Squid you will need to
fake the NEGOTIATE packet blob with what you think the client is
providing, or hack Squid to sent the NEGOTIATE packet to ntlm
helpers. Warning: if you hack Squid to send the NEGOTIATE packet then
there is a serious risk of cross-browser incompability in challenge
reuses, with the effect that one user can cause authentication to
randomly fail for others if the challenge returned by SSP for his
NEGOTIATE packet is incompatible with the browser/OS used by the
other user. But on the other hand this will most likely also allow
NTLMv2 to function.

Regards
Henrik
Received on Sat May 10 2003 - 07:58:12 MDT