Re: Needing state in NTLMSSP

Andrew Bartlett <abartlet@samba.org> writes:

> I've been working on getting Samba's NTLMSSP functionality exported to
> the world, with the aim of producing a 'standard' implementation of
> NTLMSSP that multiple projects (squid and apache) can call on.
>
> This has gone quite well so far, and I've extracted the code into
> libsmb/ntlmssp.c, and written almost all the extra code for 'ntlm_auth'
> - the squid helper interface to this. See current Samba HEAD for my
> progress so far.
>
> However, squid makes all sorts of nasty little assumptions about how
> NTLMSSP operates - in particular it attempts to make NTLMSSP almost
> stateless. It most certainly is not... While most implementations
> 'cope' with the current code, I'm trying to get this done right. (And
> therefore get NTLMv2 and Unicode working in particular).
>
> My first problem is that Squid doesn't pass the 'negotiate' packet to
> the helper at all! I'm currently testing a nasty little hack that will
> pass this along, but we also need to look at how the helpers are
> structured in general - we really do need one helper per client - say
> key it on the IP (to allow limited challenge reuse) and the contents of
> the negotiate packet.

Agreed.
And when we implemented the protocol, we didn't think that the
negotiate packet had any impact at all on the authentication outcome. This
requires an accomodation, and an extension of the squid<->helper protocol.

We didn't really make it stateless, we just thought it best to leave as
much status as possible in the client. One problem we have is that it's
guarranteed that the connection to the client will be shut down between the
negotiate and challenge phases, because we shut it down. This MIGHT be
unnecessary really, but it should be tested before changing squid's
behaviour (which right now mimics network traces obtained from different
implementations of the NTLMSSSP challenge scheme - including Microsoft's of
course). If the assumption were too strict, then we'd be able to still key
on the connection (I'm not really keen on keying anything on the IP -
Terminal Server, Metaframe etc) AND be able to keep state "right".

Also, tying the helper to the IP has some ugly consequences wrt helper
load-balancing unfortunately.

> With NTLMv2, and LMv2 the client introduces it's own 'client challenge',
> so this caching goes aways pretty quickly anyway. And with Winbind
> doing the auth end of the transaction, the expensive bit is now the
> 'verify', not getting the challenge in the first place.
>
> I am worried about the effectively one-helper-per-client side of this -
> it could be addressed by having the helper keep multiple states.
> (Because we don't need to request the challenge, or keep a socket open,
> it's relatively sane)
>
> So, what do people think? It looks awfully like the 'v2' helper
> protocol, but I really do think it's a worthwhile move forward.

Agreed.

-- 
	kinkie (kinkie-squid [at] kinkie [dot] it)
	Random fortune, unrelated to the message:
If it's not in the computer, it doesn't exist.