Daniel, I have decided to postpone my efforts for this ticket because some other stuff needs to be fixed before I can introduce the desired changes. Anyway, I have figured out the simple root cause of this issue. It happens due to false assumptions. In curl_setup.h, line 627 is assumed that GSS-API suffices to generate a SPNEGO token which is false. You need to change that line to
    <code>#if defined(HAVE_GSSAPI) && defined(HAVE_SPNEGO) || defined(USE_WINDOWS_SSPI)</code>
and it will work only if curl has been compiled with fbopenssl. (as expected)

I will open further tickets for the small issued I have found. The big improvement will happen in a separate ticket. I'd like to keep changes small for now.

---
** [bugs:#1302] HTTP Auth Negotiate sends Kerberos token instead of SPNEGO token**
**Status:** open
**Created:** Wed Nov 13, 2013 12:07 PM UTC by Michael Osipov
**Last Updated:** Sun Dec 22, 2013 07:11 PM UTC
**Owner:** Daniel Stenberg
When a server challenges a client with 'WWW-Authenticate: Negotiate', it expects a SPNEGO token. Unfortunately, curl needs to be compiled with fbopenssl for this. If you compile with GSS-API only it generates a Kerberos 5 token in lib/curl_gssapi.c line 64, NO_OID. This makes the implemenation select a default mech (namely KRB 5).
For HTTP this can be easily patched with something like this: http://code.google.com/p/serf/issues/attachmentText?id=89&aid=890000000&name=serf-spnego.patch&token=_HwqdhFej2jHi5_6V0XTh311VPM%3A1351042419228
My locally patched version works as desired. The function Curl_gss_init_sec_context is used in several spots, so if someone really needs Kerberos instead of SPNEGO another argument for passing the OID is necessary (FTP, SOCKS). With that change, fbopenssl is redundant and can be completely removed.
If not a wrapped SPNEGO token is send, an acceptor can react with:
GSSException: No credential found for: 1.2.840.113554.1.2.2 usage: Accept
        at sun.security.jgss.GSSCredentialImpl.getElement(GSSCredentialImpl.java:577)
        at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:317)
        at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
I have reported the very same issue with Subversion and libserf: http://code.google.com/p/serf/issues/detail?id=89
The SSPI version does not suffer from this because "Negotiate" is passed to AcquireCredentialsHandle.
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.