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)


Gmane