Hi Steve / all,

On Mon, Feb 9, 2015 at 11:37 PM, Steve Holme <steve_holme_at_hotmail.com> wrote:
> On Sun, 8 Feb 2015, Isaac Boukris wrote:
>
>> 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?

I've started working on the SSPI code but made a step back due to
additional concerns.
As it gets complicated, I would actually rather wait for your updates
and possibly attempt a fix later on (as necessary).

Some of the issues and questions I ran into:
- The state machine design in http_negotiate isn't quite clear (e.g.
GSS_AUTHRECV is set but not used).
- It seem the server sends a last www-authenticate with the 200 "ok"
response, is that for for mutual auth? is it being read?.
- Difference between SPNEGO and SSPI when user-pass are provided by the app.
- Best way to cleanup properly at any given flow (without lots of
duplicate lines).

But the most confusing question was about subsequent requests on the
same TCP session (with keep-alive).
At first I was persuaded that Negotiate authenticates the session
(same as NTLM), so I was concerned my change will cause unnecessarily
sending the Authorization header.
However, when I tried to 'fix' it the server (MS 2k3) denied the
subsequent requests (without authorization header)... but that only
happened when Negotiate used Kerberos inside and not when NTLMSSP was
negotiated.

So the initially suggested change would improve the behavior when
Kerberos is negotiated as it will send the Authorization header on
each request (without the change a 401 will be returned again) while
it would degrade when using NTLM inside Negotiate (although NTLM
support in GSSAPI is currently rare on Linux).

But it isn't the end of the story, apparently MS servers can support
session-based authentication with Kerberos as well by toggling a
server side parameter (authPersistNonNTLM).
The server will inform the user-agent of this support by sending a
special header "Persistent-Auth" set to "true" (NTLM is persistent
regardless, both inside Negotiate or by it self).

Based on the research so far here's what seem the best scheme:
- If auth is not yet picked (more than one auth enabled) send an empty
request and pick one auth.
- When Negotiate is picked, call 'gss_init_sec_context' immediately
and send authorization header.
- Provide 'gss_init_sec_context' with the 'out' parameter
'actual_mech_type' and set a boolean 'persist_auth' in 'neg_data'
according to NTLM or Kerberos.
- When the negotiation completes successfully, if 'persist_auth' is
'false' then check for the "Persistent-Auth" HTTP header and if exists
and 'true' set 'persist_auth' to 'true'.
- For subsequent requests on the same TCP connection, only set
authorization header if 'persist_auth' is set to 'false' (need to call
'gss_init_sec_context' ?)

This is based on several MS documentation pages and blogs post, for instance:
https://msdn.microsoft.com/en-us/library/ee393311.aspx

So I'll currently watch for changes in this area of libcurl while
continuing to investigate and test.
Once I get something worth sharing I'll post it to the mailing list.

Any feedback and assistance on the matter would be appreciated.

Thanks for reading,
Isaac B.

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