Re: NTLMSSP and Squid

On Sat, 2003-05-10 at 21:08, Henrik Nordstrom wrote:
> On Saturday 10 May 2003 12.48, Robert Collins wrote:
>
> > Deprecate / remove all stateful helper logic.
>
> The stateful helper logic may well be kept in my opinion, but not the
> challenge reuse logic of ntlm. Squid should not care at all about
> NTLMSSP packet contents, only connection and helper state.
>
> Overlapping requests solves the resource problem of stateful helpers.

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.

> > I.E. do away with all the fluff that was needed to make use of
> > server-assigned challenges work (where the server would irregularly
> > drop the tcp connection and force all outstanding auths to fail.)
>
> Fully agreed.
>
> > Arbitrary challenges will work fine with winbind, and we can retain
> > logic to check that a challenge was indeed issued by squid on a
> > connection to prevent chosen challenge attacks.
>
> Stateful deals with this. You MUST somewhere remember the challenge
> sent to the client for NTLM to work, the client does not send
> information about the challenge it received.

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.

> In my opinion all this logics belongs in the helpers.

The bulk of it yes. Stateless helpers are much easier to manage though.
Anyway, we can do the whole thing with stateful helpers and see whether
we can go stateless as a final stage.

> How to retain
> the challenge state differs with the implementation. For winbind
> helpers you only need to retain the NTLM/LM challenge value, for
> win32 NTLMSSP you need to retain the NTLMSSP connection object. For
> other NTLMSSP implementations you may need to retain other
> information to be able to process the AUTHENTICATE packet.
>
> If the clients send AUTHENTICATE packets not matching the challenge
> they got authentication will fail.
>
> For security reasons it is important the challenges are unique on each
> request, and if possible it should also be verified that the server
> choosen challenge does not produce unsuitable hashing material for
> NTLM/LM but this is not by far as important.
>
> Not sure what you refer to by "choosen challenge attacks" in the
> context of Squid. This type of attacks only applies in the other
> direction. If a server can convince a client to send AUTHENTICATE
> packets then the server can do a choosen challenge attack on the
> client credentials to try to derive the users NTHASH/LMHASH.

IIRC: Long ago (about 6 years ?) there where chosen challenge attacks
against the NT 4 SAM. But: yes, the usual case is for the challenger to
choose deliberately weak challenges. So, my memory may be faulty.

Rob.

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.