Bert Koelewijn | 1 Oct 12:37 2003

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

Andreas Jaekel | 1 Oct 12:55 2003
Picon

Re: SSL Client Certificate Support

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
(Continue reading)

Bert Koelewijn | 1 Oct 14:03 2003

Re: SSL Client Certificate Support

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 
(Continue reading)

Bert Koelewijn | 1 Oct 14:23 2003

Re: SSL Client Certificate Support

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 
(Continue reading)

Andreas Jaekel | 1 Oct 14:32 2003
Picon

Re: SSL Client Certificate Support

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
(Continue reading)

Eric S. Johansson | 1 Oct 15:06 2003

Re: SSL Client Certificate Support

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

(Continue reading)

Timo Sirainen | 3 Oct 16:48 2003
Picon
Picon

Re: SSL Client Certificate Support

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).

Bert Koelewijn | 5 Oct 11:52 2003

Re: SSL Client Certificate Support

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.

Stefan Sels | 5 Oct 12:32 2003

Re: SSL Client Certificate Support

<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

Timo Sirainen | 5 Oct 21:01 2003
Picon
Picon

Re: SSL Client Certificate Support

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
(Continue reading)

Bert Koelewijn | 6 Oct 21:14 2003

Re: SSL Client Certificate Support

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!


Gmane