On Sun, Apr 18, 2021 at 08:49:34PM -0400, Demi Marie Obenour wrote:
> >> Each system is issued a certificate for its own domain. Perhaps a
> >> better example would be email Subject Alternative Names.
> >
> > That's not an example (use-case), it is a certificate field. What
> > is the use-case. With some specificity...
>
> If I were to run my own email server (I don’t, but I plan on doing
> so someday), my preferred means of authentication would be by client
> certificate. And I would want users to be able to send emails as a
> specific user if, and only if, I have issued them a certificate with
> the corresponding email address in the SAN.
Though you didn't quite say it explicitly, it seems that you have in
mind an MSA (submission) use-case. And you'd like to associate the the
email addresses that users are allowed to use with their certificates
(possibly as email address SANs, but see below).
> ... requiring authentication to even connect to the service avoids
> whole heaps of problems.
That's only true if one neglects many practical details.
> If the user doesn’t present a certificate, they aren’t going to even
> get an SMTP greeting, much less be able to send mail.
Perhaps true on port 465, but not quite on 587, though of course
establishing STARTTLS on 587 and getting to "AUTH" can mandate the same
client cert requirements.
> And that is extremely easy to validate: I just need to ensure that
> connections with no certificate, or with an invalid certificate, fail
> during TLS negotiation.
Well, the key question is what's an "invalid certificate"? An no longer
authorised user may still be in posession of a certificate that has not
yet expired, and so one way or another you'll need to distinguish
certificates of authorised users from certificates of formerly
authorised users.
I'd like to suggest that CRLs are by far the worst way to go about this,
and that therefore, you'll want a positive mapping (a table of
authorised certificates, mapping them to notional authorised users).
> Furthermore, client certificate authentication does not require any
> form of credentials (other than the server’s own certificate) to be
> stored on the server, nor does it require that the server have any
> form of authentication database.
Somewhat true, but the server still needs an authorisation database.
Which means that the mapping from certificate to user name may as
well happen outside the certificate, and will then be possible
to manage without reissuing certificates every time a user's
authorisation changes, ...
There was some discussion on the Postfix list some time back about
supporting the SASL TLS AUTH EXTERNAL mechanism with Dovecot. I
don't recall where it went, but the idea would be to map client
certificate fingerprints to SASL login names, the latter would then
be communicated by Postfix to the dovecot SASL backend as the
authenticated user name.
The rest of the session can then pretend that SASL auth took place, and
leverage the smtpd_sender_login_maps tables, check_sasl_access,
reject_sender_login_mismatch, ...
--
Viktor.
