[Dovecot] [PATCH, RFC] add APOP authentication mechanism

[Andrey Panin]

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", 
> >>get_log_prefix(auth_request),
> >>+                               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 at 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 at donpac.ru		| PGP key: wwwkeys.pgp.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://dovecot.org/pipermail/dovecot/attachments/20040702/9d8340db/attachment-0001.pgp