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

[Timo Sirainen]

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.

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 at 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20040701/c1dff077/PGP.pgp