Re: NTLM, Windows and the sessionkey field

----- Original Message -----
From: "Henrik Nordstrom" <hno@marasystems.com>

> On Sunday 24 February 2002 06:09, Robert Collins wrote:
>
> > Another data point for why we are looking at putting the challenge
> > generation into squid :].
>
> I don't agree on such design.
>
> You then need negotiation betwen Squid and the helper on all the
> authentication methods the helper is capable of supporting.

Not a big deal really. The _only_ required difference is whether squid
asks for a challenge or provides it's own, and that can be turned on and
off via a startup handshake, or a config entry. Parsing the negotiate
can be implemented without altering the helper protocol. I plan on
retaining support for the current helper-squid protocol indefinately
anyway, because winbindd doesn't exist on win32, and NTLMSSP works.

> Extending the helper to add for example NTLMv2 and Kerberos in the
> current scheme is very simple, provided they fit in the same
> three-way handshake and you know the two protocols. Doing the same to
> Squid is not as simple.

Actually it's not. Kerberos doesn't fit in the same scheme. NTLMv2
though - yes.

> Also, if someone adds a third party authentication mechanism then
> again the same thing.

This is an interesting point. Personally if someone wants to add a third
party scheme to http-ntlm, they will need something that doesn't exist:
doco on MS's innards. They will also need to alter MSIE to support it.
Squid will be the least of their worries.

> A move that could be smart it to (optionally) allow multiplexing of
> requests on a helper.

This is adding complexity thats not needed. Several reasons:
1) _Only_ winbindd and local file helpers can support multiple
challenges. The NTLMSSP helper cannot support multiple outstanding
challenges - without serious backend changes in the smbval library we
are using.
2) The helpers would need to start using non-blocking IO, removing all
the simplicity benefits of having them outside squid in the first place.

If you mean the ability to have pending authentications overlapping,
then we already have that.

> Either by using a virtual "connection number"
> in the requests when talking to the helper, or by echoing back the
> challenge together with the authentication package. (I prefer
> "connection number" approach I think).

What do you mean by authentication package?

Rob
Received on Sun Feb 24 2002 - 00:10:11 MST