I want to discuss some problems/enhancements for dovecot in a webmail/otp setup.

For access to an IMAP server like dovecot I see different client types:
a) a "normal" MUA installed in a more or less trusted environment
b) remote access via "webmail" from untrusted environments

For a) I see with dovecot and other IMAP servers no problems, tricky is the 
setup for b).
If you use a webmail client in an untrusted environment the risk is high, that 
keyloggers and 
other malware steal your password. One easy solution is to use 
One-Time-Passwords 
(OTP). The otp setup for interactive logins (e.g. ssh) is easy, but until now I 
did not find any 
easy to use solution for webmail. The main problems I see
- In most cases a webmail client does not hold a persistent connection to the 
IMAP server, 
but makes a login for every request.
- The webmail clients are not prepared to display the otp password challenge to 
the user.

When we say "otp" with IMAP we further have to distinguish
a) the OTP SASL authentication mechanism
b) OTP configured by PAM.

I believe a) is implemented in new dovecot 1.1 version, but I prefer b), because
- it works with many clients without special client support
- all authentication setup is central in the os.

All above described problems are not specially linked to dovecot, but I believe 
with dovecot 
there is an easy solution to solve them. :-)

Solution 1:
When PAM is configured for IMAP the user can use a one-time-password in the 
same way 
as before. The problem is, that the user must know the sequence number for the 
password 
(otp challenge), so we need a way to display it. The PAM module supplies the 
otp challenge 
in the conversation function, but the challenge is not processed by the IMAP 
server.
My proposal: The IMAP server stores the challenge from the conversation 
function and 
includes it in the LOGIN response, when the login was not successful. So a user 
can try a 
login with a wrong dummy password and get knowlegdge about the current otp 
sequence.

The webmail server should be extended in a way, that it displays the complete 
IMAP error 
message, when a login fails.

Solution 2:
Webmail clients do not use persistent connections in most cases. A OTP login 
needs 
different passwords for every displayed web page.
My proposal: Use dovecot's login cache and do not ask the os for every login. 
:-)

Solution 3:
When we configure PAM we can restrict/allow it's use depending on IP address of 
client. 
Unfortunately with a webmail client the IMAP client is always the the 
webserver. It should be 
possible, that the webserver forwards the client IP address to the IMAP server. 
Furthermore 
to use dovecot's login cache as described above in a safe manner, the IP 
address should be 
compared, too.
My proposal: Create a new IMAP command "XSETREMOTEIP". With this IMAP extension 
a 
client can set the real IP address of remote client. The access to this command 
is restricted 
to the webserver with a new configuration parameter "trusted clients", which 
holds an IP 
address with mask.


I ask to discuss these solutions. It seems to work, I'm making the first tests 
now. I have 
patches for dovecot and squirrelmail, but they are very "quick and dirty". They 
show a 
possible solution, but not a clean implementation.

Do you believe, that we can build a good webmail system this way, or do you 
have better 
solutions?

Regards,
   Frank
-- 
Frank Behrens, Osterwieck, Germany
PGP-key 0x5B7C47ED on public servers available.

Reply via email to