I'm going back through my mail collecting all the outstanding concerns about HTTP auth, and I see the following side issue from a few months ago that I'd like to follow up on:

> From: curl-library-bounces_at_cool.haxx.se [curl-library-bounces_at_cool.haxx.se] on
> behalf of Steve Holme [steve_holme_at_hotmail.com]
> Sent: Wednesday, May 16, 2012 5:57 PM
> To: 'libcurl development'
> Subject: RE: introduced an auth callback
>
> I must admit I'm not too sure there is a legitimate reason to do it at the
> moment. In the SMTP world a server would typical respond with:
>
> 250-AUTH GSSAPI NTLM LOGIN
>
> I believe the preference is left to right, so if an application supports
> GSSAPI then it should use that, if not then NTLM etc...
>
> Likewise in POP3 a client would issue the AUTH command and the server would
> reply with:
>
> +OK
> GSSAPI
> NTLM
> PLAIN
> .
>
> Again I believe the order is top to bottom - although my Exchange server
> just replied with GSSAPI and NTLM the other way round!!
>
> The current SMTP implementation performs the selection based on what we
> think is the most secure ;-) I think this needs to change to honour what the
> server has told us, however, I'm not too sure whether there is a valid use
> case for an application using curl to override that and say actually, I want
> to use NTLM before GSSAPI (in the above examples).

We would you want to use the order the server lists? In the HTTP world, the standard is to choose the most secure auth available, to guard against broken servers that just return their supported auth methods in random order (say, the order they appear in a config file). I'd be surprised to find that there don't exist broken SMTP servers that put the least secure before the most secure. What value is there in choosing a less secure auth scheme when the server has indicated that it supports a more secure one?

Joe
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

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