Re: [SQU] Credentials forwarding?

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Wednesday, January 10, 2001 10:39 AM
Subject: Re: [SQU] Credentials forwarding?

I'm not suggesting your patch be backed out Henrik.. I'm suggesting we need a full solution thought out and then implemented.

> Robert Collins wrote:
>
> 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.

Agreed.

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

I disagree. Some authentication methods may server @ and . in the username that is sent on the wire. Some (like digest) may encode
the username into the request so the user can _only_ be authenticated using the header supplied user name.
Digest won't work with this method with an upstream cache UNLESS the upstream cache knows to strip the username back.

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

"Rfc 2617: IP addres spoofing is not that hard". Sure it can be hardened, but why start less secure than we need to?

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

No it's not. See my comment on Digest. Any authentication worth it's salt is going to encode the supplied username as part of the
response - precisely to defeat MITM attacks (which is essentially what this is (at a protocol level)).

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

Yes but HOW does the upstream cache communicate to the downstream that it supports this? If it doesn't communicate this, Digest
authentication (if that's being used) _will_ fail. And the upstream provider may have a problem with their cache and switch box's
temporarily. Squid doesn't assume HTTP 1.1 for a cache peer - it detects it. Sure they have a peering agreement BUT the protcol
needs to communicate it's capabilities.

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

Yes we are agreed on this. Thus implementing upstream capabilities into the auth_rewrite code was on my round #2 list.

> 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?

acl org1 coop_user [^@]*@client1\.com
acl org2 coop_user [^@]*@client2\.com

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

actually it doesn't achieve both things. That's my point. It's a neat little hack for now, but it won't cleanly and reliably grow
into the existing authentication protocols that do prevent replay & spoofing - because they are designed to prevent in-transit
changes which overloading the user is.

Rob
Received on Tue Jan 09 2001 - 16:54:59 MST