Re: persistent connections and basic authentication

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>

> Robert Collins wrote:
[snip]
> It is not per client connection, it is per hop. There might be any
> number of hops between Squid and the client, and there is no way to
> detect this reliably in the protocol.

I follow - although a tcp connection is either a) a hop or b) tunnel mode =
hop for our purposes

[snip]
>
> > I see little point - squid is not offering multiple realms for it's
requests, so
> > the user-agent (which is allowed to cache credentials) will be offering
the
> > exact same credentials on each and every request within the same
connection.
>
> Yes, but there is no guarantee that it is the same user agent which
> sends the the next request on the same connection, unless you know for
> sure that it is a direct connection from the client, and thiscannot be
> detected reliably in the protocol.

as above, we know that it is either a) a user agent directly connected or b)
a downstream cache - which SHOULD NOT pass on the users credentials.
But I do see the issue. I think this devalues the suggestion I made -
consider it dropped.

> > Thus unless squid is planning to offer different realms of
> > proxy-authentication as challenges to different requests, squid should
be
> > confident that it is the same user agent on the existing persistent
> > connection. NTLM makes this a requirement - which I don't like - but
being
> > able to do it is AFAICT within rfc 2616 and 2617.
>
> As I sait it is not safe to make this assumption.
gotcha now - in complete agreement.

>
> > Now regarding the headers
> > proxy-authenticate
> > proxy-authorization are hop by hop (rfc 2616 13.5.1),
> > so it's at squid's discretion what resources require the
proxy-authorization
> > header, and the header is in rfc 2617.
>
> Right. I missed this part, and unfortunately many proxies also disregard
> this when forwarding requests to other proxies within the same
> administrative domain.
>
> A quite common setup looks like
>
> client -> [workgroup proxy] -> [company proxy] -> internet
>
> Where authentication is performed at the company proxy.

So the workgroup proxy does not absorb the proxy-auth* headers and forwards
them in both directions? Ouch :-[

>
> For Basic proxy authentication this is not a problem since it is
> performed on a per message basis. For NTLM authentication or other
> per-connection shemes this causes big problems due to the added hop.
Yup.

>
> > we're only talking basic auth with the proposed change so I'm skipping
the
> > Digest requirements (I'm looking at that as well but more on that
later).
>
> So what is your problem with looking at the basic proxy-authorization
> header on sub-sequent requests on the connection? All known clients
> automatically sends this blindly assuming the proxy requires it.

Simply looking to minimise the work we do to serve the request. No
particular problem per se.

[snip we are both saying approx equivalent thing]

> > Now the question is: once I authenticate a connection, does squid
_allow_ me
> > to change usercode mid-connection, and do the user-agents allow that?
>
> User-agents do it if requested by the proxy, but AFAIK there is no user
> agent where you can manually request a change (logout function is
> missing in all known user agents).
>
> > What I'm really suggesting is that squid only require
Proxy-Authorization on
> > the first request on a connection. It's neither in nor out of standard.
>
> I'd say that it is more out than in of the standard since the RFC's
> assumes a per message view, not per connection. And based on how the
> current browsers behave I see no need for it.
Yup - I was looking from the squid angle not the browser angle.

Thanks for the analysis, and as I said - it's in the junk pile of
not-quite-good-enough-ideas.

Rob
Received on Tue Oct 17 2000 - 05:24:01 MDT