Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com
--On Monday, October 29, 2007 11:15 PM +0000 hyc(a)symas.com wrote:
> Stay focused on the original ITS topic.
Discussing further with Howard offline, he notes that ssf=<n> is the
minimum, not the requirement, so in the case I was thinking of:
security ssf=56
would be sufficient in that specific case, although all connections are
forced to be encrypted at that point. I'm not sure the security directive
then satisfies allowing anonymous binds to be unencrypted, which is why
then using ACL statements is a better route for that data you specifically
want to ensure is protected.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 11 months
Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com
Quanah Gibson-Mount wrote:
> --On Monday, October 29, 2007 10:57 PM +0000 hyc(a)symas.com wrote:
>> You don't. That would open you up to a downgrade attack.
> So I think the point of the ITS remains. It's difficult to do what they
> wanted to do. And really, sometimes all you care is that the connection is
> encrypted at a particular base level based on the type of encryption being
> done. Which is how it was at Stanford. Which apparently we don't support
> using the security directive. Which is why my acl's had sasl_ssf=56 all
> over them.
Your point and the original ITS are quite different. In your case, you want to
require a different SSF based on the underlying mechanism. That is foolish as
far as security policy goes; any attacker will simply ignore the stronger
defense and focus on breaking the weaker one. As the original poster stated,
security is only as strong as the weakest link.
Stay focused on the original ITS topic.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 11 months
Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com
--On Monday, October 29, 2007 10:57 PM +0000 hyc(a)symas.com wrote:
> You don't. That would open you up to a downgrade attack.
So I think the point of the ITS remains. It's difficult to do what they
wanted to do. And really, sometimes all you care is that the connection is
encrypted at a particular base level based on the type of encryption being
done. Which is how it was at Stanford. Which apparently we don't support
using the security directive. Which is why my acl's had sasl_ssf=56 all
over them.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 11 months
Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com
quanah(a)zimbra.com wrote:
> --On Monday, October 29, 2007 8:13 PM +0000 hyc(a)symas.com wrote:
>> You really need to read more carefully. If you only care about the
>> overall SSF, regardless of whether it's from TLS or SASL, then just use
>> the "ssf" factor. --
>
> Nice, in theory, but I think my example was bad. So let's rehash.
>
> When I was at Stanford, the SASL SSF max was 56, because of the DES keys.
> The TLS SSF was 128. So how would I indicate that I want EITHER a SASL SSF
> of 56 or a TLS SSF of 128 using the security directive?
You don't. That would open you up to a downgrade attack.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 11 months
Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com
--On Monday, October 29, 2007 8:13 PM +0000 hyc(a)symas.com wrote:
> You really need to read more carefully. If you only care about the
> overall SSF, regardless of whether it's from TLS or SASL, then just use
> the "ssf" factor. --
Nice, in theory, but I think my example was bad. So let's rehash.
When I was at Stanford, the SASL SSF max was 56, because of the DES keys.
The TLS SSF was 128. So how would I indicate that I want EITHER a SASL SSF
of 56 or a TLS SSF of 128 using the security directive?
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 11 months
Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com
quanah(a)zimbra.com wrote:
> --On Monday, October 29, 2007 5:08 PM +0000 h.b.furuseth(a)usit.uio.no wrote:
>
>
>> Also, repeating an old point, remember that the "security" keyword
>> produces better error messages ("Confidentiality required") than
>> "access ... ssf=..." ("Insufficient access" for updates, "Invalid
>> credentials" for Bind). With the latter, the user likely thinks
>> he mistyped the password and sends it again unencrypted.
> The problem with the security directive that the user ran into, however, I
> don't see a way to get around. Which is there is no "OR" support. I.e.,
> you can't say, I want the user to have a TLS of 128 OR SASL SSF of 128. If
> you specify both, both are required.
You really need to read more carefully. If you only care about the overall
SSF, regardless of whether it's from TLS or SASL, then just use the "ssf" factor.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 11 months
Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com
--On Monday, October 29, 2007 5:08 PM +0000 h.b.furuseth(a)usit.uio.no wrote:
> Also, repeating an old point, remember that the "security" keyword
> produces better error messages ("Confidentiality required") than
> "access ... ssf=..." ("Insufficient access" for updates, "Invalid
> credentials" for Bind). With the latter, the user likely thinks
> he mistyped the password and sends it again unencrypted.
The problem with the security directive that the user ran into, however, I
don't see a way to get around. Which is there is no "OR" support. I.e.,
you can't say, I want the user to have a TLS of 128 OR SASL SSF of 128. If
you specify both, both are required.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 11 months
Re: (ITS#5195) ssf not available during sasl bind
by h.b.furuseth＠usit.uio.no
quanah(a)zimbra.com writes:
> access to userPassword
> by anonymous auth sasl_ssf=128 break
> by anonymous auth tls=128
> by self read
>
> (At this point, you've forced any user to be encrypted,
No, you've forced users who authenticate against userPassword
to be encrypted. Not all SASL methods, nor auth with rootpw.
Also, repeating an old point, remember that the "security" keyword
produces better error messages ("Confidentiality required") than
"access ... ssf=..." ("Insufficient access" for updates, "Invalid
credentials" for Bind). With the latter, the user likely thinks
he mistyped the password and sends it again unencrypted.
Come to think of it, I guess I should insert that in the slapd.access(5)
manpage.
> so no need to duplicate the requirements on the read access).
--
Regards,
Hallvard
15 years, 11 months
