* Viktor Dukhovni <postfix-users@postfix.org>:
> On Tue, Jul 29, 2014 at 11:59:41PM +0200, Patrick Ben Koetter wrote:
>
> > > Which brings us back to the key question, what is the real motivation
> > > for this? Preventing HELO forgery? Making TLS access control easier
> > > to use (with "dane-only", one might be able to use check_helo_access
> > > safely, because certain HELO names would be authenticated)? Some sort
> > > of audit-trail that the client connection was not MiTMed?
> >
> > The use case goes like this:
> >
> > Company A and B agree to use TLS in order to protect communication. While it
> > is simple for A to create a policy that enforces TLS when they send to B,
> > there's no easy way for B to enforce TLS on their (inbound) side.
> >
> > B may create a SMTP TLS-only listener on a dedicated port/ip and tell A to
> > use
> > that. Alternatively, if the feature we are discussin at the moment, was in
> > place, they may as well create a policy that
> >
> > a) requires TLS if A's IP/hostname is used by the client
> > b) requests the client to send its ccert
> > c) verifies the clients ccert fingerprint matches one put down in a map
>
> What is the purpose of such enforcement? Thwarting MiTM attacks,
> or an audit trail of the cases when the "real A" sends unintercepted
> messages?
>
> > > What are we really gaining here? Note that active attackers on the
> >
> > The gain is mutual authentication. At the moment the SMTP server has no
> > means
> > to enforce TLS selectively on its default ip/port.
>
> Mutual authentication is surely not an end in itself. What purpose
> does it serve?
We have a few customers who must ensure that some parties use encrypted
transport when send messages to them. I'm looking for a mechanism to enforce
that on the default MX channel. It seems easier than spending hours telling
their operators how to configure their MTA to route messages to a dedicated
IP/port.
> > Correct me if I am wrong: Client-side DANE and/or ccert fingerprint matching
> > would be apt to prevent MiTM attacks.
>
> Perhaps by now you'll believe me that it can't. Rather it can
> prevent granting access rights to an authenticated party over an
> insecure channel. With SASL, if the client fails to authenticate
That's what I want.
> the server, the credentials are not channel-bound to the TLS crypto,
> and there could be an MiTM manipulating the authenticated session.
You've done a great job to explain why MiTM on the receiving side doesn't
work. Thank you. I concur.
> With client certs, whoever authenticated with the cert is also the
> party with the channel encryption keys. Thus SMTP client certs
> only prevent MiTM of specially authorized clients when they are
> accessing a suitably restricted service.
>
> Do you still want enhanced client certificate support? It is it
> too little gain for too much effort? (I'll probably build it
> anyway, so please speak freely).
Yes, I still want that. A long time ago we've discussed an analogy to
smtpd_sender_login_maps for TLS clients, where we bound envelope sender
addresses to TLS ccert fingerprints. I've attached the documentation I wrote
then, just in case you get carried away programming... :)
p@rick
--
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
smtpd_identity_sender_maps (default: empty) [former: smtpd_login_sender_maps]
Optional lookup table with identities that own envelope sender (MAIL
FROM) addresses.
A valid identity can either be
- a SASL login name
- a TLS client certificate fingerprint
- a TLS client public key fingerprint
Specify zero or more "type:table" lookup tables. With lookups from
indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or
SQL, the following
search operations are done with a sender address of user@domain:
1) user@domain
This table lookup is always done and has the highest precedence.
2) user
This table lookup is done only when the domain part of the sender
address matches $myorigin, $mydestination, $inet_interfaces or
$proxy_interfaces.
3) @domain
This table lookup is done last and has the lowest precedence.
In all cases the result of table lookup must be either "not found" or a
list of SASL login names, TLS client certificate fingerprints or TLS client
public key fingerprints separated by comma and/or whitespace.
permit_tls_clientcert_fingerprints
Permit the request when the remote SMTP client public key fingerprint
is listed in $relay_clientcerts. The fingerprint digest algorithm is
configurable via the smtpd_tls_fingerprint_digest parameter (hard-coded as md5
prior to Postfix version 2.5). See TLS_README for a discussion of the
permit_tls_clientcert_fingerprints feature.
This feature is available in Postfix 2.8 and later. In earlier releases
it was called permit_tls_clientcerts.
permit_tls_clientpkey_fingerprints
Permit the request when the remote SMTP client certificate fingerprint
is listed in $relay_clientcerts. The fingerprint digest algorithm is
configurable via the smtpd_tls_fingerprint_digest parameter (hard-coded as md5
prior to Postfix version 2.5). See TLS_README for a discussion of the
permit_tls_clientpkey_fingerprints feature
This feature is available in Postfix 2.8 and later. In earlier releases
it was called permit_tls_clientcerts.
relay_clientpkeys (default: empty)
List of tables with remote SMTP client TLS public key fingerprints for
which the Postfix SMTP server will allow access with the
permit_tls_clientpkey_fingerprints feature.
The fingerprint digest algorithm is configurable via the
smtpd_tls_fingerprint_digest parameter (hard-coded as md5 prior to Postfix
version 2.5).
Postfix lookup tables are in the form of (key, value) pairs.
Since we only need the key, the value can be chosen freely, e.g. the name of
the user or host:
D7:04:2F:A7:0B:8C:A5:21:FA:31:77:E1:41:8A:EE:80
sen...@example.com
Example:
relay_clientcerts = hash:/etc/postfix/relay_pubkeys
For more fine-grained control, use check_ccert_access to select an
appropriate access(5) policy for each client. See RESTRICTION_CLASS_README.
This feature is available with Postfix version 2.8.
smtpd_sender_restrictions (default: empty)
...
reject_authenticated_sender_identity_mismatch [former: ]
Enforces the reject_sender_identity_mismatch restriction for
authenticated clients only. This feature is available in Postfix version 2.8
and later. In earlier releases it was called
reject_authenticated_sender_login_mismatch.
reject_sender_identity_mismatch [former: reject_sender_login_mismatch]
Reject the request when $smtpd_identity_sender_maps specifies an
owner for the MAIL FROM address, but the client is not identified as that MAIL
FROM
address owner; or when the client is identified, but the client
identity doesn't own the MAIL FROM address according to
$smtpd_identity_sender_maps. This feature is available in Postfix version 2.8
and later. In earlier releases it was called reject_sender_login_mismatch.
reject_unauthenticated_sender_identity_mismatch [former:
reject_unauthenticated_sender_login_mismatch]
Enforces the reject_sender_identity_mismatch restriction for
unauthenticated clients only. This feature is available in Postfix version 2.8
and later. In earlier releases it was called
reject_unauthenticated_sender_login_mismatch.
