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@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/2c42881c056e5ab2e2e14b2f800d6dc720263..., 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.
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/2c42881c056e5ab2e2e14b2f800d6dc720263... https://github.com/dovecot/core/commit/2c42881c056e5ab2e2e14b2f800d6dc720263..., 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.
I found that the problem was already fixed in https://github.com/dovecot/core/commit/d0ea7f9f4530878a40ae0275cf0c36d3ff911.... So, I'm going to wait until the new dovecot release. Thank you for your help!
сб, 26 дек. 2020 г. в 19:59, John Fawcett john@voipsupport.it:
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/2c42881c056e5ab2e2e14b2f800d6dc720263...
< https://github.com/dovecot/core/commit/2c42881c056e5ab2e2e14b2f800d6dc720263... , 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.
participants (2)
-
John Fawcett
-
Михаил Сандаков