Re: [SQU] Credentials forwarding?

Robert Collins wrote:

> A given HTTP request is a set of headers and an optional body. Basic style authentication places no association between the specific
> request and the authentication. So if I have a telehoused box sitting at the ISP, with a little effort I can packet capture the
> requests going through. I can then replay the request (with or without IP spoofing), using the unaltered basic authentication
> header, thus acruing data charges for the original user while I get my response scott free.

Yes Basic is replayable, but it doesn't mean that the feature of
forwarding the username in this way is, only that the currently
underlying mechanism is.

If other authentication clients are implemented for the login=
cache_peer option then this won't be a problem.

The control can also be hardened by IP access controls, only allowing
downstream users from the downstream caches.

> Changing the application of the protocol is effectively changing the protocol
> from rfc 2617.
> "user-pass = userid ":" password"
>
> We are expecting the upstream cache to strip .[^@]@ from userid before treating it as a userid. This will require changes to EVERY
> proxy in the world to interoperate. Or else they will see john@ mary@ ...

Which is perfectly fine from a interoperability point of view. The user
IS mary@downstream, not downstream (if it wasn't then there would not be
any need to pass that information in the first place).

> We are also missing a mechanism to tell downstream caches that
> we expect the username in the format of john@ - how does the cache
> tell the difference between a user directly connected to the cache,
> and a downstream cache?

By having peering agreements between the management of the upstream and
downstream caches. If you didn't have those then there would not be any
need for all this in the first place.

> By separating out the functions like I'm proposing we can do the following
> acl authed proxy_auth REQUIRED
> acl downstream_caches proxy_auth client1_com client2_com
> acl client_username coop_user REQUIRED

And you still need a secure authentication method to protect from
replay/spoofing attacks.

And you also have the problem of namespaces. If you have N downstream
domains passing the user credentials, what does the coop_user ACL match?

> This will still allow direct clients. And while it does require
> changes to other caches to interoperate, they will never see the
> headers unless they put the challenge in.

And the approach by using proxy authentication acheives both things,
with no requirements on changes to interoperate. If cooperation is not
supported by the upstream then a lot of configuration is needed to set
up all the downstream user accounts in the upstream administrative
domain. If cooperation is implemented then about the same amount of
configuration is needed in either of the two methods.

/Henrik
Received on Tue Jan 09 2001 - 16:39:12 MST