Re: Needing state in NTLMSSP

On Thu, 2003-01-16 at 22:06, Andrew Bartlett wrote:

> I don't see the need for 'NTLM' knowledge. If we do a challenge cache,
> it would be on this basis:
>
> - Client sends Base64 'AAAA' for negotiate
> - Squid doesn't find this negotiate in it's cache, or doesn't find it
> for this IP.
> - Squid asks helper for a challenge, based on this negotiate
> - Squid sends to client
> - Client sends auth packet, squid sends to helper.
>
> - Client sends Base64 'AAAA' for negotiate
> - Squid finds that this negotiate is in it's cache, for this IP.
> - Squid sends reply with cached challenge. (if not 'stale' for
> security).
> - Squid gets reply, and checks against cached 'ok' reply.
> - If it doesn't match (as a base64 string), then ask the helper.
> - If it does, then authenticated.
>
> >From the helper's point of view, it's talking to one client, but may
> receive multiple 'auth' packets. Both smbval and winbind cope with this
> well.

You're missing:
* reset link after offering schemes to client
* reset link on auth failure

special cases for NTLM, as observed in MSP V2 behaviour.

> For security, we never repeat challenges to a different IP.
> Even for the same IP, we don't always repeat the challenge, we just do
> it if we are relatively busy (no free, or not very many free helpers to
> just ask for a challenge), and one of the active helpers matches.

Well, thats a matter of policy, and I'm all for providing appropriate
knobs.

> NTLMv2 responses will defeat the cache, but will not cause an additional
> problem.
>
> How does this sound? I'm actually all for just never caching anything,
> but I understand that on big installations, it's a massive win.

Fine. Like I already said in this thread, it's basically what we had for
the first external helper. The changes from that baseline will be
allowing overlapped requests (which really helps reduce the number of
helpers).

Rob

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