Authentication: Basic, Digest, NTLM, IP, whatever.

[to all who is concerned with authentication]

Andy Doran wrote:

> Here's a diff against 2.2.STABLE5 for basic NTLM support. Please note that
> this is isn't something I would even consider releasing, some of it
> doesn't even work. It's more of a mockup:
>
> http://dns1.sports.gov.uk/squid-ntlm-patch.gz

Your explanation earlier and the code has now allowed me to get a fair
understanding of the NTLM authentication sheme. Next step would be to
figure out how to correctly fit this in Squid...

Things to note:

* Most people interested in NTLM authentication want to do so against a
domain controller of some kind. Then the challenge must be generated by
the domain controller, not Squid, else there is no way to forward the
authention to the domain controller.

* NTLM can be useful even without domain controller capability if you
can accept some security-by-obscurity. Squid can "easily" fetch the
logged in username from a faked NTLM authentication session.

* NTLM authentication can only be done on a persistent connection by
design (NTLM uses randomly generated challenges). This applies both to
the client->squid connection and squid->domain login controller
connection, so it effectively requires an per connection persistent
associaion client->squid->domain login controller session.

One approach would be to simply add the NTLM+RPC code to Squid, but it
is a fairly large chunk of code needed, and I am not aware of any
non-blocking implementation of the DCE-RPC (or whatever the RPC used by
SMB/LM/CIFS is called) freely available.

The approach I am leaning towards is some more generalized approach to
authentication with (for NTLM) sticky authenticators on a per client
connection basis. The idea is to find a authenticator module method
suitable for all three commonly used authentication methods (Basic,
Digest, NTLM). Squid should only concern itself with the minimal
decoding required to find the username, and caching of authentication
responses. The rest should be handed off to the authenticator (probably
as-is). I have yet to study some of the details of Digest authentication
to find out what requirements that makes on Squid, so this picture may
be slightly revised..

There is also need for a user-group concept. In some cases this can be
joined with the authenticator, in other cases the need is separately on
a per group basis. What I am leaning towards on this issue is to have
two acl types:

auth_group: Membership indicated by the authenticator process.

group: Membership queried by a per group+username(or ident)+ip basis wia
external helpers.

A third concept missing from Squid is divided user spaces, where one
segment of the network is one domain of users and another segment is
another domain of users. The way I see this solved is to add a
authentication class directive, and have the authentication made and
cached within that class.

auth_class company1 src 10.0.1.0/24 192.168.1.0/24
auth_class company2 src 10.0.2.0/25 192.168.2.0/24

This can also be generalized to have classes where authentication is
unique on a IP basis
auth_class specialclass* src 192.168.3.0/24
where speciallclass* is a psuedo class with one unique class per IP
within that range, all named specialclass in access checks outside the
authentication.

The one ip per user limit I introduced earlier would be effective within
each unique auth_class.

/Henrik
Received on Tue Dec 14 1999 - 16:45:28 MST