Re: persistent connections and basic authentication

Does it? I read it differently - can you point me at the sections?

Here's my reasoning (please forgive wordiness - I figured better too much
than too little).

firstly regarding persistence:

Persistence is fully "persistent connection" so it is exactly per client
connection, and separately per upstream connection. So if client A can make
one persistent connection and one non persistent connection to squid at the
same time right? I'm not suggesting we alter that at all. I'm suggesting
that when it is a persistent connection we only validate (which could be via
helper or cached credentials) the Basic proxy-authorization header on the
first request.

It's at squid discretion whether _squid_ requires further credentials. 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.
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.

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.

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

The last paragraph, section 2
"A client SHOULD assume that all paths at or deeper than the depth of
   the last symbolic element in the path field of the Request-URI also
   are within the protection space specified by the Basic realm value of
   the current challenge. A client MAY preemptively send the
   corresponding Authorization header with requests for resources in
   that space without receipt of another challenge from the server.
   Similarly, when a client sends a request to a proxy, it may reuse a
   userid and password in the Proxy-Authorization header field without
   receiving another challenge from the proxy server. See section 4 for
   security considerations associated with Basic authentication.
"
So we are completely within the standard whichever way we do this - however
the Proxy SHOULD allow all requests in it's realm to be valid for a set of
credentials that passed one request (ie no more 407's, but 401's are
allowed).

That's about all that affects us.
so on to the meat

current process

1) client connects and requests http:/x.y.z
2) squid sends a 407 and leaves the connection open (http/1.1) or sends a
connection-close (http/1.0)
3) client reconnects (http/1.0)
4) client sends new request with Proxy-Authorization
5) squid verifies the credentials - on fail goto 2)
6) squid returns the resource and leaves the connection open if possible.
(if it gets closed goto 3)
7) client sends a new request, and MAY send Proxy-Authorization.
8) squid verifies credentials, and if missing or faulty goto 2)
9) goto 6
(oh and I hate goto's :-))

I'm suggest step 8 be skipped.

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?

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.

Rob

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Tuesday, October 17, 2000 6:29 AM
Subject: Re: persistent connections and basic authentication

> Robert Collins wrote:
> >
> > I think that the basic authentication code should short-circuit once a
> > connection has been authenticated once. It'll save a hash lookup & base
64
> > deciding at the minimum.
>
>
> It is not allowed to and it is here the NTLM authentication violates the
> specifications.
>
> RFC2616 says that authentication is per request, not per connection.
>
> This also affects the rule that persistense is on a hop-by-hop basis,
> not per client connection.
>
> /Henrik
>
>
Received on Mon Oct 16 2000 - 16:40:49 MDT