Re: TLS client certificates and auth external

[Bastian Schmidt]

I have reworked my implementation for SASL auth external support. I now have a patch available that would introduce the following possibilities:

Using an option: smtpd_sasl_tls_ccert_username = commonName



Using an option: smtpd_sasl_tls_ccert_username = relay_clientcerts








Bastian


On 09.01.19 22:49, Bastian Schmidt wrote:

After providing a verified client certificate, postfix advertises auth external and the user can authenticate with the username being the commonName of the certificate. This is for users having control over the CA issuing the certificates and resembles the way cyrus imap handles the situation. When a client presents a certificate, where the fingerprint matches in relay_clientcerts, the lookup value (previously unused) is used to get the username for sasl. The client can then perform an auth external with this username successfully. This is a solution for users, which cannot control the CAs or do not want to trust them or cope with crls, ... It fits in the way postfix currently handles client certificates. Both solutions then cause permit_sasl_authenticated to succeed and the sasl username to be set correctly. The default for smtpd_sasl_tls_ccert_username (the empty value) or any other value cause auth external to not be advertised and neither succeed; the same situation as without the patch. I would really like to get SASL auth external integrated, how can I submit the patch for these changes? Shall I simply post it to this mailing list?

Ok, taking this over to postfix-devel.

I understand the concern of default security.



Exactly what cyrus imap does is what I already have implemented.





Bastian

On 08.01.19 23:35, Viktor Dukhovni wrote:

As the default smtpd_relay_restrictions are permit_my_networks, permit_sasl_authenticated, defer_unauth_destination. Silently adding external auth is not an option, as then verified client certs are permitted by default due to permit_sasl_authenticated succeeding. This means, in order to not have problems with existing configurations allowing more access suddenly, we would need an option smptd_tls_ccert_verified_is_sasl_authenticated or something. I took cyrus imap server as an example for what SASL authenticated means with a client cert. It simply uses the CN of the subject of the cert as a username. And one can just specify one or several CAs, which are trusted. Cyrus also lacks support for ocsp and crls. I personally don't use the fingerprint solution from postfix due to adminstrative effort. Thus, I have not yet implemented something like the suggested "fingerprint to user map" but I see this fits very well to postfix's current security design and would be willing to implement this if it helps auth external to be integrated. You are right the implementation is rather straight forward as SASL libraries already suppport it.

On Jan 8, 2019, at 5:17 PM, Bastian Schmidt <bastian.schm...@web.de> wrote:

I hope this is the right postfix mailing list for this request.

I have an email client (K-9 on Android), which, when using TLS client certificates insists on sending an auth external. However, postfix/SASL does not advertise external auth, which causes the client to not being able to use client certificates with postfix. As I see it, postfix is missing the external mechanism as specified in RFC 2222 (SASL) completely. Thus, I have implemented this feature (for TLS CA client certs) and I am currently successfully running this on a local installation using cyrus sasl. I would be willing to provide a patch and would really like to see this integrated in future versions of postfix.

Well perhaps postfix-devel is equally or more appropriate.

There is a key design issue here:

  * In typical Postfix configurations we see relay restrictions of
    the form:

    smtpd_relay_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination

    which is fine, when the user has enrolled for a login account
    on the receiving system.  But with client certs, anyone can get
    a client certificate from some CA, or even mint their own.

    So what does "SASL authenticated" mean with client certs? Is
    there a particular issuing CA that's the only one trusted to
    issue client certs?  Or does the client certificate fingerprint
    need to match a lookup table for it to be considered authenticated?

    My advice is that a trusted CA, and likely often accidentally every
    CA on the planet from one of the usual CA bundles, is much too risky
    in this context, and would drag in revocation lists, OCSP, and that
    whole dumpster-fire of PKI issues.

    Therefore, the meaning of SASL authenticated for EXTERNAL should be
    that the client certificate fingerprint matches a lookup table that



    username obtained from the fingerprint->username map. You could also

    with valid sender addresses, ...

Otherwise, "EXTERNAL" should be fairly straight-forward.  Feel free to
move the discussion to postfix-devel, or continue here to the extent

    maps the client certificate to something resembling a SASL user name.     You would then either "permit_sasl_authenticated" without distinguishing     between one user and another, or else use "check_sasl_access" based on     then use the "sender login mismatch" features by matching the username the discussion stays high level, rather than dives into the implementation.

smime.p7s
Description: S/MIME Cryptographic Signature