On Sun, 8 Feb 2015, Isaac Boukris wrote:

> When the app sets CURLOPT_HTTPAUTH to CURLAUTH_NEGOTIATE
> (e.g. using curl --negotiate) it first sends an empty request and receives
> a 401 unauthorized before invoking GSS-API to the 'Negotiate
> Authorization' header.

Thank you for your email and associated patch / fix - it is much appreciated.

> This is different from the behavior of NTLM and Basic and seem
> unnecessary unless one set CURLAUTH_ANY (curl --anyauth) or any other
> 'set' of auth options.

Whilst I'm familiar with most of the authentication mechanisms supported by curl I tend (although have performs some fixes / tidy ups / re-arrangement of code for our HTTP authentication routines) to have a SASL focus.

I was aware that basic did this but not that NTLM did and SPNEGO didn't.

> Also, it doesn't seem to have been the initial intention - see this quote from
> the comment in the source (http.c): "Then we set the picked one to the want
> one, and if this is one single bit it'll be used instantly."

From my knowledge in this area that doesn't seem quite right and if we can save an extra round trip, and it is valid to do so, then great ;-)

> In fact, this causes a funny bug when using CURLAUTH_ANY and the server
> sends 'Negotiate' there would be two 401 response before it starts to send
> the 'Negotiate Authorization' header.

:(

> I've been working this weekend on the attached patch, with these changes
> most of the logic is done at 'Curl_output_negotiate' instead of
> 'Curl_input_negotiate' which only takes server's answer. It saves the extra
> round trip when using Negotiate (either explicitly or in CURLAUTH_ANY flow)
> and aligns the behavior with other protocols.

Cool - I'll try and take a look at your patch in more detail over the next few days.

> I've run quite several tests (with valgrind) of NTLM and Kerberos with Heimdal
> Kerberos GSSAPI library (also tested NTLM inside Negotiate with Heimdal's
> NTLMSSP).

Was that your own tests or did you run the curl Test Suite?

> Note, I noticed some recent changes in 'http_negotiate.c', so I've updated my
> source and adapted my changes but I encounter some errors which I could not
> reproduce later.
>
> When investigating, I noticed the new code seem not to add '+1' to
> 'spn_token.length' compare to the old code.

That might have been me :( but which commit are you referring to?

> I'd be happy to get feedback such as comments and corrections and to
> eventually get this fix integrated into libcurl project.
>
> Note, just before sending I noticed these changes would probably impact
> on 'http_negotiate_sspi.c' as well... I'll look at it if necessary.

Yes - It will probably need fixing there to - however, it is worth noting that:

I wanted to align the SPNEGO GSS-API and SSPI code for the next release, but it was dependent on a little rework of the authentication code for HTTP and SASL and unfortunately I ran out of time for v7.41.0. In that respect I only managed to align the return codes in these functions :(

As such I want to move SPNEGO code from HTTP into the new authentication module. This module will then allow the GSS-API code and SSPI based code to be called from a single HTTP source module, for example, the current http_negotiate.c (Just as the "NTLM" mechanism is called for HTTP and SASL and the "GSSAPI" mechanism for SASL).

Given this, would you prefer to attempt a fix in the SSPI code, fixing both at the same time, or wait for my changes in March which should mean a single fix?

Kind Regards

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-02-09