Re: New Auth configuration options

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 08 Apr 2010 02:23:01 +0000

On Wed, 7 Apr 2010 20:27:38 +0100, "Markus Moeller"
<huaraz_at_moeller.plus.com> wrote:
> Hi,
>
> Would it make sense to define in squid two new configuration options to

> control Negotiate authentication ? I am thinking of adding
>
> Negotiate-NTLM
>
> and
>
> Negotiate-Kerberos
>
> with the same options as Negotiate. Once squid receives a Negotiate
> response
> quid has to base64 decode the token and check for the NTLM string before

> invoking the Negotiate-NTLM or Negotiate-Kerberos helper.
>
> Does that break a concept in squid to analyse a token before selecting
the
> helper ?
>
> Thank you
> Markus

I agree with the principle.

Are you thinking having them as separate schemes?

There would be a fair bit of coding needed to split the one scheme into
two helper backends and to have simultaneous modules with the same scheme
name.

I can see three ways the auth config may be extended:
 As new base schemes "auth_param negotiate-kerberos" "auth_param
negotiate-ntlm"
     (minor copy-paste of files and documentation)
 or as helper flags "auth_param negotiate kerberos ntlm"
     (maybe a maor re-write needed)
 or a new "kerberos" scheme (replacing negotiate scheme) and new
"negotiate" flags to both kerberos and ntlm schemes
     (somewhat largish code changes to existing negotiate code to simplify
it down to a decode wrapper)

This last is only possible if Negotiate-NTLM has the same keys and
sequence of round-trip keys as NTLM. Then the "negotiate" flags to kerberos
and ntlm schemes can be used which permits the "Negotiate" pseudo-scheme to
be advertised and unwrap-checked before passing the wrapped key to
whichever the real backend scheme is.

There are a few other things affected by this proposal:
 * proposals for ACL control of which schemes are presented to clients in
the challenge.
 * the helper renaming, since the scheme name is now sync'd with the
helper filename and location.

NP: also I'm putting a blocker on any major auth changes internal to Squid
until the leakage bugs are resolved.

Amos
Received on Thu Apr 08 2010 - 02:23:06 MDT

This archive was generated by hypermail 2.2.0 : Thu Apr 08 2010 - 12:00:06 MDT