Re: SASL LOGIN mechanism
On 02/14/2018 09:04 PM, Ray Satiro wrote: Obviously the server does not require the password because the client certificate authentication takes precedence; the AUTH command is however needed before being able to use other commands. This looks like a deviance from the description (https://tools.ietf.org/html/draft-murchison-sasl-login-00), that has been written "a posteriori" (probably by reverse engineering) and has not become a standard. This document does not describe the case when the password is not needed. Interesting. If it's EXTERNAL then aren't you already logged in? No, you're not. Servers that allow EXTERNAL should receive an explicit AUTH EXTERNAL command to be logged in. This server does not support EXTERNAL, but behaves as such with other authentication methods (this is quite clever since many clients do not support EXTERNAL). Where is LOGIN prioritized over PLAIN and is there any effect of that on this issue? Priority is determined by the order of "else if" blocks starting at https://github.com/curl/curl/blob/43a50a2580db2bfb28483a96964ae27b584472da/lib/curl_sasl.c#L292. The only effect would be PLAIN will be chosen by curl instead of LOGIN if both are supported by the server. This does not impact the "no LOGIN password" problem, but will avoid using LOGIN if PLAIN is available. --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: SASL LOGIN mechanism
On 2/13/2018 7:48 PM, Patrick Monnerat wrote: > I've recently been facing a special case: a pop3 server (dovecot) with > a TLS-upgraded connection and client certificate does not require the > password when the LOGIN authentication mechanism is used, effectively > behaving as if it was an EXTERNAL authentication. > > > AUTH LOGIN > < + VXNlcm5hbWU6 > > dXNlcg== > < +OK Logged in. > > Obviously the server does not require the password because the client > certificate authentication takes precedence; the AUTH command is > however needed before being able to use other commands. This looks > like a deviance from the description > (https://tools.ietf.org/html/draft-murchison-sasl-login-00), that has > been written "a posteriori" (probably by reverse engineering) and has > not become a standard. This document does not describe the case when > the password is not needed. Interesting. If it's EXTERNAL then aren't you already logged in? I'd ask dovecot team if that's what they intended. > > Currently, curl stops with CURLE_LOGIN_DENIED, treating the positive > response as bad because a continuation is unconditionally expected. > > Should we support this ? If yes, the fix is ready. > > > In addition I would set the LOGIN mechanism a lower priority than the > PLAIN one, as advised in the document mentioned above. > > OK for these changes ? Where is LOGIN prioritized over PLAIN and is there any effect of that on this issue? --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
SASL LOGIN mechanism
I've recently been facing a special case: a pop3 server (dovecot) with a TLS-upgraded connection and client certificate does not require the password when the LOGIN authentication mechanism is used, effectively behaving as if it was an EXTERNAL authentication. > AUTH LOGIN < + VXNlcm5hbWU6 > dXNlcg== < +OK Logged in. Obviously the server does not require the password because the client certificate authentication takes precedence; the AUTH command is however needed before being able to use other commands. This looks like a deviance from the description (https://tools.ietf.org/html/draft-murchison-sasl-login-00), that has been written "a posteriori" (probably by reverse engineering) and has not become a standard. This document does not describe the case when the password is not needed. Currently, curl stops with CURLE_LOGIN_DENIED, treating the positive response as bad because a continuation is unconditionally expected. Should we support this ? If yes, the fix is ready. In addition I would set the LOGIN mechanism a lower priority than the PLAIN one, as advised in the document mentioned above. OK for these changes ? Patrick --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html