Re: NTLM

On Monday 25 February 2002 10:43, Chemolli Francesco (USI) wrote:

> Easy: the NTLMSSP helper understands neither, so those are always
> reset :) If you're talking about future protocol extensions where
> the helpers might not see the whole picture, I agree that it
> wouldn't be wise.

The helper must not echo back flags it did not receive from the
client.

> Squid currently just asserts its own flags, it doesn't care about
> what the other hand has to say.

Exacly.

> > Should also note that there should be a slight difference in the
> > challenge when NTLMv2 is used.
>
> I'd need doco on this.

I will implement NTLMv2 today, separately as Squid cannot be used
(yet). Will collect notes along the way.

> There is a mapping between a client and the helper process which
> generated the challenge. As long as the helper doesn't fail, that
> challenge can be reused.

Ah, got you. You reuse the authenitcate state of the same helper for
the lifetime of the challenge.

Would be a bit unstable for NTLMSSP, but I guess this is one of the
issues you are fighting with.

> For security reasons it would be better not to use the same
> challenge on the same client, I think. It limits the possibility of
> replay attacks. But since we can only have a limited number of
> in-use challenges (one per helper process) it would be hard to do,
> and probably pointless.

Agreed.

You need to either need to move the challenge generation into Squid,
or allow helpers to have more than one pending challenge at a time.
There is no real reason why a single NTLMSSP helper could not support
lets stay 500 concurrent challenges by maintaining 500 RPC handles.
(no, non-blocking I/O is not needed)

Regards
Henrik
Received on Mon Feb 25 2002 - 03:17:14 MST