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.
On 7/23/2007, Frank Behrens (frank at pinky.sax.de) wrote:> 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 environmentsWhat about: c) a "normal" MUA accessing via the internet from untrusted environments This is the recommended way all of our users access their email - webmail is just for the occasional access from a friends or other computer that they don't use regularly.> For a) I see with dovecot and other IMAP servers no problems, tricky > is the setup for b).Webmail is very easy to do...> If you use a webmail client in an untrusted environment the risk is > high, that keyloggers and other malware steal your password.Eh? Thats what SSL/TLS is for... I agree that providing access - either via webmail or any other MUA - on an unsecured connection from an untrusted source is very hazardous - but setting up SSL is fairly simple too, and I even force SSL/TLS on all of my connections even inside our trusted network (no reason not to - the extra overhead is very small). Sorry, but I don't understand the problem you are trying to solve... -- Best regards, Charles
On Mon, July 23, 2007 10:54 am, Phillip T. George wrote: [...]> Oh...also his post did include "/OTP", which unless I'm mistaken, than meansOff-Topic Post ..so it doesn't really matter if it had to do with Dovecot or not, right? :) :-) I believe he was referring to One Time Passwords. --Jo
On Mon, 2007-07-23 at 17:15 +0200, Frank Behrens wrote:> 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.I'd like to see your patch for this. I've no idea how pam_otp works.> 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.Cyrus Murder has something similar to this I think. We could make it compatible with it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070724/1c04f24c/attachment-0002.bin>
On Tue, Jul 24, 2007 at 09:42:29AM +0300, Timo Sirainen wrote:> On Mon, 2007-07-23 at 17:15 +0200, Frank Behrens wrote: > > 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. > > I'd like to see your patch for this. I've no idea how pam_otp works.I don't know a lot about the IMAP protocol's intricacies, but would it not be cleaner to either: a) provide the otp sequence as a capability (e.g. X-OTP-SEQ=1234), or b) provide a dovecot-specific IMAP command for finding out the current sequence value (e.g. X-OTP-SEQ) The sending of a dummy password to retrieve the LOGIN response seems like a bit of a hack (no offense to Frank - I'm keen to see this OTP idea implemented), but again, the above is written without much knowledge of the IMAP protocol. Jasper
Jasper Bryant-Greene <jasper at albumltd.co.nz> wrote on 24 Jul 2007 23:40:> a) provide the otp sequence as a capability (e.g. X-OTP-SEQ=1234), or > > b) provide a dovecot-specific IMAP command for finding out the current > sequence value (e.g. X-OTP-SEQ) > > The sending of a dummy password to retrieve the LOGIN response seems like a > bit of a hack (no offense to Frank - I'm keen to see this OTP idea > implemented), but again, the above is written without much knowledge of the > IMAP protocol.The problem is, that the OTP sequence is user dependent. When you use PAM you can't determine, if a user uses OTP until you try a login (you call pam_authenticate()). There is a existing mechanism in IMAP: SASL with OTP. But in that case you can not use the operating system configuration with PAM, but the IMAP server must handle the OTP challenge itself. I believe this is integrated in new dovecot 1.1 version. A problem with this setup is, that you need special support by a webmail client. I did'nt find any (easy) solution with suport for it, with the exeption of an extra IMAP-OTP-proxy server. Or another view: Until now dovecot (and I believe nearly all other IMAP servers) use PAM in a restricted form only. PAM means - you define all login capabilities and security restrictions and databases in the operating system. - when you try to authenticate a user, the PAM module requests the information via callbacks. That means a prompt is displayed for user name, user name is passed to PAM. Then a prompt for password is displayed, the password is passed to PAM. Theoretically this can be continued. With traditional IMAP LOGIN (I do not speak about SASL) the client supplies username and password together and this must be mapped to the callback sequence. Here the PAM prompts are ignored and in case for OTP they contain important information. My (probably non standard IMAP) extension creates the possibility to return the PAM callback message to the user. When you thing about it: A webmail client and the different IMAP login mechanisms fit not very well together. So some posters are right: you should better use a "real" IMAP client. But IMHO webmail is a useful solution, when you are on vacation or business travel and want to acces your email. And together with one time passwords the security risk is not too high, so you can use it. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 23 Jul 2007, Frank Behrens wrote:> 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.You mean, the client issues LOGIN (with a dummy password), because Dovecot needs to aquire the OTP challenge first, this LOGIN attempt is failed, but the username can be used to aquire the OTP challenge. It is reported back, via the LOGIN failure string and, secondly, another LOGIN attempt is sent, this time with the same username and a real password. I guess, you'll need to tweak the webmail interface a bit, that this sequence is working well. There are time-related OTPs, where the sequence number is derived from the current time. When a client tries a logon, the server calculates plenty of OTPs in the "near" of the current time and adjust itself to the client, in case the device's clock is running too slow or fast. I would say, this kind is more suitable for this purpose. However, one requires some sort of electronical device for it.> 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. :-)This will definitely a must then.> Solution 3: > 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.Hmm, any clients accessing webmail via the same proxy or from the same NATed organisation will use the same IP, dial-up IPs switch the users more often than anything else. I don't think that restricting by IPs you have no knowlegde about is save. Bye, - -- Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRrgspy9SORjhbDpvAQIJmAgA06boNvZrFTS4kNyky6ywUiYv9CHu99tI GT4iQNezyZz0PensPgGJp6ZAJGDdlAZ1ZxWBth1JCvpVZSBCwnbmbEbWnYtCi9OR v/eynzRFta/11nFy0+AB1Pf2BuoFFPtXy+hC6DnpPcLutD4Q+bvm3Kqdry72PmyQ lBUg8TxTwuDZ0sY0TTAP6VaJCmTG1RvnC5dZp4f6C3yN7kwXbcgS1rkHGr8V6Frs z9ZXMkRYUCpG/ufCQqFB9YTAAOxWM8DrKsmQZNClmkypc+q+v0w11BfcF6SK7v9I cdQqSca7AmXR4q2UYoyvAGGn7rF0cDJJXKI0iQWfWr2nchnx0/PoUA==wZxi -----END PGP SIGNATURE-----
Steffen Kaiser <skdovecot at smail.inf.fh-bonn-rhein-sieg.de> wrote on 7 Aug 2007 10:26:> You mean, the client issues LOGIN (with a dummy password), because Dovecot > needs to aquire the OTP challenge first, this LOGIN attempt is failed, > but the username can be used to aquire the OTP challenge. It is reported > back, via the LOGIN failure string and, secondly, another LOGIN attempt > is sent, this time with the same username and a real password.Yes, this was my intention.> I guess, you'll need to tweak the webmail interface a bit, that this > sequence is working well.It's easy: If a login fails the webmailer has to write an error message in any case. Simply include the IMAP error response.> There are time-related OTPs, where the sequence number is derived from the > current time. When a client tries a logon, the server calculates plenty of > OTPs in the "near" of the current time and adjust itself to the client, in > case the device's clock is running too slow or fast.Of course, this is more sophisticated and more expensive. My proposol uses OPIE - One- time Passwords In Everything. But remember: With my proposal you use always the login configuration from operating system. If you have a pam module for an electronic one-time password generator you can use it with IMAP and webmail without additional changes in IMAP- or webmail-server.> > Solution 3: > > 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. > > Hmm, any clients accessing webmail via the same proxy or from the same > NATed organisation will use the same IP, dial-up IPs switch the users more > often than anything else. I don't think that restricting by IPs you have > no knowlegde about is save.I meant it inversely. You can allow the usage of "normal" passwords for all IMAP and webmail clients in local network and restrict external clients to OTP. With pam configuration you make this decision for all logins (ssh, ftp), not only for IMAP with dovecot. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 7 Aug 2007, Frank Behrens wrote:> Of course, this is more sophisticated and more expensive. My proposol uses OPIE - One- > time Passwords In Everything. But remember: With my proposal you use always the loginAh, OK.> configuration from operating system. If you have a pam module for an electronic one-time > password generator you can use it with IMAP and webmail without additional changes in > IMAP- or webmail-server."without additional changes" Then no change would be required in Dovecot ;-) But it looks nice. How do you intend to pass the passwords to the users, via print-out? Or handhelds and Java opiekey? Bye. - -- Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRrhBYS9SORjhbDpvAQIomwf/ZEaDdZUtM2hiaZRQOecSrl+GnwzpFAnc SsRFtlU06MRpkfqQxB7Y+/PZ297lcP0dBeNDO+QNYwXOsOnNVavjhuEsszKlOvFa MI6Zzd9CgBI7fQ4j2HHwvUiOPS2gjrjS3JUWleAFcLF0XDUmp91sXytFpuiNy537 hCbxUmNiCnp1Vl4e5Hj0x7Ex0v/lQJ9GLxmWZRsfQ+Zrm3RU9zPuvjfzjZm7tjnZ 033CiHOLNSglAK40gTRHCxHAWy3NIsKWd1hydMTZpmdeV2MbM+b5AoJZ/Qt55OTj 8zZvgfn2E875I4CpvC38frR5Y7YPxPhXKt+3qhsQXfaTBJk/tOrYEQ==oZHw -----END PGP SIGNATURE-----