RE: NTLM

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

Can't ask for anything better.

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

Correct.

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

No can do unless you can supply the challenge to the authentication
provider, which is a no-go for NTLMSSP which is going to stay.
Challenge generation will be at best at the helper level.

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

Well, we'd need a better helper (looking back at the current NTLMSSP,
well let's just say it's not something I'm proud of - in fact I'm ashamed)
AND a way of multiplexing stuff to/from the helper. All of this has already
been told :)

-- 
	/kinkie