Dovecot and Postfix client certificate authentication

Comments

• tlhackque

  Posted on vr 12 april 2019, in reply to.

  I share the goal of client certificate authentication to IMAP, while still allowing passwords by users without certificates.  However, I’m missing something in your description of how to accomplish this.

  I read in 10-auth.conf that auth_ssl_username_from_cert will take the DN_CN from the client certificate, and pass that as the username.  I don’t see ssl_cert_username_field documented there, but it is in the code.

  Presumably, plain and login won’t recognize the username (foo@example.com), so it will get to external - where you pass the username as %u.  That all makes sense - if foo@example.com is in the file, the lookup will succeed.

  On the other hand, telling my e-mail client to login with “foo” and “” will fail, as plain/login will reject it.  And “foo” isn’t in the external file.  This is all good.

  But: what prevents a user from telling their e-mail client to login with “foo@example.net” and “” (the null password)?  A malicious actor certainly knows the e-mail address that he is trying to access…

  I don’t see the access to EXTERNAL conditioned by the username coming from a validated certificate.  It seems to me that this is required.

  https://wiki.dovecot.org/Variables indicates that %k /%{cert} could be passed to an external driver to allow it to respond “unknown user” to lookups where the username doesn’t come from a validated certificate.  But I don’t see any reference to that.

  (I’m looking at the code of 2.2.31, and I don’t see these variables referenced, except by a test.)

  Presumably you avoided this scenario.  What am I missing?

  (I thought it would be necessary to write a custom driver to handle this case, but if you have solved all the problems, I don’t want to re-invent the wheel!)

  ---

  • Giel van Schijndel

    Posted on za 13 april 2019, in reply to.

    Hi tlhackque,

    I eventually switched away from this setup because of other, unrelated, deployment problems.

    I was using an older version of Dovecot than the 2.2.31 you’re referencing, so perhaps the %k variable you mention didn’t exist yet at that time. I definitely don’t recall seeing it before.

    As for how this should work: The mechanism filter, introduced with cdf00f5, expressed as mechanisms = external in the config file, should prevent the separate passdb from being used for anything else.

    I.e. I had two passdb entries. /etc/dovecot/users-external was one of those and I produced it by taking my regular /ect/dovecot/users and emptying all fields except the username one. The external database only got used for the EXTERNAL mechanism, and the regular database was still permitted for all mechanisms.

    This ensured that the empty password was only permitted (required actually) for the EXTERNAL mechanism. The username itself got taken from the emailAddress field of the certificate due to the ssl_cert_username_field setting. This ensures that the username being used is under control of the party controlling the CA.

    I don’t think I mentioned this very clearly in my blog post, but the EXTERNAL-specific password database config section was in addition to what was already present in the default config.

    This is the complete content of /etc/dovecot/conf.d/auth-passwdfile.conf.ext (taken from a backup):

    # Authentication for passwd-file users. Included from 10-auth.conf.
    #
    # passwd-like file with specified location.
    # <doc/wiki/AuthDatabase.PasswdFile.txt>
    
    passdb {
      driver = passwd-file
      args = scheme=CRYPT username_format=%u /etc/dovecot/users
    }
    
    # Password database intended only for use with SASL EXTERNAL
    # https://tools.ietf.org/html/rfc4422#appendix-A
    # Specifically the user is expected to be authenticated via a TLS client certificate instead
    passdb {
      driver = passwd-file
      args = scheme=PLAIN username_format=%u /etc/dovecot/users-external
    
      # specify this with Dovecot 2.30+ (or maybe 2.28+?): requires 10f6f2224c897fc543973efd2f46b86a3ab1148d
      mechanisms = external
    
      override_fields = nopassword
    }
    
    userdb {
      driver = passwd-file
      args = username_format=%u /etc/dovecot/users
    
      # Default fields that can be overridden by passwd-file
      default_fields = home=/var/mail/vhosts/%d/%n
    }