[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@xxxxxxxxxxxxxxxxxxxx/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.
