DevHeads.net

TLS client certificates and auth external

Hello,

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.

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

Bastian

Comments

Re: TLS client certificates and auth external

By Viktor Dukhovni at 01/08/2019 - 18:35

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
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
username obtained from the fingerprint->username map. You could also
then use the "sender login mismatch" features by matching the username
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
the discussion stays high level, rather than dives into the implementation.

Re: TLS client certificates and auth external

By Matthew Horan at 03/10/2019 - 22:47

I'm quite excited about seeing this feature added to Postfix. I have a
similar configuration, and have been putting off making the proposed changes
myself. I had previously posted on the Dovecot mailing list [1] to no avail.
I'm happy to know that there are at least two of us out there who would
benefit from this feature!

Thanks,
Matt

[1] <a href="https://www.dovecot.org/list/dovecot/2017-February/106884.html" title="https://www.dovecot.org/list/dovecot/2017-February/106884.html">https://www.dovecot.org/list/dovecot/2017-February/106884.html</a>

Re: TLS client certificates and auth external

By Bastian Schmidt at 03/18/2019 - 17:45

In the meantime I have completed a patch and sent it to Wietse and
Victor, which adds an option smtpd_sasl_tls_ccert_username.
As the patch is rather small, I also attached it to this message.

This smtpd_sasl_tls_ccert_username option can be used in the following way:

Using smtpd_sasl_tls_ccert_username = commonName
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.

Using smtpd_sasl_tls_ccert_username = relay_clientcerts
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 have the first version running successfully in a small local
installation using cyrus sasl, where K-9 and Thunderbird are both able
to use client certificates (and simple username/password login). With
cyrus sasl the setup is more or less straight forward.
I also setup a virtual machine to test a dovecot sasl setup. Here the
setup is more complicated, as dovecot has to be setup to allow an empty
password, when using external auth (and only, when using external auth).
This is only possible since version dovecot version 2.2.28. Here I have
tested my patch using the s_client only.

Best regards,
Bastian

On 11.03.19 03:47, Matthew Horan wrote:

Re: TLS client certificates and auth external

By Bastian Schmidt at 01/09/2019 - 17:49

Ok, taking this over to postfix-devel.

I understand the concern of default security.
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.
Exactly what cyrus imap does is what I already have implemented.

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.

Bastian

On 08.01.19 23:35, Viktor Dukhovni wrote:

Re: TLS client certificates and auth external

By Bastian Schmidt at 01/14/2019 - 14:13

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

Using an option: smtpd_sasl_tls_ccert_username = relay_clientcerts
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?

Bastian

On 09.01.19 22:49, Bastian Schmidt wrote:

Re: TLS client certificates and auth external

By Wietse Venema at 01/14/2019 - 14:30

Bastian Schmidt:
It's probably too large for a mailing list, because it should not
only contain raw code, but also documentation (updates for proto/*
and ideally also for mantools/postlink). Please use <a href="http://www.w3.org/validator" title="www.w3.org/validator">www.w3.org/validator</a>,
spell checker, and if possible, valgrind.

You can send the code to me and Viktor. I do not expect to include
this in Postfix 3.4, as we are still racing to finish things for
Postfix 3.4, and we have limited time resources.

Wietse