openldap-bugs

openldap-bugs@openldap.org

1 participants
21002 discussions

Re: (ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au 29 Oct '07

29 Oct '07

On Mon, 2007-10-29 at 18:07 +0100, Hallvard B Furuseth wrote: > No, you've forced users who authenticate against userPassword > to be encrypted. Not all SASL methods, nor auth with rootpw. Thats a worry. Rootpw aside, the intended objective of the ACL was to ensure passwords were never sent in the clear. Either a protocol like CRAM-MD5 was used, or the entire link is encrypted. Does it not do that? (Actually it doesn't. It should have been sasl_ssf=71. But bugs aside ...) Secondly, just out of curiosity, are there SASL methods that check a shared secret of some kind and don't use userPassword? What are they? The "security" option may produce better error messages by it appears to apply to all connections, including lookups done by SASL to dn="" to discover what mechanisms are allowed. It wasn't at all obvious to a newbie like me that this sentence from "man 1 ldapsearch" only applies if you don't use the "security" option: "-Y mech .... If it's not specified, the program will choose the best mechanism the server knows."

1 0

Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com 29 Oct '07

29 Oct '07

--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

1 0

Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com 29 Oct '07

29 Oct '07

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/

1 0

Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com 29 Oct '07

29 Oct '07

--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

1 0

Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com 29 Oct '07

29 Oct '07

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/

1 0

Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com 29 Oct '07

29 Oct '07

--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

1 0

Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com 29 Oct '07

29 Oct '07

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/

1 0

Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com 29 Oct '07

29 Oct '07

--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

1 0

Re: (ITS#5195) ssf not available during sasl bind
by h.b.furuseth＠usit.uio.no 29 Oct '07

29 Oct '07

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

1 0

Re: (ITS#5206) Admin guide: Berkeley DB version
by ghenry＠suretecsystems.com 29 Oct '07

29 Oct '07

> The admin guide says > "Generally, the most recent release [of Berkeley DB] > (with published patches) is recommended." > in CVS openldap-guide/admin/install.sdf and > <http://www.openldap.org/doc/admin23/install.html>. > > Not true with 4.6, and the advise on -software is still 4.2.52+patches: > http://www.openldap.org/lists/openldap-software/200710/msg00321.html > We have a versions table in the 2.4 guide and a link to it from the install section in the 2.4 version as well (below is not the latest version): http://suretec.org/our_docs/appendix-recommended-versions.html Haven't we already decided that we aren't updating the 2.3 guide? If we are now going to, then I can put in a big DEPRECATED for slurpd and fix above.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs