RE: [PATCH] SF bug #1302: HTTP Auth Negotiate sends Kerberos token instead of SPNEGO token
Date: Mon, 14 Jul 2014 22:27:23 +0100
On Mon, 14 Jul 2014, Michael Osipov wrote:
> > I would be interested to know what aspects of SASL you were
> > referring to and any other thoughts/suggestions you have on
> > the topic.
> As far as I can see, curl_sasl.c implements SASL-based auth itself.
It does. I tried to take some of the authentication mechanisms that we already supported in SMTP, adding NTLM from the HTTP code in the process and centralising them for use with the other email protocols - We also obtained Digest-MD5 support over the course of my modifications as well. However, my apologies that the NTLM, HTTP and SASL code is still a little disjointed at the moment.
> As far as I am acquiant with SASL, there are already good working
> implemenatations which implements all known mechs like Digest,
> Kerberos, Plain etc.
I'm certainly no expect in this field, and I'm still learning, but maybe with the help of yourself, David W, Marc H and others, which from what I've gathered have expertise in this area, I think we could complete and better structure the authentication layer in curl.
> In Windows you have this , though I never figured out how this
> works o the client side. On Unix you have Cyrus SASL, etc. That's
> what I have tried to say.
For libcurl I would like to give the programmer the choice of what library they use for authentication... They may be interfacing with CyrusSSL, Windows SSPI or GNU SASL in other areas of their application or maybe they just don't care and just want libcurl to implement it natively ;-)
I've only really used Windows SSPI for NTLM and Digest myself, and then recently reviewed the HTTP negotiate code off the back of the recent username/password issue that Leonardo reported.
From the article you mentioned, I'm not sure how the SASL functions fit into the picture at the moment and how they are differ to Digest for example which I understand to a SASL mechanism but I hope to get up to speed over the coming weeks/months.
> Let's take the curl LDAP code for instance, it obviously uses native
> Windows code or OpenLDAP where both already can use SASL
> underneath if you performs SASL bind but that code does only a
> simple bind. Leaving all SASL features behind. Options like --digest,
> --ntlm, --negotiate do not work basically.
Unfortunately yes - that is something I would like to sort out once I've finished off some of my work in the email protocols - I would like to see support for GSSAPI (the mechanism) in there first ;-)
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2014-07-14