Re: [SQU] Authenticate problem:

Ok,
    with the basic scheme code this race window still exists. For NTLM it is irrelevant as every query requires a response from a
helper to 'prime' the challenge-response cache for each username/helper pair. For Digest the window is not present (I have
implemented the request/user distinction I mentioned before. When I push this back up to the auth_rewrite branch the basic scheme
will have the window removed.

The cache will not get multiple entries in the current code, or in the auth_rewrite branch.

The original flow was basically

Decode the header,
check the cache
pass to the helper
read reply
decode the header
check the cache
add to the cache.

The rewritten branch will not get multiple entries either. It's flow is (loosely)
Check for a cached header,
If not Decode
pass to helper if needed
read reply
check the cache
add to the cache.

I had removed the credential ttl (I misinterpreted it as a ttl on the cache entry, not a ttl on the credentials validity. I have
reimplemented this for the basic scheme. There is an equivalent function for NTLM (challenge reuses limit). Digest doesn't have any
such thing currently, and I'll probably put one in. However until we have trailers implemented in client_side I cannot complete
Digest anyway..

authenticate_ip_ttl's normal soft mode?
I currently drop the old IP (as discussed). What really needs to happen is a list of credentials per ip per username. Then we simply
add the ip/credentials pair to that list. The hard mode then limits that to one entry in the list at any one time. I'll look at
putting this into the generic code, and if I can't then maybe it can go on the wishlist?

>In strict ip_ttl mode the requests from other IP's are always denied
>until the TTL have expired.

This should be working at the moment (I still have the check code in place).

Rob

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Saturday, December 23, 2000 11:07 AM
Subject: Re: [SQU] Authenticate problem:

Re: [SQU] Authenticate problem:Robert Collins wrote:

> > Hmm.. maybe there are a proxy_auth cache defiency there. In theory the
> > first request carrying the new passphrase would be sent to the
> > authenticator, but maybe all are until the authenticator returns. Need
> > to check the code on this.
>
> The Auth_rewrite branch should have this fixed as a 'freebie'. I'll check
> when I get fully back on deck. If not then then it will be trivial to fix
> in auth_rewrite.

Ok. I'll await your investigation, but in the current code (not
auth_rewrite) there surely is a window between the first query and the
result where additional requests will spawn additional validations, and
probably even cause duplicate entries in the cache.

> > > > authenticate_ip_ttl
> > >
> > > 3600
> >
> > This might also be one source if the same userid tried to access Squid
> > from two or more different IP's.
> >
>
> This is fixed in auth_rewrite. We compare the passwords. in memory without an external trip.

So how do you implement authenticate_ip_ttl's normal soft mode where the
user is meant to be required to reauthenticate each time he/she switches
IP within the TTL?

In the normal code this is done by forgetting the cached credentials
each time a switch is detected, AND to reject the request with
"authentication required". This way the user can switch IP with only a
minor annoyance, but if two IP's tries to use the same user then things
will get really annoying for the user.

Hmm.. could of course change it to simply change the IP instead of
dropping the cache entry.. probably a good idea.

In strict ip_ttl mode the requests from other IP's are always denied
until the TTL have expired.

/Henrik
Received on Mon Jan 01 2001 - 04:44:58 MST