Re: [squid-users] Re: Negotiate/NTLM authentication caching

Markus Moeller wrote:
> I may misunderstood what you said, but there is no caching of
> authentication for Kerberos nor Basic/Digest. I think the TTL you talk
> about is for authorisation.
>
> Markus
>

Quite right.

Amos

> "Khaled Blah" <khaled.blah_at_googlemail.com> wrote in message
> news:4a3250ab1003290408q72ec495an7d04934d527c345d_at_mail.gmail.com...
> Thx a lot for your answer, Amos! You are of course right with your
> concerns towards "IP/TCP caching". Not a very good idea!
>
> Does the same hold true for Kerberos as well, though? I mean could it
> be possible to cache Kerberos authentication in a secure fashion?
>
> Thinking about what you said, I am wondering what the big difference
> is to Basic/Digest authentication. I mean with them squid challenges
> the user as well, the credentials the user's client sends are being
> verified by the authentication helper and that result is cached so
> that when the same user requests anything with the same credentials,
> he or she will not be re-verified with the helper's help until the TTL
> has passed, right? So what am I missing here?
>
> Thx in advance for any insight you can give me on this!
>
> Khaled
>
> 2010/3/28 Khaled Blah <khaled.blah_at_googlemail.com>:
>> Thx a lot for your answer, Amos! You are of course right with your
>> concerns towards "IP/TCP caching". Not a very good idea!
>>
>> Does the same hold true for Kerberos as well, though? I mean could it
>> be possible to cache Kerberos authentication in a secure fashion?
>>
>> Thinking about what you said, I am wondering what the big difference
>> is to Basic/Digest authentication. I mean with them squid challenges
>> the user as well, the credentials the user's client sends are being
>> verified by the authentication helper and that result is cached so
>> that when the same user requests anything with the same credentials,
>> he or she will not be re-verified with the helper's help until the TTL
>> has passed, right? So what am I missing here?
>>
>> Thx in advance for any insight you can give me on this!
>>
>> Khaled
>>
>> 2010/3/28 Amos Jeffries <squid3_at_treenet.co.nz>:
>>> Khaled Blah wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I'm developing an authentication helper (Negotiate/NTLM) for squid and
>>>> I am trying to understand more how squid handles this process
>>>> internally. Most of all I'd like to know how and how long squid caches
>>>> authentication results. I have looked at the debug logs and they show
>>>> that squid seems to do "less caching" for Negotiate/NTLM than it does
>>>> for Basic/Digest authentication. I am wondering whether I can do
>>>> something about this so that a once verified user will only get his
>>>> credentials re-verified after a certain time and not all during. I am
>>>> grateful to any insight the list can give me. Thanks in advance!
>>>>
>>>> Khaled
>>>
>>> NTLM does not authenticate a user per-se. It authenticates a TCP link
>>> to a
>>> some form of account (user being only one type). Squid holds the
>>> authentication credentials for as long as the authenticated TCP link is
>>> open. It challenges the browser on any requests without supplied
>>> credentials, and re-verifies on every new link opened or change in
>>> existing
>>> credentials.
>>>
>>> Caching NTLM credentials for re-use on TCP links from specific IP
>>> addresses
>>> has always been a very risky business. As the world is now moving
>>> further
>>> towards NAT and proxy gateways a single IP address can have multiple
>>> requests from multiple clients. This makes caching NTLM credentials
>>> an even
>>> worse prospect in future than it is now or ever before.
>>>
>>> What we are doing in Squid-3 now is improving the HTTP/1.1 support which
>>> enables TCP links to be held open under more conditions than HTTP/1.0
>>> allows
>>> and thus the length of time between credential checks to be lengthened
>>> without loosing security.
>>>
>>> I can tell you now that any patches to do with caching credentials
>>> will be
>>> given some very strict checks even to be considered for acceptance into
>>> Squid.
>>>
>>> Amos
>>> --
>>> Please be using
>>> Current Stable Squid 2.7.STABLE8 or 3.0.STABLE25
>>> Current Beta Squid 3.1.0.18
>>>
>>
>
>

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.1