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

[Thomas Harding]

[my mother tongue is French, and I'm not very fluent in English...]

Le 02/09/2010 21:44, Dan White a écrit :
> On 02/09/10 21:11 +0200, Thomas Harding wrote:
>> However, I use my own created CA chain (with intermediate one)
>> to authenticate users in Postfix, not to account, which would
>> need the same process, and both postfix and cyrus ask for a
>> certificate issued from this secondary authority.
>> So, my postfix smtp_sender_restrictions rules allows mails from
>> certificates issued by my authority (permit_tls_all_clientcerts),
>> these users are logged as "trusted", while certificates from other
>> authorities are logged as anonymous.
>>
>> At same time, I have Sep 2 17:27:23 smtp2 cyrus/imaps[27137]: login: 
>> [192.168.0.254] tom plain+TLS User logged in
>>
>> And I run imaps (tcp 993) only.
>>
>> So, how to use "TLS" authentication without plain/other authentication
>> mechanisms ?
>>
>> * I wonder is something is planned on cyrus SASL to allow accounting
>> through X509 subject DN, with selected CA authorities
>
> The cyrus sasl library facilitates the use of authentication of a TLS
> session via the EXTERNAL mechanism. However, such support must be
> implemented by the server in question (such as Postfix).
>
> 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.
>
> For instance, the imapd server does this in its starttls implementation:
>

Tried from imap/143/startls and imaps/993 without success

 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.

> 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"

dn: uid=foo, ou=bar, dc=foobar, dc=com
ObjectClass: (can't remain)
ObjectClass: (can't remain)
....
uid: foo
cn: Thomas Harding
....

dn: cn=Thomas Harding, ou=bar, dc=foobar, dc=com
ObjectClass: (can't remain)
ObjectClass: (can't remain)
uid: foo
cn: Thomas Harding
> 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.

I think this is the current right way,

While my goal is to avoid any user password/certs database, even ldap, 
but relay
on a certificate attribute from delivered by one or more trusted CAs, then
authenticate on certificate itself without any database look :
I know it's stupid because I will have no revocation list possible 
currently.

Even if it would be great to have sasl rely only _fully_ on certificates,
with CRLs handling.



So, I will turn to ldap (there are good slides I googlized on that)
Both for cyrus and postfix (which is very flexible), with addition
of "individual" root + intermediates CA, and sasl login for postfix
(which for the last already authorize my signed certificates only
to send mails out from my domain without having to log in but
allows my authority issued certs only and logs cert identity in
"Received:" header...
which is enough to proof sender identity, and allow any "From:"
address... as usual with SMTP)


The way I wish is in fact this one, according thread ending by
http://www.mail-archive.com/info-cyrus@lists.andrew.cmu.edu/msg18981.html

It /should work/ but the guy didn't success

However, postfix can also uses directly LDAP and tables for certs MD5 
hashes,
but I didn't notice REJECT/DUNNO/OK actions as for other tables.


Concerning cyrus doc I have :
<cite>
You can use the self-signed certificate generated above as a CA for 
client certificates. To do this, try the
following:


TODO: write me!

</cite>
Which could be completed by:

TinyCA GUI will help, notably in exporting CA chains,
CRLS and bundled certificates such as PKCS12 and PEM
Take care of RSA/DSA in case of server purpose (one not needs passphrase...)

The use of the TinyCA GUI would help dummies and ensure a good 
wallets/revocation lists management :
on Debian GNU/Linux, install "tinyca"; in a terminal, command is 'tinyca2'

create a first CA (the root one), the first "pages" icon from the left

then create a certificate request/key/cert for intermediate CA by click 
the second "pages"
icon just after the two "search" icons

fill in "create intermediate CA form", the first item is the top-level 
root CA passphrase

In top level menu CA => open CA => choose the intermediate CA nickname

in "cert requests tab", right click => new request
fill in the form

once done, right click on the request item then sign with intermediate 
CA passphrase :
You will have choice between server and client

in "certs" tab, export the request. Choose tar or zip for a server, 
pkcs12 for a
client, (PEM without key for LDAP [I’m not sure currently, as never done).
Tip: my smart phone not accept any signature algorithm : MD5+RSA is OK, 
not SHA1 nor other tested...

Tip: acutes must be re-written each time a request if you have ones (my 
city is Orléans)
Tip: take care on symlink ~/.TinyCA on a mounted device such as an usb key
Tip: typing on keyboard like a mad cat would accelerate encryption process

<cite>
Unfortunately, there's no standard on how to convert the client's 
authenticate DN (distinguished name) to a SASL authentication name.
</cite>

I hope a "standard on how to convert the client's authenticate DN",
based on cn or uid, ObjectClass +,
organizational unit and domain components (which could be named "suffix")

...which could be done in a /var/lib/sasl/smtp.conf like file or a 
postfix ldap like table,
but would largely benefits on an xml syntax (to allow virtual domains 
and several
ldap servers.

I'm not a developer, my programming and administration skills are 
self-learned ones,

I have no capability in C/C++ except little hacks,
I seriously learned only Python (good), (not so) Posix shells, PHP 
(heerk), SQL
and a little bit PL/PGSQL (which for "quoting" is a nightmare)

But I'm experienced in dozens of configuration file types and 
DTD/xml/xslt authoring.

So, if anyone interested in the xml configuration file I hope definition 
and processing,
which could handle LDAP+certificates or "certificates only with CRLs",
I could help, even in documentation (for the last, I helped 
documentation automated
generation in "Dia" project a few years ago, and I could adapt that to 
Cyrus project.
Beware: it is a long last process to build and "pack" correctly any 
documentation
with a good matter of "integration to the program build and compilation") ;)

HTH,
TH.