Re: [Dovecot] [PATCH, RFC] add APOP authentication mechanism
On 1.7.2004, at 16:26, Andrey Panin wrote:
if (strcmp(auth_request->protocol, "POP3")) {if (verbose)i_info("apop(%s): wrong protocol %s",auth_request->protocol);mech_auth_finish(auth_request, NULL, 0, FALSE);return TRUE;}I don't think there's really any point in checking this? Maybe someone really wants to use APOP with another protocol :)
This will be RFC violation isn't it ?
(I'll send a public reply, the last question could need input from others)
Well, it's not compatible with any RFC of course, but I don't think it would violate anything? I'd just rather like to avoid unnecessary code bloat.
Well, except now that I thought about the logic instead of just the code, there are problems. APOP prevents replay attacks by sending different timestamp in greeting, but you're sending the greeting to dovecot-auth as user input to APOP authentication mechanism. So, a user could simply say "AUTH APOP" and send wanted timestamp as input.
One way to fix this would be to disallow APOP mechanism to be used with AUTH command in pop3-login and require that the request was done with POP3 protocol. But I think that's pretty ugly kludge. It also requires that processes connecting to dovecot-auth are trusted, which is something I've tried to avoid as much as possible. So dovecot-auth doesn't really know if it's pop3-login which connects to it..
Better fix would be to get part of the timestamp from dovecot-auth itself. It could send a growing ID number as handshake which would be used as part of the timestamp, and APOP mechanism processing would check that timestamp really contains the ID. So timestamp would be <authid.unixtime@hostname>. That also makes the PID go away, which was another thing I would have suggested.
POP3 RFC also says:
It is conjectured that use of the APOP command provides origin
identification and replay protection for a POP3 session.
Accordingly, a POP3 server which implements both the PASS and APOP
commands should not allow both methods of access for a given user;
that is, for a given mailbox name, either the USER/PASS command
sequence or the APOP command is allowed, but not both.But I don't know if there's any nice way to do it, except perhaps by defining APOP password scheme which would actually be plaintext but wouldn't work with anything but APOP authentication. Do any other servers prevent it either?
On 183, 07 01, 2004 at 05:39:07PM +0300, Timo Sirainen wrote:
On 1.7.2004, at 16:26, Andrey Panin wrote:
if (strcmp(auth_request->protocol, "POP3")) {if (verbose)i_info("apop(%s): wrong protocol %s",auth_request->protocol);mech_auth_finish(auth_request, NULL, 0, FALSE);return TRUE;}I don't think there's really any point in checking this? Maybe someone really wants to use APOP with another protocol :)
This will be RFC violation isn't it ?
(I'll send a public reply, the last question could need input from others)
Well, it's not compatible with any RFC of course, but I don't think it would violate anything? I'd just rather like to avoid unnecessary code bloat.
AUTHNTICATE APOP will not work in IMAP session anyway because it doesn't pass initial responce required for APOP, so looks like this check is not really necessary.
Well, except now that I thought about the logic instead of just the code, there are problems. APOP prevents replay attacks by sending different timestamp in greeting, but you're sending the greeting to dovecot-auth as user input to APOP authentication mechanism. So, a user could simply say "AUTH APOP" and send wanted timestamp as input.
Hmm, this is really bad.
One way to fix this would be to disallow APOP mechanism to be used with AUTH command in pop3-login and require that the request was done with POP3 protocol. But I think that's pretty ugly kludge. It also requires that processes connecting to dovecot-auth are trusted, which is something I've tried to avoid as much as possible. So dovecot-auth doesn't really know if it's pop3-login which connects to it..
Better fix would be to get part of the timestamp from dovecot-auth itself. It could send a growing ID number as handshake which would be used as part of the timestamp, and APOP mechanism processing would check that timestamp really contains the ID. So timestamp would be <authid.unixtime@hostname>. That also makes the PID go away, which was another thing I would have suggested.
Can't say something valuable here. I didn't explored pop3-login and dovecot-auth interaction deeply.
POP3 RFC also says:
It is conjectured that use of the APOP command provides origin identification and replay protection for a POP3 session. Accordingly, a POP3 server which implements both the PASS and APOP commands should not allow both methods of access for a given user; that is, for a given mailbox name, either the USER/PASS command sequence or the APOP command is allowed, but not both.
Yeah, I read this RFC part and IMHO it's quite stupid. IIRC here is no such restriction for AUTH command, why APOP should be different ?
But I don't know if there's any nice way to do it, except perhaps by defining APOP password scheme which would actually be plaintext but wouldn't work with anything but APOP authentication. Do any other servers prevent it either?
After very quick view on Cyrus I think it doesn't enforce this limitation. It just just checks that valid USER command was not given before the APOP command. I did't check other pop3 implementations yet.
-- Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net
On Fri, 2004-07-02 at 10:27, Andrey Panin wrote:
AUTHNTICATE APOP will not work in IMAP session anyway because it doesn't pass initial responce required for APOP, so looks like this check is not really necessary.
Currently it doesn't, but there most likely will be extension which adds initial response support for IMAP. I think there already was a draft.
POP3 RFC also says:
It is conjectured that use of the APOP command provides origin identification and replay protection for a POP3 session. Accordingly, a POP3 server which implements both the PASS and APOP commands should not allow both methods of access for a given user; that is, for a given mailbox name, either the USER/PASS command sequence or the APOP command is allowed, but not both.
Yeah, I read this RFC part and IMHO it's quite stupid. IIRC here is no such restriction for AUTH command, why APOP should be different ?
I thought the same.. And I don't see a "MUST" there, so maybe it's not that important.
Anyway, I committed the patch with several other changes to implement dovecot-auth-trusted challenge.
There's still one problem. It's possible that connecting to dovecot-auth takes longer than accepting a POP3 client. In that case get_apop_challenge() fails because it doesn't know about auth connections yet. So, the greeting string should really be delayed until all auth connections are done. I left it there as FIXME, but moving it into clients_notify_auth_connected() probably would fix it..
I didn't actually test any of my changes, so it might be broken as well..
On 185, 07 03, 2004 at 01:01:15AM +0300, Timo Sirainen wrote:
On Fri, 2004-07-02 at 10:27, Andrey Panin wrote:
AUTHNTICATE APOP will not work in IMAP session anyway because it doesn't pass initial responce required for APOP, so looks like this check is not really necessary.
Currently it doesn't, but there most likely will be extension which adds initial response support for IMAP. I think there already was a draft.
POP3 RFC also says:
It is conjectured that use of the APOP command provides origin identification and replay protection for a POP3 session. Accordingly, a POP3 server which implements both the PASS and APOP commands should not allow both methods of access for a given user; that is, for a given mailbox name, either the USER/PASS command sequence or the APOP command is allowed, but not both.
Yeah, I read this RFC part and IMHO it's quite stupid. IIRC here is no such restriction for AUTH command, why APOP should be different ?
I thought the same.. And I don't see a "MUST" there, so maybe it's not that important.
Anyway, I committed the patch with several other changes to implement dovecot-auth-trusted challenge.
There's still one problem. It's possible that connecting to dovecot-auth takes longer than accepting a POP3 client. In that case get_apop_challenge() fails because it doesn't know about auth connections yet. So, the greeting string should really be delayed until all auth connections are done. I left it there as FIXME, but moving it into clients_notify_auth_connected() probably would fix it..
I didn't actually test any of my changes, so it might be broken as well..
Hmm, it's really broken:
Jul 5 12:39:22 pazke dovecot: pop3-login: APOP auth connection lost [80.254.111.17]
On the client side I see that connection is closed immediately after APOP command. I'll try to trace it down some time later.
-- Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net
On 187, 07 05, 2004 at 12:44:57PM +0400, Andrey Panin wrote:
Hmm, it's really broken:
Jul 5 12:39:22 pazke dovecot: pop3-login: APOP auth connection lost [80.254.111.17]
On the client side I see that connection is closed immediately after APOP command. I'll try to trace it down some time later.
Problem found: client->auth_id structure passed to auth_client_request_new() isn't filled anywhere. Attached patch fixes it, it also fixes dovecot-auth crash when username is not found in userdb.
Please consider applying.
-- Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net
On 6.7.2004, at 08:28, Andrey Panin wrote:
Problem found: client->auth_id structure passed to auth_client_request_new() isn't filled anywhere. Attached patch fixes it, it also fixes dovecot-auth crash when username is not found in userdb.
Please consider applying.
Thanks. One thing though:
safe_memset((void *) credentials, 0, strlen(credentials));
credentials parameter is a pointer given by passdb. It's const because it's not supposed to be modified as it could be a pointer to permanent location of the password, as it is with eg. passwd-file. If it's wanted to be cleared after use, it's passdb's job. The reason why eg. mech-plain does a safe_memset() is because it does a temporary copy of the password given by user.
I don't think all passdbs clear the passwords as much as they could, maybe I'll look one day and try to get them all cleared. Anyway, there's two reasons why the passwords are cleared:
More importantly, the plaintext passwords (and equilevants) sent by user should be cleared. The server contains only crypted versions of the password, so it's better to avoid leaking the plaintext password as much as possible. So if someone cracks the dovecot-auth, the attacker don't find lots of plaintext passwords lying around in process memory.
The other reason is just that it's better to avoid storing passwords into swap if possible. Although we could do better here too by using mlock(). Probably not worth the trouble.
participants (2)
-
Andrey Panin
-
Timo Sirainen