On Wed, 7 Apr 2010 20:27:38 +0100, "Markus Moeller"
<hua...@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
