Re: Needing state in NTLMSSP

From: Andrew Bartlett <abartlet@dont-contact.us>
Date: 16 Jan 2003 22:06:08 +1100

On Thu, 2003-01-16 at 21:46, Robert Collins wrote:
> On Thu, 2003-01-16 at 21:38, Henrik Nordstrom wrote:
> > tor 2003-01-16 klockan 10.44 skrev Robert Collins:
> >
> > > V2 is the helper-squid revision 2 protocol I think. We had exactly the
> > > interface Andrew suggests back in the early days. It's actually a
> > > straight forward case of removing optimisations to get what he needs.
> >
> > Then we are talking about two different things here.
> >
> > My proposal involves both a complete abstraction of NTLM from Squid
> > moving the full responsibility of NTLM processing down to the helper and
> > also quite significant changes to get rid of the limitation in number of
> > helpers, allowing NTLM to run with a single helper if you like (assuming
> > good connectivity to your backend). The only thing Squid is required is
> > to keep connectivity state between client connection and helper.
>
> We are much of the way there already, and doing what Andrew needs will
> get us closer to that.
>
> I think allowing some caching like we have today is good, and that does
> need NTLM knowledge, but not all that much.

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.

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.

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.

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

Received on Thu Jan 16 2003 - 04:02:44 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:07 MST