Dick Visser: > Hi guys > > At the moment we use SASL authentication to allow our users to > send mail through our mailer (Postfix 2.5). I would like to extend this > to using client certificates for authentication as well. > > Our users have personal certificates that are signed by a the "TERENA > Personal CA". Due to the nature of this CA, it is guaranteed that all > the attributes in the certificate are correct (see > https://www.terena.org/activities/tcs/ for more information). > > So certificates with O=OrganisationX are therefore guaranteed to really > be from Organisation X. I would like to use this to give relay access to > my users. > > Regarding access control and client certs I can find: > > * allow all certs based on the issuer (smtpd_tls_CAfile). This is not an > option because the CA also signs ccerts from other institutions. > * allow certs based on their fingerprint (check_ccert_access). This is > not scalable. > > Postfix has already access to at least the Common Name and Issuer > attributes of the ccert, as can be seen by these headers: > > Received: from [192.168.2.199] (a213088.upc-a.chello.nl [62.163.213.88]) > (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) > (Client CN "Dick Visser", Issuer "TERENA Personal CA" (verified OK)) > (Authenticated sender: vis...@terena.org) > by erasmus.terena.org (Postfix) with ESMTPSA id 6466087BC3 > for <d...@tienhuis.nl>; Mon, 22 Mar 2010 21:33:38 +0100 (CET) > > > Is there a way to restrict relaying access only to clients showing a > certificate that has: > > * issuer "TERENA Personal CA" > * O=TERENA > * C=NL > > ? > > > I guess what I am looking for is a new restriction called something like > "check_ccert_attr", that would use user defined attributes to take > decisions. That would be really scalable for our situation. > > Any ideas how to implement this in other ways? > I looked into policy daemon options but Postfix does not pass any > certificate information other than ccert_subject, ccert_issuer, and > ccert_fingerprint, which is not enough for what we want.
If you need a solution now, Postfix supports MULTI-ATTRIBUTE access decisions via the policy delegation protocol; policies can be implemented in a standard scripting language, and performance is good. Postfix is careful not to execute a new script for each query. See: http://www.postfix.org/SMTPD_POLICY_README.html For solutions built into Postfix there are some short-term options. First, there needs to be a way to search Postfix tables for session attributes other than client, helo, sender, or recipient. I have a design and partial implementation for access map lookups for a SINGLE attribute that looks like: check_attr_access attr_name maptype:mapname Where attr_name is the name of a SINGLE attribute (attribute names are the same as in the policy delegation protocol) and where maptype:mapname specifies a lookup table in the usual manner. The options for built-in multi-attribute access control are limited. Other than using a restriction class kludge (see below), I currently have no design for multi-attribute queries on lookup tables that works with all Postfix lookup tables, nor do I have a design for an AND operation on multiple single-attribute queries. With a restriction class kludge you would use two table queries. The first query would look like "check_attr_access ccert_issuer maptype:mapname". If the query succeeds, the result would be the name of a restriction class. This would expand into the second query, which has the form "check_attr_access ccert_subject maptype:mapname" (which could query a regexp table). This second query would return OK for users with the right ccert_subject attribute. This is not very elegant, and that is why I call it a kludge. See: http://www.postfix.org/RESTRICTION_CLASS_README.html Wietse
