Re: NA - token = fatalf

On 13/02/2013 3:00 p.m., Alex Rousskov wrote:
> On 02/12/2013 06:41 PM, Amos Jeffries wrote:
>> On 13/02/2013 11:33 a.m., Henrik Nordström wrote:
>>> tis 2013-02-12 klockan 14:41 -0700 skrev Alex Rousskov:
>>>> Hello,
>>>> Could somebody with better authentication and helper knowledge clarify
>>>> whether the token field is indeed required for Nagotiate ERR and NA
>>>> responses? If not, can we just remove the above quoted fatalf() blob and
>>>> make the following line conditional on the token presence?
>>> Squid-2 negotiate expects
>>>
>>> NA<SPACE>blob<SPACE>message<NEWLINE>
>>>
>>> but do not require any of them to be present. It accepts
>>>
>>> NA<SPACE><NEWLINE>
>>>
>>> as valid response.
>>>
>>> NTLM is slightly different and do not expect a blob. Simply
>>>
>>> NA<SPACE>message<NEWLINE>
>>>
>>> where message may be blank.
>>>
>>> Regards
>>> Henrik
>>>
>> Squid-3 should be identical. The token is required for Authenticate-Info
>> to supply client with keytab identification in the reponse headers.
> Can you clarify (for those who do not know enough about authentication)
> whether the token is required only if the admin wants some optional
> functionality to work? Like some optional header to be sent by Squid to
> the user? Or is it required for the error page to be reliably displayed
> to the authenticating user at all?
>
> My understanding is that the admin does not want authentication to
> continue in this NA/ERR case.

I'm not sure exactly what it is used for on failures, or if we need to
send it at all. Care to experiment?

 From that and the snippet of RFC 4559 "

If a 401 containing a "WWW-Authenticate"
    header with "Negotiate" and gssapi-data is returned from the server,
    it is a continuation of the authentication request.
"

It does not make any separation between challenge responses or re-try
authenticate states (NA with a token). I am guessing that it could be
used to negotiate acceptible GSSAPI sub-protocols when validation
failure occurs. Or re-start of the authentication session if nonce sent
by the client is broken.

>
>> A
>> missing token= on the Negotiate response normally indicates that an NTLM
>> helper has been wrongly configured on the Negotiate auth interface.
>> Markus' negotiate_wrapper helper presents a dummy token when mapping
>> NTLM responses to Squid.
> I do not know whether this particular helper is misconfigured. And I
> cannot tell by reading the wiki page (for the reasons discussed
> earlier). I believe the helper works OK otherwise. In the NA case, the
> helper returns something like NA NT_STATUS_NO_SUCH_USER *\n
> Is that a valid NA response?

Looks like it should be correct.

Yes .... ERR token="NT_STATUS_NO_SUCH_USER" message="*"

I spy the HelperReply.cc parse() "NA " case is not converting the
responses. AF is doing so, but not NA. Neither is the Negotiate switch
case. This would seem to be the main bug.

IIRC that was left because there was confusion over how to handle
multi-word messages and optional token prefix.

Questions are:
  do we assume that there is no token on NA and send the whole string as
visible error message? The proposed patch will do that.

Do we try to check the first word and see if it is possibly a token and
use it as one when is found?

Or, always assume the first word is a token and send it as one? that
would probably break NTLM so we would have to do it in the Negotiate
swicth case. But would allow us to send the catenated token+message for
error display in case we got it wrong and a FUD token in Negotiate
should not hurt.

... and yes these are blind guess ideas. I have not investigated any
side effects.

> If the token is required for NA/ERR responses, then the helper is broken
> because it does not send one. If the token is not required, then Squid
> is broken because it requires one. Henrik says the token is not required
> [in Squid2].

It seems to be sending token "NT_STATUS_NO_SUCH_USER".

Henrick only said these two were valid:
  NA \n
  NA token message\n

Although I would go so far as to add this one is probably valid also:
  NA token\n

>
>> Yes you can remove these fatal() if you want, but it needs to result in
>> authentication failure
> Will removal of fatal(), as in the posted patch, result in
> authentication failure? I assume it will, but, again, I am not an
> authentication expert.

As done yes it should.

>
>> and squid.conf ERROR messages if you do so.
> Do you mean squid.cache ERROR message? At level 1? Does that imply that
> token is required? I doubt the admin would want tons of ERROR messages
> in the cache.log so they would probably have to fix their helper
> instead. But we should not force them to fix the helper if there is
> nothing wrong with it.

Nix that now.

>
>> The
>> code for triggering all that side-effect is in the BrokenHelper use case
>> which might need to become a separate error handling method. This also
>> goes for the other identical fatal("Unsupported helper response") in
>> Negotiate auth which would be worth removing in the same way.
> Tthis seems to imply that the helper is broken because the token should
> be required in all NA/ERR responses. Is that correct?

Yes. But as I just spotted Squid is not parsing off the token blob
correctly in your test case. So even if the helper is complying it would
appear broken.

Amos
Received on Wed Feb 13 2013 - 03:49:09 MST