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

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

"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
>>
>
Received on Mon Mar 29 2010 - 21:12:36 MDT