dovecot - Dec 2020 - AUTH command behaviour when authentication process failed or aborted by user is changed

Hi all,

I have tried to update from 2.3.10.1 to 2.3.11.3 and found some strange
change of dovecot behaviour at pop3 authentication.
Firstly this changes have been found by my tests with curl. But this can be
simply reproduced with telnet too.

On version 2.3.10.1 when authentication is failed or aborted by client,
client can send "AUTH [auth method]" to retry authentication with the
same
or another authentication method. Example of client <-> server
conversation:
server <<< +OK Dovecot ready.
client >>> AUTH DIGEST-MD5
server <<< [some_auth_data]
client >>> *
server <<< -ERR Authentication aborted by client.
client >>> AUTH CRAM-MD5
server <<< [another_auth_data]

But on version 2.3.11.3 in the same cases client must send only "auth
method" without "AUTH". Example of successful conversation on
this version:
server <<< OK Dovecot ready.
client >>> AUTH DIGEST-MD5
server <<< [some_auth_data]
client >>> *
server <<< -ERR Authentication aborted by client.
client >>> CRAM-MD5
server <<< [another_auth_data]

And example of what happens if a client will try to do that in an old way
on version 2.3.11.3:
server <<< OK Dovecot ready.
client >>> AUTH DIGEST-MD5
server <<< [some_auth_data]
client >>> *
server <<< -ERR Authentication aborted by client.
client >>> AUTH CRAM-MD5
server <<< ERR [AUTH] Unsupported authentication mechanism.

As you can see dovecot tries to find an authentication method by string
"AUTH" not by "CRAM-MD5".

This change looks strange to me. And changes break curl, because it uses an
old way to make authentication. To reproduce it with curl you can just do
something like:
[user at 10.52.48.220]# curl -u [user]:[password] --verbose
pop3://[dovecot-host]

Also seems like new behaviour is not fully accorded to rfc1734 (
https://tools.ietf.org/html/rfc1734). Based on this part of rfc:
"If an AUTH
 command fails with a negative response, the session remains
 in the AUTHORIZATION state and client may try another
 authentication mechanism by issuing another AUTH command,
 or may attempt to authenticate by using the USER/PASS or
 APOP commands."
I think "AUTH command" means full auth command started with
"AUTH", not
only authentication method. But I may be wrong in the interpretation of
this part.

I suppose this changes was made in commit
https://github.com/dovecot/core/commit/2c42881c056e5ab2e2e14b2f800d6dc72026399b,
but not sure about this. Seems like if authentication is aborted or failed
client->current_cmd is not going to be cleaned.

So I suggest to revert old behaviour in this cases. If I am right with
commit, it seems like we just need to add clearing client->current_cmd if
the authentication process has failed somehow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20201224/867889f4/attachment.html>

On 24/12/2020 08:42, ?????? ???????? wrote:
> Hi all,
>
> .....
>
> Also seems like new behaviour is not fully accorded to rfc1734
> (https://tools.ietf.org/html/rfc1734
> <https://tools.ietf.org/html/rfc1734>). Based on this part of rfc:
> "If an AUTH
> ?command fails with a negative response, the session remains
> ?in the AUTHORIZATION state and client may try another
> ?authentication mechanism by issuing another AUTH command,
> ?or may attempt to authenticate by using the USER/PASS or
> ?APOP commands."
> I think "AUTH command" means full auth command started with
"AUTH",
> not only authentication method. But I may be wrong in the
> interpretation of this part.
>
Your reading of the RFC looks correct. AUTH commands start with the
string "AUTH". This is no different after a negative response.

John
> I suppose this changes was made in commit
>
https://github.com/dovecot/core/commit/2c42881c056e5ab2e2e14b2f800d6dc72026399b
>
<https://github.com/dovecot/core/commit/2c42881c056e5ab2e2e14b2f800d6dc72026399b>,
> but not sure about this. Seems like if authentication is aborted or
> failed client->current_cmd is not going to be cleaned.
>
> So I suggest to revert old behaviour in this cases. If I am right with
> commit, it seems like we just need to add clearing client->current_cmd
> if the authentication process has failed somehow.