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