TLS client certificates and auth external

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

TLS client certificates and auth external

Bastian Schmidt
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




Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

Viktor Dukhovni
> On Jan 8, 2019, at 5:17 PM, Bastian Schmidt <[hidden email]> wrote:
>
> 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.

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.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

Matthew Horan
 > On Jan 8, 2019, at 5:17 PM, Bastian Schmidt <[hidden email]> wrote:

>
> 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'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] https://www.dovecot.org/list/dovecot/2017-February/106884.html



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

Bastian Schmidt
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:

>   > On Jan 8, 2019, at 5:17 PM, Bastian Schmidt <[hidden email]> wrote:
>> 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'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] https://www.dovecot.org/list/dovecot/2017-February/106884.html
>
>
>
> --
> Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html


sasl_auth_external.patch (10K) Download Attachment
smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

Emmanuel Fusté-2
Hello,

Great piece of work ! It solve a big part of my problem, but sadly I
need to go deeper.

Le 18/03/2019 à 22:45, Bastian Schmidt a écrit :

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

I have to deal with products that do not support SMTP AUTH (big email
security appliance provider .....) but are able to present a TLS
certificate.
On my platform, the use of the smtpd_sender_login_maps and associated
restrictions (reject_sender_login_mismatch) is mandatory to achieve our
goal.
At first, I was thinking about using the lookup value of
relay_clientcerts to map a sasl username.
It is nicely done with your patch with smtpd_sasl_tls_ccert_username =
relay_clientcerts, but I need to go one step further:
I need to completely bypass the sasl provider call and act as if the
mapped user successfully authenticate.
It would be something like "smtpd_sasl_tls_ccert_username =
relay_clientcerts_nosasl" or relay_clientcerts_saslbypass or other (I'm
not good at finding good option naming ...)

The goal is to be as transparent as possible :
- if the client is not found in the relay_clientcerts, act as usual
- if the client is found in the relay_clientcerts, no longer announce
AUTH support, the auth and identity mapping is already done by the
relay_clientcerts map

I think it is not a big code complexity addition on top of your work,
but before going further I would like to request for comments about this.
Viktor, Wietse, would you accept such addition ?

Emmanuel.
Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

Viktor Dukhovni
On Wed, Mar 27, 2019 at 04:31:33PM +0100, Emmanuel Fusté wrote:

> The goal is to be as transparent as possible :
> - if the client is not found in the relay_clientcerts, act as usual
> - if the client is found in the relay_clientcerts, no longer announce
> AUTH support, the auth and identity mapping is already done by the
> relay_clientcerts map

I believe you're asking Postfix to (when configured to do that)
simulate "AUTH EXTERNAL" when the client has presented a client
certificate, but proceeds from "EHLO" to "MAIL FROM" with no
intevening explicit "AUTH".

The simulated "AUTH EXTERNAL" would never "fail" (5XX), it either
yields an authenticated user or proceeds with the user unauthenticated,
and acts accordingly.

Does that sound right?

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

Emmanuel Fusté-2
Le 27/03/2019 à 17:14, Viktor Dukhovni a écrit :

> On Wed, Mar 27, 2019 at 04:31:33PM +0100, Emmanuel Fusté wrote:
>
>> The goal is to be as transparent as possible :
>> - if the client is not found in the relay_clientcerts, act as usual
>> - if the client is found in the relay_clientcerts, no longer announce
>> AUTH support, the auth and identity mapping is already done by the
>> relay_clientcerts map
> I believe you're asking Postfix to (when configured to do that)
> simulate "AUTH EXTERNAL" when the client has presented a client
> certificate, but proceeds from "EHLO" to "MAIL FROM" with no
> intevening explicit "AUTH".
Yes exactly, if a hash to sasl id/username mapping is found in the
relay_clientcerts
>
> The simulated "AUTH EXTERNAL" would never "fail" (5XX), it either
> yields an authenticated user or proceeds with the user unauthenticated,
> and acts accordingly.
>
> Does that sound right?
Yes, in case of unauthenticated (not present in relay_clientcerts), the
simulated "AUTH EXTERNAL" must ideally not be performed and AUTH support
be announced as usual as this is perhaps a client with proper AUTH
support (otherwise it would be listed with a mapping in relay_clientcerts).
But I could live with an unconditional simulated "AUTH EXTERNAL" mode 
as clients not normally present a certificate.
I did not already dig in the code to see if it is doable in a "clean"
manner or if the unconditional simulated "AUTH EXTERNAL" mode is the
only way to go without too intrusive changes.

Emmanuel.
Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

Emmanuel Fusté-2
Le 27/03/2019 à 18:10, Emmanuel Fusté a écrit :

> Le 27/03/2019 à 17:14, Viktor Dukhovni a écrit :
>> On Wed, Mar 27, 2019 at 04:31:33PM +0100, Emmanuel Fusté wrote:
>>
>>> The goal is to be as transparent as possible :
>>> - if the client is not found in the relay_clientcerts, act as usual
>>> - if the client is found in the relay_clientcerts, no longer announce
>>> AUTH support, the auth and identity mapping is already done by the
>>> relay_clientcerts map
>> I believe you're asking Postfix to (when configured to do that)
>> simulate "AUTH EXTERNAL" when the client has presented a client
>> certificate, but proceeds from "EHLO" to "MAIL FROM" with no
>> intevening explicit "AUTH".
> Yes exactly, if a hash to sasl id/username mapping is found in the
> relay_clientcerts
>>
>> The simulated "AUTH EXTERNAL" would never "fail" (5XX), it either
>> yields an authenticated user or proceeds with the user unauthenticated,
>> and acts accordingly.
>>
>> Does that sound right?
> Yes, in case of unauthenticated (not present in relay_clientcerts),
> the simulated "AUTH EXTERNAL" must ideally not be performed and AUTH
> support be announced as usual as this is perhaps a client with proper
> AUTH support (otherwise it would be listed with a mapping in
> relay_clientcerts).
Ok, patch attached.
Need to be applied on top of Bastian one.
Work well here, thanks to the hard part done by Bastian !
Please comment.

Emmanuel.

sasl-cert-auto.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

lst_hoe02

Zitat von Emmanuel Fusté <[hidden email]>:

> Le 27/03/2019 à 18:10, Emmanuel Fusté a écrit :
>> Le 27/03/2019 à 17:14, Viktor Dukhovni a écrit :
>>> On Wed, Mar 27, 2019 at 04:31:33PM +0100, Emmanuel Fusté wrote:
>>>
>>>> The goal is to be as transparent as possible :
>>>> - if the client is not found in the relay_clientcerts, act as usual
>>>> - if the client is found in the relay_clientcerts, no longer announce
>>>> AUTH support, the auth and identity mapping is already done by the
>>>> relay_clientcerts map
>>> I believe you're asking Postfix to (when configured to do that)
>>> simulate "AUTH EXTERNAL" when the client has presented a client
>>> certificate, but proceeds from "EHLO" to "MAIL FROM" with no
>>> intevening explicit "AUTH".
>> Yes exactly, if a hash to sasl id/username mapping is found in the  
>> relay_clientcerts
>>>
>>> The simulated "AUTH EXTERNAL" would never "fail" (5XX), it either
>>> yields an authenticated user or proceeds with the user unauthenticated,
>>> and acts accordingly.
>>>
>>> Does that sound right?
>> Yes, in case of unauthenticated (not present in relay_clientcerts),  
>> the simulated "AUTH EXTERNAL" must ideally not be performed and  
>> AUTH support be announced as usual as this is perhaps a client with  
>> proper AUTH support (otherwise it would be listed with a mapping in  
>> relay_clientcerts).
>
> Ok, patch attached.
> Need to be applied on top of Bastian one.
> Work well here, thanks to the hard part done by Bastian !
> Please comment.
>
> Emmanuel.

This sounds like the feature we will need. I doubt the client would be  
able to do real AUTH, but we have to trust/relay based on the CN of a  
validated certificate. Is there any progress merging this in the 3.5  
line or do i have to poke around with patches some longer?

Thanks

Andreas


Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

Wietse Venema
[hidden email]:
> This sounds like the feature we will need. I doubt the client would be  
> able to do real AUTH, but we have to trust/relay based on the CN of a  
> validated certificate. Is there any progress merging this in the 3.5  
> line or do i have to poke around with patches some longer?

Yes and yes. It is ready when it is ready.

        Wietser
Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

lst_hoe02
In reply to this post by Emmanuel Fusté-2

Zitat von Emmanuel Fusté <[hidden email]>:

> Hello,
>
> Great piece of work ! It solve a big part of my problem, but sadly I  
> need to go deeper.
>
> Le 18/03/2019 à 22:45, Bastian Schmidt a écrit :
>> 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.
>
> I have to deal with products that do not support SMTP AUTH (big  
> email security appliance provider .....) but are able to present a  
> TLS certificate.
> On my platform, the use of the smtpd_sender_login_maps and  
> associated restrictions (reject_sender_login_mismatch) is mandatory  
> to achieve our goal.
> At first, I was thinking about using the lookup value of  
> relay_clientcerts to map a sasl username.
> It is nicely done with your patch with smtpd_sasl_tls_ccert_username  
> = relay_clientcerts, but I need to go one step further:
> I need to completely bypass the sasl provider call and act as if the  
> mapped user successfully authenticate.
> It would be something like "smtpd_sasl_tls_ccert_username =  
> relay_clientcerts_nosasl" or relay_clientcerts_saslbypass or other  
> (I'm not good at finding good option naming ...)
>
> The goal is to be as transparent as possible :
> - if the client is not found in the relay_clientcerts, act as usual
> - if the client is found in the relay_clientcerts, no longer  
> announce AUTH support, the auth and identity mapping is already done  
> by the relay_clientcerts map
>
> I think it is not a big code complexity addition on top of your  
> work, but before going further I would like to request for comments  
> about this.
> Viktor, Wietse, would you accept such addition ?
>
> Emmanuel.

I tested this with a patched postfix for my usage scenario (relaying  
based on validated CN) but i fail to get it work. Note that i don't  
need a sasl username at all, but also tested with sasl username and  
check_sasl_access.

The config basically looks like this:

smtpd_relay_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_sasl_access hash://etc/postfix/check_sasl_access,
        defer_unauth_destination

# tested both
#smtpd_sasl_tls_ccert_username = commonName
smtpd_sasl_tls_ccert_username = relay_clientcerts_auto
#relay_clientcerts = hash://etc/postfix/relay_clientcerts
smtpd_tls_loglevel = 2
smtpd_tls_ask_ccert = yes
smtpd_sasl_auth_enable = yes

smtpd_use_tls=yes
smtpd_tls_CApath = /etc/ssl/certs

But this leads to
Apr 18 11:46:05 linux-test postfix/smtpd[4257]:  
kw-tools.hq.kwsoft.de[10.1.7.15]: subject_CN=xxx.kwsoft.de,  
issuer=SwissSign Server Silver CA 2014 - G22,  
fingerprint=B8:D9:ED:1F:33:FE:DB:36:11:A6:D9:3F:BA:B5:1D:44,  
pkey_fingerprint=43:B6:FE:07:BB:2E:BF:86:8A:4D:2A:DD:78:07:09:C6
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: Trusted TLS connection  
established from kw-tools.hq.kwsoft.de[10.1.7.15]: TLSv1.2 with cipher  
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: NOQUEUE: reject: RCPT  
from kw-tools.hq.kwsoft.de[10.1.7.15]: 454 4.7.1 <[hidden email]>:  
Relay access denied; from=<[hidden email]> to=<[hidden email]>  
proto=ESMTP helo=<kw-tools>
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: disconnect from  
kw-tools.hq.kwsoft.de[10.1.7.15] ehlo=2 starttls=1 mail=1 rcpt=0/1  
data=0/1 rset=1 quit=1 commands=6/8

What i actually need is relaying based on validated certificate CN  
without forcing the client to use some form of authentication, so this  
would basically mean relay_clientcerts with CN lookup key or a  
relay_clientcerts_auto_cn to always skip AUTH and use the CN as  
username i guess.

Any other idea?

Thanks

Andreas

Any othe idea

Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

lst_hoe02
In reply to this post by Wietse Venema

Zitat von Wietse Venema <[hidden email]>:

> [hidden email]:
>> This sounds like the feature we will need. I doubt the client would be
>> able to do real AUTH, but we have to trust/relay based on the CN of a
>> validated certificate. Is there any progress merging this in the 3.5
>> line or do i have to poke around with patches some longer?
>
> Yes and yes. It is ready when it is ready.
>
> Wietser

What is the way to go to take part of the feature development? I looks  
like we need a slight modification of the auth external as described.

Thanks

Andreas


Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

Emmanuel Fusté-2
In reply to this post by lst_hoe02
Le 18/04/2019 à 12:05, [hidden email] a écrit :

>
> Zitat von Emmanuel Fusté <[hidden email]>:
>
>> Hello,
>>
>> Great piece of work ! It solve a big part of my problem, but sadly I
>> need to go deeper.
>>
>> Le 18/03/2019 à 22:45, Bastian Schmidt a écrit :
>>> 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.
>>
>> I have to deal with products that do not support SMTP AUTH (big email
>> security appliance provider .....) but are able to present a TLS
>> certificate.
>> On my platform, the use of the smtpd_sender_login_maps and associated
>> restrictions (reject_sender_login_mismatch) is mandatory to achieve
>> our goal.
>> At first, I was thinking about using the lookup value of
>> relay_clientcerts to map a sasl username.
>> It is nicely done with your patch with smtpd_sasl_tls_ccert_username
>> = relay_clientcerts, but I need to go one step further:
>> I need to completely bypass the sasl provider call and act as if the
>> mapped user successfully authenticate.
>> It would be something like "smtpd_sasl_tls_ccert_username =
>> relay_clientcerts_nosasl" or relay_clientcerts_saslbypass or other
>> (I'm not good at finding good option naming ...)
>>
>> The goal is to be as transparent as possible :
>> - if the client is not found in the relay_clientcerts, act as usual
>> - if the client is found in the relay_clientcerts, no longer announce
>> AUTH support, the auth and identity mapping is already done by the
>> relay_clientcerts map
>>
>> I think it is not a big code complexity addition on top of your work,
>> but before going further I would like to request for comments about
>> this.
>> Viktor, Wietse, would you accept such addition ?
>>
>> Emmanuel.
>
> I tested this with a patched postfix for my usage scenario (relaying
> based on validated CN) but i fail to get it work. Note that i don't
> need a sasl username at all, but also tested with sasl username and
> check_sasl_access.
>
> The config basically looks like this:
>
> smtpd_relay_restrictions =
>        permit_mynetworks,
>        permit_sasl_authenticated,
>        check_sasl_access hash://etc/postfix/check_sasl_access,
>        defer_unauth_destination
>
> # tested both
> #smtpd_sasl_tls_ccert_username = commonName
> smtpd_sasl_tls_ccert_username = relay_clientcerts_auto
> #relay_clientcerts = hash://etc/postfix/relay_clientcerts
You need the relay_clientcerts map with relay_clientcerts_auto mode.
Put the fingerprint or pkey_fingerprint and the mapped SASL identity in
the file and it will work
For example:
43:B6:FE:07:BB:2E:BF:86:8A:4D:2A:DD:78:07:09:C6    xxx.kwsoft.de

> smtpd_tls_loglevel = 2
> smtpd_tls_ask_ccert = yes
> smtpd_sasl_auth_enable = yes
>
> smtpd_use_tls=yes
> smtpd_tls_CApath = /etc/ssl/certs
>
> But this leads to
> Apr 18 11:46:05 linux-test postfix/smtpd[4257]:
> kw-tools.hq.kwsoft.de[10.1.7.15]: subject_CN=xxx.kwsoft.de,
> issuer=SwissSign Server Silver CA 2014 - G22,
> fingerprint=B8:D9:ED:1F:33:FE:DB:36:11:A6:D9:3F:BA:B5:1D:44,
> pkey_fingerprint=43:B6:FE:07:BB:2E:BF:86:8A:4D:2A:DD:78:07:09:C6
> Apr 18 11:46:05 linux-test postfix/smtpd[4257]: Trusted TLS connection
> established from kw-tools.hq.kwsoft.de[10.1.7.15]: TLSv1.2 with cipher
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Apr 18 11:46:05 linux-test postfix/smtpd[4257]: NOQUEUE: reject: RCPT
> from kw-tools.hq.kwsoft.de[10.1.7.15]: 454 4.7.1 <[hidden email]>:
> Relay access denied; from=<[hidden email]> to=<[hidden email]>
> proto=ESMTP helo=<kw-tools>
> Apr 18 11:46:05 linux-test postfix/smtpd[4257]: disconnect from
> kw-tools.hq.kwsoft.de[10.1.7.15] ehlo=2 starttls=1 mail=1 rcpt=0/1
> data=0/1 rset=1 quit=1 commands=6/8
>
> What i actually need is relaying based on validated certificate CN
> without forcing the client to use some form of authentication, so this
> would basically mean relay_clientcerts with CN lookup key or a
> relay_clientcerts_auto_cn to always skip AUTH and use the CN as
> username i guess.

Yes, if you don't want fingerprint to something maps, you need a
"commonName_auto" mode which rely on SASL external provider to validate
the user (provide the map of valid users) but auto triggered.
For that, you need to invoke SASL external auth directly in the smtpd
sasl glue code as it is in the processing of the AUTH verb (a simplified
single step version).
Will look at it if I have time, but I prefer to wait Viktor/Wietse
comments before.

Emmanuel.
Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

lst_hoe02

Zitat von Emmanuel Fusté <[hidden email]>:
> You need the relay_clientcerts map with relay_clientcerts_auto mode.
> Put the fingerprint or pkey_fingerprint and the mapped SASL identity  
> in the file and it will work
> For example:
> 43:B6:FE:07:BB:2E:BF:86:8A:4D:2A:DD:78:07:09:C6    xxx.kwsoft.de
>

Will try that, but for our final use case we have no way fix the  
fingerprint of the remote client, it can change any time. The only  
thing which should stay is the CN.

>> smtpd_tls_loglevel = 2
>> smtpd_tls_ask_ccert = yes
>> smtpd_sasl_auth_enable = yes
>>
>> smtpd_use_tls=yes
>> smtpd_tls_CApath = /etc/ssl/certs
>>
>> But this leads to
>> Apr 18 11:46:05 linux-test postfix/smtpd[4257]:  
>> kw-tools.hq.kwsoft.de[10.1.7.15]: subject_CN=xxx.kwsoft.de,  
>> issuer=SwissSign Server Silver CA 2014 - G22,  
>> fingerprint=B8:D9:ED:1F:33:FE:DB:36:11:A6:D9:3F:BA:B5:1D:44,  
>> pkey_fingerprint=43:B6:FE:07:BB:2E:BF:86:8A:4D:2A:DD:78:07:09:C6
>> Apr 18 11:46:05 linux-test postfix/smtpd[4257]: Trusted TLS  
>> connection established from kw-tools.hq.kwsoft.de[10.1.7.15]:  
>> TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
>> Apr 18 11:46:05 linux-test postfix/smtpd[4257]: NOQUEUE: reject:  
>> RCPT from kw-tools.hq.kwsoft.de[10.1.7.15]: 454 4.7.1  
>> <[hidden email]>: Relay access denied; from=<[hidden email]>  
>> to=<[hidden email]> proto=ESMTP helo=<kw-tools>
>> Apr 18 11:46:05 linux-test postfix/smtpd[4257]: disconnect from  
>> kw-tools.hq.kwsoft.de[10.1.7.15] ehlo=2 starttls=1 mail=1 rcpt=0/1  
>> data=0/1 rset=1 quit=1 commands=6/8
>>
>> What i actually need is relaying based on validated certificate CN  
>> without forcing the client to use some form of authentication, so  
>> this would basically mean relay_clientcerts with CN lookup key or a  
>> relay_clientcerts_auto_cn to always skip AUTH and use the CN as  
>> username i guess.
>
> Yes, if you don't want fingerprint to something maps, you need a  
> "commonName_auto" mode which rely on SASL external provider to  
> validate the user (provide the map of valid users) but auto triggered.
> For that, you need to invoke SASL external auth directly in the  
> smtpd sasl glue code as it is in the processing of the AUTH verb (a  
> simplified single step version).
> Will look at it if I have time, but I prefer to wait Viktor/Wietse  
> comments before.
>
> Emmanuel.

Thanks, so i will wait for comment if we can include our special case also.

Andreas



Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

Wietse Venema
In reply to this post by lst_hoe02
[hidden email]:
> What is the way to go to take part of the feature development? I looks  
> like we need a slight modification of the auth external as described.

Mailin glist discussions.

Eventually there will be a postfix-xxxx-nonprod release that combines
all the code (jay) and none of the guarantees (bleh).

I am not convinced that stuffing arbitrary PKI identities into a
SASL identity is necessarily a good idea. Maybe it is safer to solve
this problem without PKI-to-SASL cross-talk.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

lst_hoe02

Zitat von Wietse Venema <[hidden email]>:

> [hidden email]:
>> What is the way to go to take part of the feature development? I looks
>> like we need a slight modification of the auth external as described.
>
> Mailin glist discussions.
>
> Eventually there will be a postfix-xxxx-nonprod release that combines
> all the code (jay) and none of the guarantees (bleh).
>
> I am not convinced that stuffing arbitrary PKI identities into a
> SASL identity is necessarily a good idea. Maybe it is safer to solve
> this problem without PKI-to-SASL cross-talk.
>
> Wietse

At least in my case no SASL would be needed. For me a  
relay_clientcerts able to list allowed validated CNs would be enough.  
The SASL stuff will be handy for tie a "identity" to certificates and  
assign additional rights/limits of course.

Andreas

Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

Viktor Dukhovni
In reply to this post by Wietse Venema
> On Apr 18, 2019, at 12:01 PM, Wietse Venema <[hidden email]> wrote:
>
> Eventually there will be a postfix-xxxx-nonprod release that combines
> all the code (jay) and none of the guarantees (bleh).
>
> I am not convinced that stuffing arbitrary PKI identities into a
> SASL identity is necessarily a good idea. Maybe it is safer to solve
> this problem without PKI-to-SASL cross-talk.

I would expect the mapping to be indirect.  That is, a table lookup
key of either the client public key fingerprint to a SASL name (roughly
what we have now, but with an explicit RHS indicating the desired SASL
identity), or else the client's subject name in a standard (likely
RFC2254) form, again mapped to the desired identity, provided the
client certificate is from a trusted PKI issuer.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

Emmanuel Fusté-2
Le 18/04/2019 à 21:45, Viktor Dukhovni a écrit :

>> On Apr 18, 2019, at 12:01 PM, Wietse Venema <[hidden email]> wrote:
>>
>> Eventually there will be a postfix-xxxx-nonprod release that combines
>> all the code (jay) and none of the guarantees (bleh).
>>
>> I am not convinced that stuffing arbitrary PKI identities into a
>> SASL identity is necessarily a good idea. Maybe it is safer to solve
>> this problem without PKI-to-SASL cross-talk.
> I would expect the mapping to be indirect.  That is, a table lookup
> key of either the client public key fingerprint to a SASL name (roughly
> what we have now, but with an explicit RHS indicating the desired SASL
> identity), or else the client's subject name in a standard (likely
> RFC2254) form, again mapped to the desired identity, provided the
> client certificate is from a trusted PKI issuer.
>
Yes I agree. The proposed sasl provider dance is for a quick hack to not
have to implement the client subject name table lookup.

Emmanuel.
Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

Wietse Venema
In reply to this post by lst_hoe02
[hidden email]:

>
> Zitat von Wietse Venema <[hidden email]>:
>
> > [hidden email]:
> >> What is the way to go to take part of the feature development? I looks
> >> like we need a slight modification of the auth external as described.
> >
> > Mailin glist discussions.
> >
> > Eventually there will be a postfix-xxxx-nonprod release that combines
> > all the code (jay) and none of the guarantees (bleh).
> >
> > I am not convinced that stuffing arbitrary PKI identities into a
> > SASL identity is necessarily a good idea. Maybe it is safer to solve
> > this problem without PKI-to-SASL cross-talk.
>
> At least in my case no SASL would be needed. For me a  
> relay_clientcerts able to list allowed validated CNs would be enough.  
> The SASL stuff will be handy for tie a "identity" to certificates and  
> assign additional rights/limits of course.

One SASL-less option that I can think of is check_cname_access: map
the CNAME to an action. Requires that the certificate is verified.

Would that work? Thius approach avoids the mixing of PKI identities
and SASL identities.

Implementation note: this would require that check_cname_access
looks up a quoted string if the CNAME contains spaces. The postnap
command understands quoted strings as of Postfix 3.2.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: TLS client certificates and auth external

Michael Ströder
In reply to this post by Viktor Dukhovni
On 4/18/19 9:45 PM, Viktor Dukhovni wrote:

>> On Apr 18, 2019, at 12:01 PM, Wietse Venema <[hidden email]> wrote:
>>
>> Eventually there will be a postfix-xxxx-nonprod release that combines
>> all the code (jay) and none of the guarantees (bleh).
>>
>> I am not convinced that stuffing arbitrary PKI identities into a
>> SASL identity is necessarily a good idea. Maybe it is safer to solve
>> this problem without PKI-to-SASL cross-talk.
>
> I would expect the mapping to be indirect.  That is, a table lookup
> key of either the client public key fingerprint to a SASL name (roughly
> what we have now, but with an explicit RHS indicating the desired SASL
> identity), or else the client's subject name in a standard (likely
> RFC2254) form, again mapped to the desired identity, provided the
> client certificate is from a trusted PKI issuer.
Using a name instead of cert fingerprint also requires revocation checking.

Ciao, Michael.


smime.p7s (5K) Download Attachment
12