How to authenticate through a X509/pkcs12 client certificate (SSLv3/ [RFC 5246 ?] authentication only)?

[Dan White]

On 04/09/10 11:48 +0200, Thomas Harding wrote:
>Le 02/09/2010 21:44, Dan White a écrit :
>>Servers typically implement support by providing a STARTTLS command, and
>>using some information contained in the certificate to derive a username.
>>How the server derives the username is up to the server.
>
>Tried from imap/143/startls and imaps/993 without success

How did you test it? Did you specify the EXTERNAL mechanism? You can test
with imtest:

imtest -t "<path>/client.cert" -m EXTERNAL imap.example.net

>From another response quoted below, EXTERNAL auth is done through OpenLDAP
>(ldapdb), which with further Ternet readings offers "EXTERNAL".
>
>I didn't found literature on Ternet on that subject.

The ldapdb auxprop plugin will not have access to your client certificate,
and would not allow you to authenticate to the IMAP/SMTP without a username
and password.

It would allow you to store your user credentials in an LDAP directory.

>>Which presumably means that whatever is in the common name of the
>>certificate will become the authenticated identity.
>
>For sure, but I remain an alternative "key" field in certificates for
>identification, maybe found in a RFC, As for as an LDAP entry can have
>both "uid" an "cn" for "dn" "last significant name"

Again, how the server chooses to derive an authentication identify from the
contents of a certificate is left up to server implementation. There is no
standard that I'm aware of.

For instance, it might make some sense for an LDAP server to derive a DN as
the authentication identity, since the structure of a certificate and an
LDAP tree look similar. I don't actually know if that's true of OpenLDAP.

The SASL library offers the ability to canonicalize (simplify/unify)
authentication identities in this scenario, via a user canon plugin.

>>I believe sendmail, cyrus imap, and openldap support such authentication.
>>I don't believe postfix does. I cannot find any mention of
>>SASL_AUTH_EXTERNAL in its source.
>
>> [from Dan white]> You may use OpenLDAP as identity provider, ldapdb 
>> as auxiliary
>> [from Dan white]> property plugin and SASL Mechanism EXTERNAL.

The first part was from me. The suggestion to use ldapdb came from Dieter.

-- 
Dan White