Re: New Auth configuration options
"Amos Jeffries" wrote in message
news:6a344dc47f7a230a7cf24e0a5bed7...@treenet.co.nz...
On Sun, 6 Mar 2011 12:39:28 -, Markus Moeller wrote:
"Amos Jeffries" wrote in message
news:4d73721e.4000...@treenet.co.nz...
On 06/03/11 00:46, Markus Moeller wrote:
"Amos Jeffries" wrote in message
news:4d718401.6050...@treenet.co.nz...
On 05/03/11 05:41, Markus Moeller wrote:
Do you have an idea how such a wrapper would work ?
The issue I see is that the wrapper helper must do the same process
management as squid. Which I think is quite some duplication.
Markus
Squid already does the tri-state response handling similarly for
Negoatite and NTLM auth schemes. The blob decoding and response state
is entirely up to the helper.
I think the wrapper just needs to decode the blob and do either NTLM
challenge+validate or Kerberos validate on the result depending on
what detail it gets.
So squid keeps state to which helper instance the NTLM challenge was
send too ?
Yes, and whether there is a challenge pending blocking it from other
uses.
Good
A flag internally to determine that an NTLM validate is the next state
after challenge will be needed to avoid sending NTLM challenge then
validating the follow-up with Kerberos.
I really don't want to program all of that. I just would like to hand
it
over to the existing squid_kerb_auth or ntlm_auth helper after
identification of the blob beeing NTLM or not. But if I hand the token
over squid_kerb_auth or ntlm_auth will get into an endless loop and
won't return to my wrapper.
Does that make sense ?
Nope. Sorry. Is the wrapper calling itself recursively when the first
sub-lookup results in failure?
The only loop I can see is when Negotiate/NTLM challenge-response
arrives. If the wrapper pases it to Kerberos it may have bad
consequences, though I'm not certain. If Kerberos can validate the NTLM
challenge responses safely that simplifies things a lot.
As for programming, we have a libntlmauth library bundled with Squid
which has NTLM decoder functions and "struct ntlmhdr" definitions in it.
Code would be something like:
flag = unset
while(fgets(input)) {
base64decode(input, output);
validation_reply = ntlm_validate_packet((struct ntlmhdr*)output,
);
if (validation_reply && flag != doing_ntlm) {
... get result form kerberos ...
Here I see a problem. I asume I can re-use the existing helpers.
How do I start it and get data to and from it ?
That would be via fork() or vfork() earlier during startup setting up a
pair of pipes to the other helper.
OK. That is what I thought might work.
} else {
flag = unset
... get result or challenge from NTLM ...
Same here.
if result is challenge
flag = doing_ntlm
}
... pass result to squid
}
Amos
Markus
Re: New Auth configuration options
On Sun, 6 Mar 2011 12:39:28 -, Markus Moeller wrote:
"Amos Jeffries" wrote in message
news:4d73721e.4000...@treenet.co.nz...
On 06/03/11 00:46, Markus Moeller wrote:
"Amos Jeffries" wrote in message
news:4d718401.6050...@treenet.co.nz...
On 05/03/11 05:41, Markus Moeller wrote:
Do you have an idea how such a wrapper would work ?
The issue I see is that the wrapper helper must do the same
process
management as squid. Which I think is quite some duplication.
Markus
Squid already does the tri-state response handling similarly for
Negoatite and NTLM auth schemes. The blob decoding and response
state
is entirely up to the helper.
I think the wrapper just needs to decode the blob and do either
NTLM
challenge+validate or Kerberos validate on the result depending on
what detail it gets.
So squid keeps state to which helper instance the NTLM challenge
was
send too ?
Yes, and whether there is a challenge pending blocking it from other
uses.
Good
A flag internally to determine that an NTLM validate is the next
state
after challenge will be needed to avoid sending NTLM challenge
then
validating the follow-up with Kerberos.
I really don't want to program all of that. I just would like to
hand it
over to the existing squid_kerb_auth or ntlm_auth helper after
identification of the blob beeing NTLM or not. But if I hand the
token
over squid_kerb_auth or ntlm_auth will get into an endless loop and
won't return to my wrapper.
Does that make sense ?
Nope. Sorry. Is the wrapper calling itself recursively when the
first sub-lookup results in failure?
The only loop I can see is when Negotiate/NTLM challenge-response
arrives. If the wrapper pases it to Kerberos it may have bad
consequences, though I'm not certain. If Kerberos can validate the
NTLM challenge responses safely that simplifies things a lot.
As for programming, we have a libntlmauth library bundled with Squid
which has NTLM decoder functions and "struct ntlmhdr" definitions in
it.
Code would be something like:
flag = unset
while(fgets(input)) {
base64decode(input, output);
validation_reply = ntlm_validate_packet((struct ntlmhdr*)output,
);
if (validation_reply && flag != doing_ntlm) {
... get result form kerberos ...
Here I see a problem. I asume I can re-use the existing helpers.
How do I start it and get data to and from it ?
That would be via fork() or vfork() earlier during startup setting up a
pair of pipes to the other helper.
} else {
flag = unset
... get result or challenge from NTLM ...
Same here.
if result is challenge
flag = doing_ntlm
}
... pass result to squid
}
Amos
Re: New Auth configuration options
"Amos Jeffries" wrote in message
news:4d73721e.4000...@treenet.co.nz...
On 06/03/11 00:46, Markus Moeller wrote:
"Amos Jeffries" wrote in message
news:4d718401.6050...@treenet.co.nz...
On 05/03/11 05:41, Markus Moeller wrote:
Do you have an idea how such a wrapper would work ?
The issue I see is that the wrapper helper must do the same process
management as squid. Which I think is quite some duplication.
Markus
Squid already does the tri-state response handling similarly for
Negoatite and NTLM auth schemes. The blob decoding and response state
is entirely up to the helper.
I think the wrapper just needs to decode the blob and do either NTLM
challenge+validate or Kerberos validate on the result depending on
what detail it gets.
So squid keeps state to which helper instance the NTLM challenge was
send too ?
Yes, and whether there is a challenge pending blocking it from other uses.
Good
A flag internally to determine that an NTLM validate is the next state
after challenge will be needed to avoid sending NTLM challenge then
validating the follow-up with Kerberos.
I really don't want to program all of that. I just would like to hand it
over to the existing squid_kerb_auth or ntlm_auth helper after
identification of the blob beeing NTLM or not. But if I hand the token
over squid_kerb_auth or ntlm_auth will get into an endless loop and
won't return to my wrapper.
Does that make sense ?
Nope. Sorry. Is the wrapper calling itself recursively when the first
sub-lookup results in failure?
The only loop I can see is when Negotiate/NTLM challenge-response arrives.
If the wrapper pases it to Kerberos it may have bad consequences, though
I'm not certain. If Kerberos can validate the NTLM challenge responses
safely that simplifies things a lot.
As for programming, we have a libntlmauth library bundled with Squid which
has NTLM decoder functions and "struct ntlmhdr" definitions in it.
Code would be something like:
flag = unset
while(fgets(input)) {
base64decode(input, output);
validation_reply = ntlm_validate_packet((struct ntlmhdr*)output,
);
if (validation_reply && flag != doing_ntlm) {
... get result form kerberos ...
Here I see a problem. I asume I can re-use the existing helpers. How do I
start it and get data to and from it ?
} else {
flag = unset
... get result or challenge from NTLM ...
Same here.
if result is challenge
flag = doing_ntlm
}
... pass result to squid
}
"Simples", as the rat said to the piper.
Amos
-Messaggio originale-
Da: Henrik Nordström
ons 2010-04-07 klockan 20:27 +0100 skrev Markus Moeller:
> 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
I would prefer a wrapper helper doing this selection.
Regards
Henrik
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.11
Beta testers wanted for 3.2.0.5
Re: New Auth configuration options
On 06/03/11 00:46, Markus Moeller wrote:
"Amos Jeffries" wrote in message
news:4d718401.6050...@treenet.co.nz...
On 05/03/11 05:41, Markus Moeller wrote:
Do you have an idea how such a wrapper would work ?
The issue I see is that the wrapper helper must do the same process
management as squid. Which I think is quite some duplication.
Markus
Squid already does the tri-state response handling similarly for
Negoatite and NTLM auth schemes. The blob decoding and response state
is entirely up to the helper.
I think the wrapper just needs to decode the blob and do either NTLM
challenge+validate or Kerberos validate on the result depending on
what detail it gets.
So squid keeps state to which helper instance the NTLM challenge was
send too ?
Yes, and whether there is a challenge pending blocking it from other uses.
A flag internally to determine that an NTLM validate is the next state
after challenge will be needed to avoid sending NTLM challenge then
validating the follow-up with Kerberos.
I really don't want to program all of that. I just would like to hand it
over to the existing squid_kerb_auth or ntlm_auth helper after
identification of the blob beeing NTLM or not. But if I hand the token
over squid_kerb_auth or ntlm_auth will get into an endless loop and
won't return to my wrapper.
Does that make sense ?
Nope. Sorry. Is the wrapper calling itself recursively when the first
sub-lookup results in failure?
The only loop I can see is when Negotiate/NTLM challenge-response
arrives. If the wrapper pases it to Kerberos it may have bad
consequences, though I'm not certain. If Kerberos can validate the NTLM
challenge responses safely that simplifies things a lot.
As for programming, we have a libntlmauth library bundled with Squid
which has NTLM decoder functions and "struct ntlmhdr" definitions in it.
Code would be something like:
flag = unset
while(fgets(input)) {
base64decode(input, output);
validation_reply = ntlm_validate_packet((struct ntlmhdr*)output,
);
if (validation_reply && flag != doing_ntlm) {
... get result form kerberos ...
} else {
flag = unset
... get result or challenge from NTLM ...
if result is challenge
flag = doing_ntlm
}
... pass result to squid
}
"Simples", as the rat said to the piper.
Amos
-Messaggio originale-
Da: Henrik Nordström
ons 2010-04-07 klockan 20:27 +0100 skrev Markus Moeller:
> 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
I would prefer a wrapper helper doing this selection.
Regards
Henrik
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.11
Beta testers wanted for 3.2.0.5
Re: New Auth configuration options
"Amos Jeffries" wrote in message news:4d718401.6050...@treenet.co.nz... On 05/03/11 05:41, Markus Moeller wrote: Do you have an idea how such a wrapper would work ? The issue I see is that the wrapper helper must do the same process management as squid. Which I think is quite some duplication. Markus Squid already does the tri-state response handling similarly for Negoatite and NTLM auth schemes. The blob decoding and response state is entirely up to the helper. I think the wrapper just needs to decode the blob and do either NTLM challenge+validate or Kerberos validate on the result depending on what detail it gets. So squid keeps state to which helper instance the NTLM challenge was send too ? A flag internally to determine that an NTLM validate is the next state after challenge will be needed to avoid sending NTLM challenge then validating the follow-up with Kerberos. I really don't want to program all of that. I just would like to hand it over to the existing squid_kerb_auth or ntlm_auth helper after identification of the blob beeing NTLM or not. But if I hand the token over squid_kerb_auth or ntlm_auth will get into an endless loop and won't return to my wrapper. Does that make sense ? "Simples", as the rat said to the piper. Amos -Messaggio originale- Da: Henrik Nordström ons 2010-04-07 klockan 20:27 +0100 skrev Markus Moeller: > 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 I would prefer a wrapper helper doing this selection. Regards Henrik Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.11 Beta testers wanted for 3.2.0.5
Re: New Auth configuration options
On 05/03/11 05:41, Markus Moeller wrote: Do you have an idea how such a wrapper would work ? The issue I see is that the wrapper helper must do the same process management as squid. Which I think is quite some duplication. Markus Squid already does the tri-state response handling similarly for Negoatite and NTLM auth schemes. The blob decoding and response state is entirely up to the helper. I think the wrapper just needs to decode the blob and do either NTLM challenge+validate or Kerberos validate on the result depending on what detail it gets. A flag internally to determine that an NTLM validate is the next state after challenge will be needed to avoid sending NTLM challenge then validating the follow-up with Kerberos. "Simples", as the rat said to the piper. Amos -Messaggio originale- Da: Henrik Nordström ons 2010-04-07 klockan 20:27 +0100 skrev Markus Moeller: > 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 I would prefer a wrapper helper doing this selection. Regards Henrik Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.11 Beta testers wanted for 3.2.0.5
Re: New Auth configuration options
Do you have an idea how such a wrapper would work ? The issue I see is that the wrapper helper must do the same process management as squid. Which I think is quite some duplication. Markus "Guido Serassio" wrote in message news:58fd293ce494af419a59ef7e597fa4e6400...@hermes.acmeconsulting.loc... Hi Henrik, I was thinking about the same thing few minutes ago ... :-) +1 Regards Guido Guido Serassio Acme Consulting S.r.l. Microsoft Gold Certified Partner Via Lucia Savarino, 110098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: guido.seras...@acmeconsulting.it WWW: http://www.acmeconsulting.it -Messaggio originale- Da: Henrik Nordström [mailto:hen...@henriknordstrom.net] Inviato: giovedì 8 aprile 2010 21.47 A: Markus Moeller Cc: squid-dev@squid-cache.org Oggetto: Re: New Auth configuration options ons 2010-04-07 klockan 20:27 +0100 skrev Markus Moeller: > 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 I would prefer a wrapper helper doing this selection. Regards Henrik
R: New Auth configuration options
Hi Henrik, I was thinking about the same thing few minutes ago ... :-) +1 Regards Guido Guido Serassio Acme Consulting S.r.l. Microsoft Gold Certified Partner Via Lucia Savarino, 110098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: guido.seras...@acmeconsulting.it WWW: http://www.acmeconsulting.it > -Messaggio originale- > Da: Henrik Nordström [mailto:hen...@henriknordstrom.net] > Inviato: giovedì 8 aprile 2010 21.47 > A: Markus Moeller > Cc: squid-dev@squid-cache.org > Oggetto: Re: New Auth configuration options > > ons 2010-04-07 klockan 20:27 +0100 skrev Markus Moeller: > > > 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 > > I would prefer a wrapper helper doing this selection. > > Regards > Henrik
Re: New Auth configuration options
ons 2010-04-07 klockan 20:27 +0100 skrev Markus Moeller: > 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 I would prefer a wrapper helper doing this selection. Regards Henrik
Re: New Auth configuration options
On Wed, 7 Apr 2010 20:27:38 +0100, "Markus Moeller" 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
New Auth configuration options
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
