Re: "negotiate" auth with fallback to other schemes

On Wed, 24 Feb 2010 17:03:08 +0100, Livio B <lbsqdd_at_gmail.com> wrote:
> 2010/2/23 Henrik Nordström <henrik_at_henriknordstrom.net>:
>>> So the idea is to extend the negotiate helper protocol so that the
>>> helper can specify that its auth mechanism should no longer be offered
>>> to the client (this might be useful for other mechanisms too). This
>>> way it would be up to the helper to decide if its scheme should be
>>> reiterated or not.
>>
>> I would say this fits better as an auth_param setting. Both Negotiate
>> and NTLM protocols has a clear "Authentication has failed due to
invalid
>> credentials" message (NA ....).
>
> Yes however, whether the client should get prompted again can make
> sense (or not) regardless of the type of the returned message (NA, BH,
> AF...).
> For example, even when kerberos auth succeeds (AF message), still
> squid acls can deny access to that authenticated user. And the helper
> has no way to know that. Depending on the scenario, it may make sense
> to prompt the user again or not.
> In particular, if I want only transparent auth, it wouldn't make sense
> to retry the authentication because either the helper would get the
> same SSO (denied) credentials or the user would get prompted (which I
> don't want). On a different scenario, where it is ok to prompt the
> user for alternative credentials, it would make sense to retry the
> negotiate.
>
>> Why do the helper need to decide if the user should be prompted again?
>> In which cases should the user get prompted again for Negotiate or NTLM
>> after incorrect authentication?
>
> I'm not sure: at the moment I cannot think of cases where the helper
> decision cannot be taken beforehand as an auth_param.
> However letting the helper decide seems more dynamic and allows for
> decisions based on the answer from the client, something that wouldn't
> be possible with auth_param. Also letting the helper decide wouldn't
> require a change to auth_param syntax (possibly breaking backward

auth_param can be extended without many compatibility worries.

> compatibility) tough it clearly requires a small protocol extension.
>
>>> My main doubt is where to keep the information about "disabled"
>>> schemes. In my current test I keep a list of "still active" auth
>>> schemes in the HttpRequest object. However the problem with this is
>>> that the httprequest object is (seems to be) freed as soon as the
>>> connection is closed. Therefore this works only for the first auth
>>> reiteration, that is, this is what can happen:
>>
>> Simplest is to add a per-connection flag indicating that connection
>> oriented auth (NTLM / Negotiate) should not be used for this
connection.
>
> This seem a little unflexible. For example, currently there is no
> helper that can handle both negotiate/kerberos and negotiate/ntlm so
> if I need to support both I need a negotiate helper and a NTLM helper
> and might want to disable just one. And of course new protocols can
> eventually surface.

Whenever NTLM or Kerberos credentials are sent over a TCP connection. The
entire connection (through every single proxy hop along the way) changes
its authentication credentials. These credentials may be spread and cached
across the whole Internet in order to authenticate with one remote server.

All other authentication methods only authenticate a specific part of the
link between a server and client. Credentials are not passed outside the
current administrators security zone.

(You start to see why security people don't like NTLM stuff?)

What would be nice is that if the Kerberos libraries received NTLM input
they should handle it as NTLM instead of immediately rejecting it. When
that happens the Squid kerberos helper (or an extended one) should be able
to handle both auth methods without re-challenging.

If you know of any way thats possible today, please get in touch with
Marcus the negotiate/Kerberos helper author. I know he has a lot of people
annoying him with questions when they inadvertently configure NTLM thinking
its Kerberos.

Amos
Received on Wed Feb 24 2010 - 22:20:17 MST