Hi Steve / all, On Mon, Feb 9, 2015 at 11:37 PM, Steve Holme <[email protected]> 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
