[squid-dev] [RFC] How would you call this "authentication" way?(a bit long)

[Eliezer Croitoru]

After playing with couple SSO ideas in general I noticed that something 
similar can be done with squid while it will not be as secured as 
kerberos and couple other nice implementation.

Deatils:
A transparent proxy cannot authenticate users in the session level. The 
current known available options are using some session db(by IP) or 
Radius or LDAP(by ip) and couple others.
So for couple specific environments which uses either NAT or multiple 
VNC\RDP sessions there is no option to authenticate a specific user but 
a whole IP\machine.

The real solution would be to somehow make it possible for a browser to 
know about the option of a "transparent proxy" and to also trust it. 
Also this specific network must be secured enough so no rough dhcp 
services will pop up and couple other network level restrictions will be 
applied to ensure that the browser can authenticate to the proxy in the 
case he will be there.(There might be some other attacks which I didn't 
mentioned)

Another approach to the issue:
Currently browsers use cookies to authenticate banks, police, health and 
many other systems. They are not highly secured but they are being used 
in many places.

Maybe we can use them for something?
Since the first days of cookies security restrictions was applied on 
them to disable phishing, impersonation etc.
Many vendors "secure" the cookies based on user-agent string, 
timestamps, origin ip and many others. These in very specific cases can 
make it somehow harder on the cookie finder to use them but it still 
might not be enough for many systems.

OK so cookies are not 100% secure but as long as my network is under my 
"total" control and nobody can use tcpdump\wireshark on the client whole 
machine without privileges or some attack can force a network flood it 
would be kind of safe to use some cookies on some machines\clients.

What I was testing is a setup like this(which I don't know how to call 
if at all):
- Linux router with squid in intercept(ssl-bump)
- Linux machine ICAP service
- Linux machine HTTPs\AUTH service
- Linux machine Shared ram DB service
- A Client with a browser(Firefox\IE\Chrome\Opera\Safari etc)

The client is expected to be authenticated to the AUTH service.
On every http request(to wan) the ICAP service checks for a specific 
TOKEN-COOKIE.
If the TOKEN-COOKIE exists it validates the TOKEN VS the DB and if 
cleared for this specific IP and maybe other properties the TOKEN-COOKIE 
is being stripped from the request and the client request is being 
passed to the origin server and the ICAP service returns to squid the 
request authenticated users.
In the other case which either the TOKEN-COOKIE is not present or 
invalid the ICAP service is redirecting the client to the AUTH service 
page with a special REDIRECTION-TOKEN.
If the user was not authenticated to the AUTH service he will be asked 
to enter credentials.
When the user press LOGIN the user is being sent an authentication 
cookie and receives a redirection with a TOKEN(which can be stored in 
the DB) to the original request page.
If the browser has a valid AUTH cookie he will be identified and 
redirected automatically without the need to enter any credentials.
Then the ICAP service can verify who the user is and if the TOKEN is 
valid and the user is being redirected to the original request page with 
a Set-Cookie which contains the TOKEN-COOKIE for this specific domain.
Now this domain and all it's sub-domains requests will contain the 
TOKEN-COOKIE which the ICAP service will clear any request to them until 
some per-defined cookie expiration property or auto detected cookie abuse.

The above "idea" is being implemented in many SSO systems but in this 
specific use case it's being done on the whole Internet HTTP and HTTPS 
traffic.
It has couple attacks vectoring points and also lots of "holes" such as 
non bumpable HTTPS traffic.
It's not an alternative to simple forward proxy settings in browsers and 
gives really bad time to POST requests but it works for many simple use 
cases.

But, how would you call this kind of proxy authentication? "cookie" 
based? "token" based? SSO?? "cookie bearer" ? ideas?

Thanks,
Eliezer