Re: Access based on client cert attributes?
On 23/03/2010 16:41, Victor Duchovni wrote: Having noticed the many pitfalls of parsing X.509 certs, and written careful code to parse them (and avoided Postfix being linked to vulnerabilities later found in most certificate parsers), I am reluctant to ask Postfix users to write robust X.509 parsing code in their own policy service code. True. On the other hand, the admins responsible for setting the institution information (most importantly: 'Organisation') in the certificate are also the ones that need to check for it. And the most likely scenario will be that you want to check if a certificate belongs to one of your own users. Since you put that data in, it should be possible to establish some positive confirmation on that. I can see that writing a X.509 parser is non-trivial. Maybe this is totally the wrong idea, but would it be possible to reuse the SSLRequire code of Apache in a new check_ccert_x, or possibly in a policy daemon? http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslrequire That option looks exactly like what we need... Do your users actually want to install and use client certs? Do they have them in any case for other reasons? They don't have them now, but they will soon, and so will thousands of others users: https://www.terena.org/activities/tcs/ Right now nobody has them, so nobody uses them. TERENA has taken the initiative to break this circle and to make them really available to our community. The same approach was used for the TERENA server certificates, which were introduced a couple of years ago. Currently there are about 30.000 servers in the European research and education area field that use those certificates. It is expected that the same will happen with the personal (client) certificates: once it is very easy and convenient to get one, certificate based services will get used more and more. Lots of postmasters in the academic and research networking area will want to use this. The TERENA Certificate Service is aimed at European NRENs, which means in principle all students/employees/etc of higher education and research institutes. So there is a huge potential. -- Dick Visser System Networking Engineer TERENA Secretariat Singel 468 D, 1017 AW Amsterdam The Netherlands T +31 20 530 44 88 F +31 20 530 44 99 vis...@terena.org | www.terena.org smime.p7s Description: S/MIME Cryptographic Signature
Re: Access based on client cert attributes?
On Fri, Mar 26, 2010 at 12:52:55PM +0100, Dick Visser wrote: Having noticed the many pitfalls of parsing X.509 certs, and written careful code to parse them (and avoided Postfix being linked to vulnerabilities later found in most certificate parsers), I am reluctant to ask Postfix users to write robust X.509 parsing code in their own policy service code. True. On the other hand, the admins responsible for setting the institution information (most importantly: 'Organisation') in the certificate are also the ones that need to check for it. If there is no TTP (trusted third party, e.g. an external CA) in the loop, fingerprints work much more simply. Why do I need a TTP to authenticate my own users? Using X.509 certs for this is IMHO unwise. SASL (especially GSSAPI for sites with Kerberos) is much more usable than X.509 client certs in any case. I can see that writing a X.509 parser is non-trivial. Maybe this is totally the wrong idea, but would it be possible to reuse the SSLRequire code of Apache in a new check_ccert_x, or possibly in a policy daemon? http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslrequire Much too complex I think. Do your users actually want to install and use client certs? Do they have them in any case for other reasons? They don't have them now, but they will soon, and so will thousands of others users: https://www.terena.org/activities/tcs/ Sorry, I am deeply skeptical of all PKI initiatives. Right now nobody has them, so nobody uses them. TERENA has taken the initiative to break this circle and to make them really available to our community. My prediction is that Terena will fail for the same reasons as everyone that tried this before. The PKI model is deeply flawed. It is expected that the same will happen with the personal (client) certificates: once it is very easy and convenient to get one, certificate based services will get used more and more. I expect that you'll not find this to be the case. Lots of postmasters in the academic and research networking area will want to use this. The TERENA Certificate Service is aimed at European NRENs, which means in principle all students/employees/etc of higher education and research institutes. So there is a huge potential. If PKI for the masses suddenly takes off, we can revisit Postfix support for this. In the mean time, what's available to policy services is the issuer name (CN or O) and subject CN. I am disinclined to send the peer certificate blob to policy services or build-in a complex language to evaluate client certs. We could perhaps agree on a robust encoding of the issuer and subject DN, and make these available to policy services (duplicating the current issuer name and subject name, which are components of each). I can probably help more users at lower implementation cost by allowing access checks on the public-key fingerprint instead of the certificate fingerprint, which would allow clients that renew CA certs with the same underlying private/public key pair to continue to access a given Postfix server. -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
Access based on client cert attributes?
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. Thanks! -- Dick Visser System Networking Engineer TERENA Secretariat Singel 468 D, 1017 AW Amsterdam The Netherlands T +31 20 530 44 88 F +31 20 530 44 99 vis...@terena.org | www.terena.org smime.p7s Description: S/MIME Cryptographic Signature
Re: Access based on client cert attributes?
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
Re: Access based on client cert attributes?
On Tue, Mar 23, 2010 at 10:10:44AM -0400, Wietse Venema wrote: * 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. Keep in mind that in general, ccert attributes are UTF-8 data so any code to handle these would need to be UTF-8 compatible. Also, I code to parse the issuer DN into all its components is not attractive in this context. The component names (dc, ou, ...) can repeat or be unnamed numbered oids, ... It is far from clear how to expose the parsed DN to a policy service or Wietse's proposed check_access attr_name table feature. Therefore, the best that I can offer in this context is to expose the full subject DN as a single attribute. This too requires care, becase string encodings of DNs can be tricky to parse since , or / characters use to create displayable DNs can also occur inside the values of DN components. I would have to generate an escaped DN, in which internal delimiters are preceded by \ or something similar. You'll also need the issuer DN unless your CA file includes only the one trusted issuer (and no standard CA file is preloaded by OpenSSL library in addition to the CAfile you specify, as is the case in some vendor releases of OpenSSL). An extra complication is that the best subject name could in subjectAltName value, not the subject DN. Another option is to export the entire client certificate chain as a single attribute (in a suitable encoding) and let the policy service parse certificates via a suitable X.509 library. Having noticed the many pitfalls of parsing X.509 certs, and written careful code to parse them (and avoided Postfix being linked to vulnerabilities later found in most certificate parsers), I am reluctant to ask Postfix users to write robust X.509 parsing code in their own policy service code. So, bottom line, X.509 is hell, and I would humbly suggest that you stick with SASL or consider client cert fingerprints, if issuing your own client certs (rather than using a public CA) is an option. Do your users actually want to install and use client certs? Do they have them in any case for other reasons? -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
