RE: [SQU] Credentials forwarding?

> -----Original Message-----
> From: Henrik Nordstrom [mailto:hno@hem.passagen.se]
> Sent: Wednesday, 10 January 2001 11:51 AM
> To: Robert Collins
> Cc: squid-dev@squid-cache.org
> Subject: Re: [SQU] Credentials forwarding?
>
>
> Robert Collins wrote:
>
> > 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.
>
> It doesn't need to. It is a requirement in the peering
> agreement between
> the two administrative domains. If the peering agreement
> didn't require
> the user credentials to be passed, why should they?

What you're suggesting is the caches are _manually_ synchronised for
this protocol extention/change/whateverwecallit. That is bad in my book
because a change in sysadmin, or a change in user directory will break
the link. It's not robust.

I'm not suggesting that squid send the credentials just because the
upstream asks for them - that'd be a invasion of privacy. I'm suggesting
that squid _never_ sends them unless it knows the upstream wants and can
use them. There would need to be a cache_peer option on the downstream
to allow it
ie cache_peer .... pass_user_details=on

> > 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.
>
> Point taken.
>
> So for such schemes, the upstream using my proposal cannot take the
> shortcut and handle all users as one. This means the backend must be
> aware of the method, or that the (backend) user database includes all
> users for each downstream.

Exactly: it won't work without upstream code changes. Even if the
backend is aware, the cache as well must be aware. - and that was my
point: we have broken the protocol, and done it for less than the
maximum results.

Including all users for the downstream defeats the point of passing
usernames across _administrative_ boundaries.

>
> Does not look as neat, but still manageable I think.
>

It's manageable, as long as both caches are altered to cope. Or the ISP
adds x users with the same secret to their basic/digest/ntlm backend.
Not exactly a concise solution.

Rob
Received on Tue Jan 09 2001 - 18:11:51 MST