Re: NTLMSSP and Squid

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.

> 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.

In my opinion all this logics belongs in the helpers. 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.

> This is a major change though, and IMO best slated for 3.1 - it
> will take time to do it RIGHT.

Agreed.

Regards
Henrik
Received on Sat May 10 2003 - 05:07:55 MDT