FAQ update

Just a though - I was reading the FAQ for something else and this struct me
as being slighty, well, uhmm, wrong. (The IP address isn't an issue AFAICT).

Could the following be changed
11.14 How come Squid doesn't work with NTLM Authorization.
We are not sure. We were unable to find any detailed information on NTLM
(thanks Microsoft!), but here is our best guess:

Squid transparently passes the NTLM request and response headers between
clients and servers. The encrypted challenge and response strings most
likely encode the IP address of the client. Because the proxy is passing
these strings and is connected with a different IP address, the
authentication scheme breaks down. This implies that if NTLM authentication
works at all with proxy caches, the proxy would need to intercept the NTLM
headers and process them itself.

Henrik Nordstrom adds the following information about NTLM:

NTLM authentication is carried entirely inside the HTTP protocol, but is
different from Basic authentication in many ways.

  1.. It is dependent on the IP addresses of both the server and the client,
and thus cannot be proxied by a application level proxy (not even Microsoft
Proxy server).
  2.. It is only taking place once per connection, not per request. Once the
connection is authenticated then all future requests on the same connection
inherities the authentication. The connection must be reestablished to set
up other authentication.

The reasons why it is not implemented in Netscape is probably:

  a.. It is very specific for the Windows platform
  b.. It is not defined in any RFC or even internet draft.
  c.. The protocol has several shortcomings, where the most apparent one is
that it cannot be proxied.
  d.. There exists an open internet standard which does mostly the same but
without the shortcomings or platform dependencies: Digest authentication.

to be

11.14 How come Squid doesn't work with NTLM Authorization.
We are not sure. We were unable to find any detailed information on NTLM
(thanks Microsoft!), but here a reference:

http://support.microsoft.com/support/kb/articles/Q198/1/16.ASP

We quote from the summary at the end of the browser authentication section

"In summary, Basic authentication does not require an implicit end-to-end
state, and can therefore be used through a proxy server. Windows NT
Challenge/Response authentication requires implicit end-to-end state and
will not work through a proxy server. "

Squid transparently passes the NTLM request and response headers between
clients and servers. NTLM relies on a single end-end connection (possibly
with men-in-the-middle, but a single connection every step of the way. This
implies that for NTLM authentication to work at all with proxy caches, the
proxy would need to tightly link the client-proxy and proxy-server links, as
well as understand the state of the link at any one time. NTLM through a
CONNECT might work, but we as far as we know that hasn't been implemented
by anyone, and it would prevent the pages being cached - removing the value
of the proxy.

Henrik Nordstrom adds the following information about NTLM:

NTLM authentication is carried entirely inside the HTTP protocol, but is
different from Basic authentication in many ways.

  1.. It is dependant on a stateful end-end connection which collides with a
RFC 2616 for proxy-servers to disjoin the client-proxy and proxy-server
connections.
  2.. It is only taking place once per connection, not per request. Once the
connection is authenticated then all future requests on the same connection
inherities the authentication. The connection must be reestablished to set
up other authentication or re-identify the user.

The reasons why it is not implemented in Netscape is probably:

  a.. It is very specific for the Windows platform
  b.. It is not defined in any RFC or even internet draft.
  c.. The protocol has several shortcomings, where the most apparent one is
that it cannot be proxied.
  d.. There exists an open internet standard which does mostly the same but
without the shortcomings or platform dependencies: Digest authentication.
Received on Thu Aug 10 2000 - 04:21:32 MDT