Re: NTLMSSP and Squid

On Sat, 2003-05-10 at 22:00, Robert Collins wrote:
> On Sat, 2003-05-10 at 21: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.
>
> Yes - I know that. There is a subtle issue here:
> state about the handshake vs state for each helper process.
>
> Due to limitations in the original helpers, they *had* to maintain a TCP
> session to the domain controller, and the challenges they issued came
> from the that controller - so the specific requests could not follow
> this pattern:
>
> negotiate->squid->helper 1
> helper1->squid->client
> client->squid->helper 2
> helper2 ->squid
>
> winbind, and AFAIK Guidos' helper, don't suffer from this issue.

Winbind does suffer from this - because it's helper makes up the
challenge, and the second helper won't know what it is.

> > > Yes - we store that in the ntlm request auth structure that we
> > > associate with the TCP connection. (We do that today). We then send
> > > that back to the helper along with the response.
> >
> > And I strongly maintain this should not be of a concern to Squid.
> > Squid should not even attempt to decode or understand NTLMSSP
> > packets. All Squid should worry about is the connections to the
> > client and helper.
>
> We *have* to know the handshake logic. Decoding the packets is
> orthogonal. (I wasn't suggesting decoding). Simply storing the base64
> encoded challenge as we do today will do. And that *will* be needed to
> do efficient overlapping stateful requests anyway.

It's not needed for stateful overlapping - all you need there is a
'connection number' sent to the helper. You could do it all with one
helper, actually. (winbind is a single thread in any case).

It is needed if you want to play caching tricks, so you can compare if a
request is compatible with a previous challenge. The helper would just
get 2 auth packets for one challenge. I have written Samba's NTLMSSP
code to cope with this, but SSPI on windows probably won't like it.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet@pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet@samba.org
Student Network Administrator, Hawker College   abartlet@hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net