Prev: migration question
Next: bogus HELO name used
From: zhong ming wu on 24 Feb 2010 23:46
Dear List

I am using dovecot sasl with postfix smtp-auth. I also use tls with
both dovecot imap/pop server to retrieve mails and
also tls with postfix for submission to the relay server.

With dovecot I can have my mail client send a certificate and make
dovecote use CN field of the cert as username
to authenticate. If I enable that feature in dovecot, postfix
authentication does not work despite the fact that I am also
sending the same cert to postfix. I wonder if there is a way to do
that and I don't know how.

Also if I enable the feature "require client cert" with dovecot server
then postfix auth again does not work. Is that
because dovecot socket is not accepting cert information or postfix is
not sending the information? Any way to make it work?
What if I go with a cyrus sasl?

Any explanation on these issues will be appreciated.

Thanks

mr.wu.

From: Victor Duchovni on 25 Feb 2010 00:48
On Wed, Feb 24, 2010 at 11:46:10PM -0500, zhong ming wu wrote:

> With dovecot I can have my mail client send a certificate and make
> dovecote use CN field of the cert as username
> to authenticate. If I enable that feature in dovecot, postfix
> authentication does not work despite the fact that I am also
> sending the same cert to postfix. I wonder if there is a way to do
> that and I don't know how.

Postfix does not implement the "external" SASL mechanism for
authenticating users via TLS client certs.

> Also if I enable the feature "require client cert" with dovecot server
> then postfix auth again does not work. Is that
> because dovecot socket is not accepting cert information or postfix is
> not sending the information? Any way to make it work?
> What if I go with a cyrus sasl?

TLS is hop-by-hop, not end to end. With TLS the client authenticates
to the Postfix TLS library, not to any SASL plugin. Postfix has no
glue to communicate client certificate details to the SASL library.

Such glue would be fragile in any case, as one needs to be extremely
careful which CAs one is willing to trust in this context, and most
users would get this wrong and be open relays for anyone who can
get a client cert from a public CA. I do not recommend this feature.

If you want a decent SASL mechanism that is better than passwords,
use GSSAPI. Also, more MUAs support GSSAPI auth than client TLS auth.

--
Viktor.

P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment. If you are interested, please drop me a note.

From: zhong ming wu on 25 Feb 2010 13:42
On Thu, Feb 25, 2010 at 12:48 AM, Victor Duchovni
<Victor.Duchovni(a)morganstanley.com> wrote:

> Postfix does not implement the "external" SASL mechanism for
> authenticating users via TLS client certs.

So it sends user/password to dovecot socket and get yes/no answer?

>
> TLS is hop-by-hop, not end to end. With TLS the client authenticates

I would call a server dedicated only to my own users specifically for
relay at a submission port "end to end."

> Such glue would be fragile in any case, as one needs to be extremely
> careful which CAs one is willing to trust in this context, and most
> users would get this wrong and be open relays for anyone who can
> get a client cert from a public CA. I do not recommend this feature.

My dovecot server trusts certs signed by my own private CA. With
postfix I would think
it would be a matter of maintaining two separate lists of CA. This can
be done with a master.cf option for, say submission server, which
overrides the ca list of
public mx server; I have not tested this setup. If I were to maintain
two separate servers one
for submission and one for public mx this would be even less
susceptible to errors.
Come to think of it, there are two simple features I am asking:
"require client cert"
and pass the CN from cert to sasl server. After all postfix knows how
to ask cert from client
and knows how to parse CN from cert; I can see it write CN to log. Of
course these two features
should never be used in a public mx server.

There is also the difficult-to-implement feature of making sasl work
with postfix if dovecot has "require client cert" turned on
in which case the dovecot socket may be completely and not mentioned
in dovecot documentation.
BTW I asked a similar question to dovecot mailing list and my post
disappeared into a black hole.

>
> If you want a decent SASL mechanism that is better than passwords,
> use GSSAPI. Also, more MUAs support GSSAPI auth than client TLS auth.

I didn't know about GSSAPI but will look further into it.

Thanks for your explanation.

mr.wu

> --
>        Viktor.
>
> P.S. Morgan Stanley is looking for a New York City based, Senior Unix
> system/email administrator to architect and sustain our perimeter email
> environment.  If you are interested, please drop me a note.
>

From: Victor Duchovni on 25 Feb 2010 14:21
On Thu, Feb 25, 2010 at 01:42:27PM -0500, zhong ming wu wrote:

> > Postfix does not implement the "external" SASL mechanism for
> > authenticating users via TLS client certs.
>
> So it sends user/password to dovecot socket and get yes/no answer?

Postfix copies SASL protocol requests between the SMTP client and the
SASL library. Postfix does not know whether the packets contain passwords
for a PLAIN mechanism or some complex handshake for CRAM-MD5 or GSSAPI.

Regardless, Postfix has no support for "external" AUTH whether via TLS
or by other means.

> > TLS is hop-by-hop, not end to end. With TLS the client authenticates
>
> I would call a server dedicated only to my own users specifically for
> relay at a submission port "end to end."

I was explaining that the TLS connection terminates at the Postfix SMTP
server, and Dovecot does not see the TLS exchange, it is not end-to-end
from the the SMTP client to Dovecot. Disputing the explanation is unwise.
If it is unclear, feel free to ask further questions.

> > Such glue would be fragile in any case, as one needs to be extremely
> > careful which CAs one is willing to trust in this context, and most
> > users would get this wrong and be open relays for anyone who can
> > get a client cert from a public CA. I do not recommend this feature.
>
> My dovecot server trusts certs signed by my own private CA. With
> postfix I would think
> it would be a matter of maintaining two separate lists of CA.

I stand by my point, this would be a high-risk feature that a lot
of users would misconfigure.

Have you considered client cert fingerprints and check_ccert_access?

--
Viktor.

P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment. If you are interested, please drop me a note.

 | 
Pages: 1
Prev: migration question
Next: bogus HELO name used