Re: Needing state in NTLMSSP

On Thu, 2003-01-16 at 22:10, Robert Collins wrote:
> 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.

I don't see how this involves the helper. When it receives a new
negotiate packet, then it discards the previous negotiated settings, but
I don't see any other issues here.

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

Good :-)

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

If it becomes a real problem, we can make the helper 'multithreaded'
(keep multiple sets of state) *very* easily. Well, it's easy for
ntlm_auth, maybe not so easy for the others. It would still be up to
squid to 'manage' the allocation to those contexts, but it could save
process table space. (Authentications are single-threaded anyway, at
the winbind level).

For this, the protocol would be:
1 YR DFAFFD -> TT BABABA
2 YR ABABAB -> TT BRDFDD
1 KK FGESGD -> OK ab\foo
2 KK DFADFD -> OK ab\foo2
2 KK DFDSDF -> AF bad pw

etc.

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