[Dovecot] SSL Client Certificate Support
Dear Timo,
most modern enterprises make use of a Public Key Infrastructure. It would be nice to have dovecot check a client certificate instead of a password. This makes life much easier and more secure. Mail clients like Mozilla and MS Outlook do support this. What do you think of the following feature request:
- Client authenticates with a certificate via SSL. (Like stunnel can)
- Dovecot looks the username up in a table with (public key, username)
- The mailclient gives a name and password, but dovecot ignores them
- Dovecot gives the client access by the username found in the table
This way existing mail clients can use this system and you can save your username with an empty password.
Best Regards,
Bert Koelewijn
Aloha!
At 12:37 01/10/2003 +0200, Bert Koelewijn wrote:
Dear Timo,
most modern enterprises make use of a Public Key Infrastructure. It would be nice to have dovecot check a client certificate instead of a password. This makes life much easier and more secure. Mail clients like Mozilla and MS Outlook do support this. What do you think of the following feature request:
- Client authenticates with a certificate via SSL. (Like stunnel can)
- Dovecot looks the username up in a table with (public key, username)
- The mailclient gives a name and password, but dovecot ignores them
- Dovecot gives the client access by the username found in the table
This way existing mail clients can use this system and you can save your username with an empty password.
Wouldn't it be much better to take the list of valid usernames from X.509 extension fields instead of a lookup table? That way the usernames are also verified and trusted information.
dovecot-auth would then allow the client to log in with any of the certified usernames using any arbitrary password, or to additional usernames using the correct password.
Of course, one could also use attribute certificates... :)
Anyway, one thing to remember might be that a ceritifcate usually identifies a person, not an account, so if a lookup table is used it should allow the person to have more than one account, and dovecot should allow that person into any one of them. Which one the person wants would be indicated by the username given to LOGIN.
Regards, Andy
Andreas Jaekel wrote:
Aloha!
At 12:37 01/10/2003 +0200, Bert Koelewijn wrote:
Dear Timo,
most modern enterprises make use of a Public Key Infrastructure. It would be nice to have dovecot check a client certificate instead of a password. This makes life much easier and more secure. Mail clients like Mozilla and MS Outlook do support this. What do you think of the following feature request:
- Client authenticates with a certificate via SSL. (Like stunnel can)
- Dovecot looks the username up in a table with (public key, username)
- The mailclient gives a name and password, but dovecot ignores them
- Dovecot gives the client access by the username found in the table
This way existing mail clients can use this system and you can save your username with an empty password.
Wouldn't it be much better to take the list of valid usernames from X.509 extension fields instead of a lookup table? That way the usernames are also verified and trusted information.
dovecot-auth would then allow the client to log in with any of the certified usernames using any arbitrary password, or to additional usernames using the correct password.
Of course, one could also use attribute certificates... :)
Anyway, one thing to remember might be that a ceritifcate usually identifies a person, not an account, so if a lookup table is used it should allow the person to have more than one account, and dovecot should allow that person into any one of them. Which one the person wants would be indicated by the username given to LOGIN.
Regards, Andy
Yep, you're totally right. In our company everybody has 1 mailbox, then one could use X.509 extensions.
Thanks!
Bert
Bert Koelewijn wrote:
Andreas Jaekel wrote:
Aloha!
At 12:37 01/10/2003 +0200, Bert Koelewijn wrote:
Dear Timo,
most modern enterprises make use of a Public Key Infrastructure. It would be nice to have dovecot check a client certificate instead of a password. This makes life much easier and more secure. Mail clients like Mozilla and MS Outlook do support this. What do you think of the following feature request:
- Client authenticates with a certificate via SSL. (Like stunnel can)
- Dovecot looks the username up in a table with (public key, username)
- The mailclient gives a name and password, but dovecot ignores them
- Dovecot gives the client access by the username found in the table
This way existing mail clients can use this system and you can save your username with an empty password.
Wouldn't it be much better to take the list of valid usernames from X.509 extension fields instead of a lookup table? That way the usernames are also verified and trusted information.
dovecot-auth would then allow the client to log in with any of the certified usernames using any arbitrary password, or to additional usernames using the correct password.
Of course, one could also use attribute certificates... :)
Anyway, one thing to remember might be that a ceritifcate usually identifies a person, not an account, so if a lookup table is used it should allow the person to have more than one account, and dovecot should allow that person into any one of them. Which one the person wants would be indicated by the username given to LOGIN.
Regards, Andy
Yep, you're totally right. In our company everybody has 1 mailbox, then one could use X.509 extensions.
Thanks!
Bert
If you don't use a lookup table, you HAVE to implement CRL's! You can make a script to download a new CRL and set it in your cron tabs.
Regards,
Bert
At 14:23 01/10/2003 +0200, Bert Koelewijn wrote:
Bert Koelewijn wrote:
Andreas Jaekel wrote:
Aloha!
At 12:37 01/10/2003 +0200, Bert Koelewijn wrote:
Dear Timo,
most modern enterprises make use of a Public Key Infrastructure. It would be nice to have dovecot check a client certificate instead of a password. This makes life much easier and more secure. Mail clients like Mozilla and MS Outlook do support this. What do you think of the following feature request:
- Client authenticates with a certificate via SSL. (Like stunnel can)
- Dovecot looks the username up in a table with (public key, username)
- The mailclient gives a name and password, but dovecot ignores them
- Dovecot gives the client access by the username found in the table
This way existing mail clients can use this system and you can save your username with an empty password.
Wouldn't it be much better to take the list of valid usernames from X.509 extension fields instead of a lookup table? That way the usernames are also verified and trusted information.
dovecot-auth would then allow the client to log in with any of the certified usernames using any arbitrary password, or to additional usernames using the correct password.
Of course, one could also use attribute certificates... :)
Anyway, one thing to remember might be that a ceritifcate usually identifies a person, not an account, so if a lookup table is used it should allow the person to have more than one account, and dovecot should allow that person into any one of them. Which one the person wants would be indicated by the username given to LOGIN.
Regards, Andy
Yep, you're totally right. In our company everybody has 1 mailbox, then one could use X.509 extensions. Thanks! Bert
If you don't use a lookup table, you HAVE to implement CRL's! You can make a script to download a new CRL and set it in your cron tabs.
Regards,
Bert
Wouldn't it be CA- and config specific how to implement revocation lists? Maybe dovecot wants to do real time checks via LDAP and use an internal cache with weekly updates. A cron job would be easiest, thought, and the fastest way to get there.
I imagine the cert code from Apache could be used to verify certs and extract X.509 extensions.
Regards, Andy
Andreas Jaekel queried:
Wouldn't it be CA- and config specific how to implement revocation lists? Maybe dovecot wants to do real time checks via LDAP and use an internal cache with weekly updates. A cron job would be easiest, thought, and the fastest way to get there.
this is one of those cases where theory and practice in certificates collide rather unpleasantly. In theory, the entity receiving a certificate should query the CA's revocation list each and every time it sees a certificate. To be most accurate, this query should go directly to the CA and receive an answer directly from their primary copy of the revocation list. Unfortunately, this model doesn't scale beyond something like a few thousand certificates. Implementation assumptions might get you better scaling on the order of a few tens of percent but you won't see the order of magnitude scaling that is frequently needed.
The suggestion you gave is more practical but does create an opportunity for a revoked certificate to still be used. This opportunity is the latency between the time the certificate is revoked and the time the revocation list is propagated. If you can use a push model (from CA to certificate receiver), it will keep the latency to a minimum.
Personally, I think the whole PKI idea is fundamentally flawed as do many cryptographic and security experts in the world. It works in the small. It doesn't work in the large and as long as you recognize that and are willing to accept the limitations of the implementation, you will be OK. Just never forget the limitations.
---eric
On Wed, 2003-10-01 at 13:37, Bert Koelewijn wrote:
most modern enterprises make use of a Public Key Infrastructure. It would be nice to have dovecot check a client certificate instead of a password. This makes life much easier and more secure. Mail clients like Mozilla and MS Outlook do support this. What do you think of the following feature request:
- Client authenticates with a certificate via SSL. (Like stunnel can)
- Dovecot looks the username up in a table with (public key, username)
- The mailclient gives a name and password, but dovecot ignores them
- Dovecot gives the client access by the username found in the table
I've thought about it before myself a few times. I'm not against such patch, but I don't think I'll implement it myself anytime soon.
Doing this also worries me a bit. Wasn't the recent security hole in OpenSSL just in the client certificate parsing? SSL cert authentication would have to rely on OpenSSL (or GNUTLS).
Timo Sirainen wrote:
I've thought about it before myself a few times. I'm not against such patch, but I don't think I'll implement it myself anytime soon. Is there anything I can do to give this patch a higher priority?
Doing this also worries me a bit. Wasn't the recent security hole in OpenSSL just in the client certificate parsing? SSL cert authentication would have to rely on OpenSSL (or GNUTLS).
OpenSSL have been audited many times, by many experts. If you trust dovecot, I think you can trust OpenSSL too.
<quote who="Bert Koelewijn"> > Timo Sirainen wrote: >> Doing this also worries me a bit. Wasn't the recent security hole in >> OpenSSL just in the client certificate parsing? SSL cert authentication >> would have to rely on OpenSSL (or GNUTLS). > > OpenSSL have been audited many times, by many experts. If you trust > dovecot, I think you can trust OpenSSL too.
this might be a bit off-topic but : -openssl might be audited by many experts, but this might apply to an version, but not the latest. -openssh is probably audited with the same affort as openssl. do you remember the bugs ?
for me the conclusion is every security application which is used by a large userbase (as openssl or openssh) is audited so closely that they always find some bugs.
regards, stefan
On Sun, 2003-10-05 at 12:52, Bert Koelewijn wrote:
Timo Sirainen wrote:
I've thought about it before myself a few times. I'm not against such patch, but I don't think I'll implement it myself anytime soon. Is there anything I can do to give this patch a higher priority?
Well..
Personally I'd really like to get the current CVS code fully working as intended. Then there's some long standing bugs/features (eg. recent counters). Then some NFS safety problems. All those should have been fixed long ago.
But it's also possible to buy features, support and whatever from Procontrol. I just don't really like that idea (well, support anyway) before 1.0 is released. Currently it's 85EUR/h if you really want it done :)
Doing this also worries me a bit. Wasn't the recent security hole in OpenSSL just in the client certificate parsing? SSL cert authentication would have to rely on OpenSSL (or GNUTLS).
OpenSSL have been audited many times, by many experts. If you trust dovecot, I think you can trust OpenSSL too.
Sendmail has also been audited many times by many experts and holes still keep showing up.
OpenSSL sources aren't nearly as bad as sendmail, but they are pretty dirty. Auditing dirty code is very time consuming and it's too easy to overlook problems. I've thought about auditing OpenSSL a few times, but I always got tired after reading just a few files since they were full of code that looked suspicious.
Also currently there's only dovecot-auth and master processes in Dovecot which have to be free of security holes to avoid pre-login security holes. That's not a lot of code. Using OpenSSL for authentication brings in tons of more code that has to be relied on.
Timo Sirainen wrote:
Personally I'd really like to get the current CVS code fully working as intended. Then there's some long standing bugs/features (eg. recent counters). Then some NFS safety problems. All those should have been fixed long ago. yes, it's better to get dovecot stable first.
Also currently there's only dovecot-auth and master processes in Dovecot which have to be free of security holes to avoid pre-login security holes. That's not a lot of code. Using OpenSSL for authentication brings in tons of more code that has to be relied on.
I understand. But please, keep it in mind for later versions of dovecot!
participants (5)
-
Andreas Jaekel
-
Bert Koelewijn
-
Eric S. Johansson
-
Stefan Sels
-
Timo Sirainen