Re: [SQU] Credentials forwarding?

Henrik Nordstrom Wrote:

> Robert Collins wrote:
>
> > I'm not quite sure I follow on the use@something... could you elaborate?
>
> Lets assume the forwarding is configured to use
>
> login=*@this-cache.com:my_secret_password
>
> And the parent is configured to receive forwarded credentials using this
> format. What the parent then could do is to strip away the user@ part
> from the credentials for it's own authentication processing, but use the
> full credentials for logging and "user" ACL list processing.

ahh. Yes that's a reasonable hack. this-cache.com becomes the username.

>
> > a) it's replayable (I know - broken record)
>
> And this I do not get fully get. Please explain.

Putting a cracking hat on:
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.

With NTLM to do the same I need the server to send the same challenge - which it won't (out of the box at least). And certainly it
won't after any length of time.

With Digest the URI is part of the calculation of the header, and each authentication header can only be used once because of the
nonce count (duplicate nonce counts result in access denied). Thus the authenication header doesn't let me pretend to be that user.
/hat
>
> > b) the upstream cache's own authentication mechanism gets trodden all over. The point being that we're not doing procy
> > authentication here, we're doing name passing.
>
> In many cases the peer also does authentication and access controls, as
> you describe below.
>
> > AND cannot easily simultaneously authenticate the actual proxy
> > and other users (ie they have a RADIUS based authenticator, that
> > all their local users use. They have to code a special case to
> > detect and authenticate the overloaded proxy case. And we're
> > still extending rfc 2616 - without addressing the core issue.
>
> By using the *@this-cache.com extension, this-cache.com is put in the
> domain of the peer for authentication purposes, but user@this-cache.com
> is used for identification.
Yes. It's a neatish hack doing that,
> And no, we are not extending RFC 2616, or even 2617. The protocols stays
> exacly the same, only the application of the protocols differs. What the
> login= option does is authentication to the upstream, and the method of
> authentication is defined to optionally include the name of the locally
> authorized user.

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

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

http_access deny !proxy_auth
http_access deny downstream_caches !client_username
http_access allow ....

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.

> No, this is not a credentials passing method per se.
>
Agreed.
Received on Tue Jan 09 2001 - 16:16:42 MST