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.

There is already a proposal to add a 'connection number' state system
into Samba's ntlm_auth. Ie, if the stdio line starts with an integer,
then that is the context to be looked up inside ntlm_auth's internal
list of outstanding challenges.

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

There is a performance issue here - challenge re-use can give
significant performance gains. However, recent advances in how winbind
operates in Samba has allowed the DC communication part to be reduced to
just 2 packets.

Challenge re-use can be done safely - we just need to ensure that the
challenge is only sent to a 'compatible' client. This should be a
client with the same IP, and who sent the same negotiate packet
(compared base64 encoded inside squid).

> 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 why NTLMv2 exists, which blows all of the challenge reuse out of
the window...

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