Discussion:
smtpd_sasl_security_options clarification
(too old to reply)
Michael Fox
2016-07-11 16:59:21 UTC
Permalink
http://www.postfix.org/postconf.5.html#smtpd_sasl_security_options says "the
following security features are defined for the cyrus server .". Dovecot is
not mentioned. So, is it correct to interpret this to mean that this
postfix setting is a noop when dovecot is used for sasl authentication?



And how does Postfix know which authentication mechanisms to offer the
client? Does dovecot communicate this to postfix somehow?



Thanks,

Michael
Wietse Venema
2016-07-11 18:27:45 UTC
Permalink
Post by Michael Fox
http://www.postfix.org/postconf.5.html#smtpd_sasl_security_options says "the
following security features are defined for the cyrus server .". Dovecot is
not mentioned. So, is it correct to interpret this to mean that this
postfix setting is a noop when dovecot is used for sasl authentication?
Hmm. that file hasn't been updated in a while. The list appears to
be the same for dovecot.
Post by Michael Fox
And how does Postfix know which authentication mechanisms to offer the
client? Does dovecot communicate this to postfix somehow?
Dovecot tells Postfix the supported mechanism names and their
security properties. Postfix intersects that with the main.cf
settings, and announces the mechanisms that remain.

Wietse
Michael Fox
2016-07-11 20:40:10 UTC
Permalink
Post by Michael Fox
Post by Michael Fox
http://www.postfix.org/postconf.5.html#smtpd_sasl_security_options says
"the
Post by Michael Fox
following security features are defined for the cyrus server .".
Dovecot is
Post by Michael Fox
not mentioned. So, is it correct to interpret this to mean that this
postfix setting is a noop when dovecot is used for sasl authentication?
Hmm. that file hasn't been updated in a while. The list appears to
be the same for dovecot.
Post by Michael Fox
And how does Postfix know which authentication mechanisms to offer the
client? Does dovecot communicate this to postfix somehow?
Dovecot tells Postfix the supported mechanism names and their
security properties. Postfix intersects that with the main.cf
settings, and announces the mechanisms that remain.
Wietse
O.K. Thanks.

Can be more specific about which SASL mechanisms are allowed or disallowed
by each option? In other words, how do I know which mechanisms will be
disallowed with "noactive" or "nodictionary" or allowed by "forward_secrecy"
or "mutual_auth"? I'm unable to connect the dots.

Thanks,
Michael
Wietse Venema
2016-07-11 23:28:03 UTC
Permalink
Post by Wietse Venema
Dovecot tells Postfix the supported mechanism names and their
security properties. Postfix intersects that with the main.cf
settings, and announces the mechanisms that remain.
O.K. Thanks.
Can be more specific about which SASL mechanisms are allowed or disallowed
by each option? In other words, how do I know which mechanisms will be
disallowed with "noactive" or "nodictionary" or allowed by "forward_secrecy"
or "mutual_auth"? I'm unable to connect the dots.
You can find out about SASL active etc. attacks in RFC 4422
https://tools.ietf.org/html/rfc4422

Wietse
Michael Fox
2016-07-12 02:57:21 UTC
Permalink
Post by Michael Fox
In other words, how do I know which mechanisms will be
Post by Michael Fox
disallowed with "noactive" or "nodictionary" or allowed by
"forward_secrecy"
Post by Michael Fox
or "mutual_auth"? I'm unable to connect the dots.
You can find out about SASL active etc. attacks in RFC 4422
https://tools.ietf.org/html/rfc4422
Wietse
Thanks. Yes, that describes the attack categories. But it doesn't answer
the above question. Is the categorization documented somewhere? If not,
how are we to know?

Michael
Wietse Venema
2016-07-12 10:52:36 UTC
Permalink
Post by Michael Fox
Post by Wietse Venema
You can find out about SASL active etc. attacks in RFC 4422
https://tools.ietf.org/html/rfc4422
Thanks. Yes, that describes the attack categories. But it doesn't answer
the above question. Is the categorization documented somewhere? If not,
how are we to know?
This is standard terminology, and therefore not defined in either
Postfix or SASL RFC.

Active network attack: an attacker modifies the communication between
parties.

Mutual authentication: each party authenticates to the other party.

For more info I suggest a web search engine.

Wietse
Michael Fox
2016-07-13 03:38:42 UTC
Permalink
Post by Wietse Venema
This is standard terminology, and therefore not defined in either
Postfix or SASL RFC.
Active network attack: an attacker modifies the communication between
parties.
Mutual authentication: each party authenticates to the other party.
Thanks. But again, the question is *NOT* about the terminology or the
general meaning or definition of the categories. The question is
specifically asking which authentication mechanisms Postfix places in those
categories.
Post by Wietse Venema
For more info I suggest a web search engine.
If I could find the answer, I wouldn't need to ask the question. And
frankly, it doesn't matter what might be written elsewhere (which may or may
not be correct). All that matters is what is actually implemented in
Postfix, i.e. which mechanisms are effected by the various
smtpd_sasl_security_options categories.

Does anyone here know which mechanisms are effected by noactive,
nodictionary, forward_secrecy and mutual_auth? Or does everyone stick with
"noanonymous, noplaintext".

Thanks,
Michael
Peter
2016-07-13 03:56:30 UTC
Permalink
Post by Michael Fox
Thanks. But again, the question is *NOT* about the terminology or the
general meaning or definition of the categories. The question is
specifically asking which authentication mechanisms Postfix places in those
categories.
I think the actual security features list is dependant on the SASL
implementation, and which mechs satisfy each security feature is defined
in cyrus and dovecot sasl. I'm not certain but I think taht postfix
simply passes the list of security options you specify directly to the
SASL implementation and it selects the mechs based on that.

The short answer is, ask cyrus or dovecot.


Peter
Peter
2016-07-13 04:00:27 UTC
Permalink
Post by Peter
Post by Michael Fox
Thanks. But again, the question is *NOT* about the terminology or the
general meaning or definition of the categories. The question is
specifically asking which authentication mechanisms Postfix places in those
categories.
I think the actual security features list is dependant on the SASL
implementation, and which mechs satisfy each security feature is defined
in cyrus and dovecot sasl.
Dovecot tells Postfix the supported mechanism names and their
security properties. Postfix intersects that with the main.cf
settings, and announces the mechanisms that remain.
...so the list comes from Dovecot, you need to ask Dovecot what the
properties are of each mech.


Peter
Michael Fox
2016-07-13 04:30:20 UTC
Permalink
Post by Peter
I think the actual security features list is dependant on the SASL
implementation, and which mechs satisfy each security feature is defined
in cyrus and dovecot sasl.
Ah. So you're saying that for each auth mechanism configured in the SASL
implementation (dovecot in my case), the SASL implementation is sending
Postfix a tuple which includes the mechanism name and which categories it
fits into, rather than Postfix keeping a list of which mechanisms are in
each category.

Is that right? If so, then that's clear enough.

Michael
Peter
2016-07-13 04:48:27 UTC
Permalink
Post by Michael Fox
Ah. So you're saying that for each auth mechanism configured in the SASL
implementation (dovecot in my case), the SASL implementation is sending
Postfix a tuple which includes the mechanism name and which categories it
fits into, rather than Postfix keeping a list of which mechanisms are in
each category.
Is that right? If so, then that's clear enough.
Dovecot tells Postfix the supported mechanism names and their
security properties.
Peter
Michael Fox
2016-07-13 05:10:04 UTC
Permalink
Post by Wietse Venema
Dovecot tells Postfix the supported mechanism names and their
security properties.
O.K. Thanks.

I read but did not understand the quote above. Your explanation was clearer
and I understood it the first time.

Thanks again,
Michael

Continue reading on narkive:
Loading...