Re: Needing state in NTLMSSP

tor 2003-01-16 klockan 12.06 skrev Andrew Bartlett:

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

Looks good.

For load purposes (with Squid we might get a storm of several hundreds
concurrent NTLM negotiations for a high rate proxy) I only propose that
to each helper process a multiplexed channel is used, IFF the helper is
capable of processing multiple users.

For winbind there is no problem with processing multiple users.

Having the helpers sit idle only because they are blocked by a client
thinking about how to send the auth packet is a big waste, and very
easily ends up in a DoS condition where all helpers are made busy unless
the number of helpers is exessively large (in the range of thousands).

Regards
Henrik
Received on Thu Jan 16 2003 - 08:12:13 MST