Logged in as guest
Viewing Incoming/5195 Full headers
Major security issue: yes no
Notes: Notification:
Date: Fri, 19 Oct 2007 05:33:44 GMT From: russell-openldap@stuart.id.au To: openldap-its@OpenLDAP.org Subject: ssf not available during sasl bind
Full_Name: Russell Stuart Version: 2.3.30 OS: Debian Etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.15.201.110) I am trying to insist that connections during sasl auth operations are encrypted. Ie, that this works: access to attrs=userPassword by tls_ssf=128 ssf=128 anonymous auth by * none It does work for a simple bind. But for a sasl bind it fails, and this telltale appears in the log: slapd[26499]: <= check a_authz.sai_ssf: ACL 128 > OP 0 I fixed the issue using this patch, which applies to 2.4.5, 2.3.38 and 2.3.30: diff -Nur openldap2.3-2.3.30/servers/slapd/sasl.c openldap2.3-2.3.30.new/servers/slapd/sasl.c --- openldap2.3-2.3.30/servers/slapd/sasl.c 2007-10-19 15:27:53.000000000 +1000 +++ openldap2.3-2.3.30.new/servers/slapd/sasl.c 2007-10-19 15:29:18.000000000 +1000 @@ -384,6 +384,7 @@ op.ors_slimit = 1; op.ors_filter = &generic_filter; op.ors_filterstr = generic_filterstr; + op.o_authz = conn->c_authz; /* FIXME: we want all attributes, right? */ op.ors_attrs = NULL;
Date: Fri, 19 Oct 2007 08:26:50 -0700 From: Howard Chu <hyc@symas.com> To: russell-openldap@stuart.id.au CC: openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
russell-openldap@stuart.id.au wrote: > I am trying to insist that connections during sasl auth operations are > encrypted. Ie, that this works: > > access to attrs=userPassword > by tls_ssf=128 ssf=128 anonymous auth > by * none > > It does work for a simple bind. But for a sasl bind it fails, and this telltale > appears in the log: > > slapd[26499]: <= check a_authz.sai_ssf: ACL 128 > OP 0 > > I fixed the issue using this patch, which applies to 2.4.5, 2.3.38 and 2.3.30: I suppose that may be a legitimate bug, but this isn't really the correct fix. slap_auxprop_lookup is doing an internal search, so there is no network to speak of. In SSF terms it would have an SSF of "infinity". > diff -Nur openldap2.3-2.3.30/servers/slapd/sasl.c > openldap2.3-2.3.30.new/servers/slapd/sasl.c > --- openldap2.3-2.3.30/servers/slapd/sasl.c 2007-10-19 15:27:53.000000000 > +1000 > +++ openldap2.3-2.3.30.new/servers/slapd/sasl.c 2007-10-19 15:29:18.000000000 > +1000 > @@ -384,6 +384,7 @@ > op.ors_slimit = 1; > op.ors_filter = &generic_filter; > op.ors_filterstr = generic_filterstr; > + op.o_authz = conn->c_authz; > /* FIXME: we want all attributes, right? */ > op.ors_attrs = NULL; > > > > . > -- -- 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/
Subject: Re: (ITS#5195) ssf not available during sasl bind From: Russell Stuart <russell-openldap@stuart.id.au> To: openldap-its@OpenLDAP.org Cc: russell-openldap@stuart.id.au Date: Thu, 25 Oct 2007 17:15:13 +1000
In one sense you are correct: the userPassword read by slap_auxprop_lookup will never be revealed. And so yes, the ssf for the results of that search would be infinity. But what I want to check is the weakest link in the chain. I can't imagine any instance when that isn't what you would want to check, so that is what the ssf should reflect. By definition, the slap_auxprop_lookup can never be the weakest link. The weakest link in this case when sasl sent the password to slapd. Really, what I want to say is if the password was sent in the clear, whether it be by sasl or simple auth, then the link must be encrypted. The patch makes the information required to do that test available.
Date: Thu, 25 Oct 2007 05:18:27 -0700 From: Howard Chu <hyc@symas.com> To: russell-openldap@stuart.id.au CC: openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
russell-openldap@stuart.id.au wrote: > In one sense you are correct: the userPassword read > by slap_auxprop_lookup will never be revealed. And > so yes, the ssf for the results of that search would > be infinity. > > But what I want to check is the weakest link in the > chain. I can't imagine any instance when that isn't > what you would want to check, so that is what the > ssf should reflect. By definition, the > slap_auxprop_lookup can never be the weakest link. > The weakest link in this case when sasl sent the > password to slapd. Really, what I want to say is if > the password was sent in the clear, whether it be by > sasl or simple auth, then the link must be encrypted. > > The patch makes the information required to do that > test available. Using ACLs to enforce this requirement is the wrong approach though. You should just use the "security" directive instead. With your approach you're missing the fact that SASL may not have sent any password at all to slapd (e.g., when using DIGEST-MD5 or an OTP mechanism). As such, you're imposing a constraint that makes no sense. -- -- 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/
Subject: Re: (ITS#5195) ssf not available during sasl bind From: Russell Stuart <russell-openldap@stuart.id.au> To: openldap-its@openldap.org Date: Fri, 26 Oct 2007 09:01:44 +1000
On Thu, 2007-10-25 at 05:18 -0700, Howard Chu wrote: > Using ACLs to enforce this requirement is the wrong approach though. You > should just use the "security" directive instead. With your approach you're > missing the fact that SASL may not have sent any password at all to slapd > (e.g., when using DIGEST-MD5 or an OTP mechanism). As such, you're imposing a > constraint that makes no sense. So you are saying: security sasl=128 simple_bind=128 would achieve that? I guess it would. However, with the patch applied this would have the same effect, with the addition that if some other authorisation mechanism were introduced (eg pam), it would fail unless it was encrypted or I explicitly allowed it. acl <password-stuff> by tls_ssf=128 ... read by sasl_ssf=128 ... read by * none This may look icky to you, but to someone who is just trying to deploy slapd it means there is one less slapd.conf option I have to get my head around. <rant> Perhaps ease of configuration doesn't seem so important. But I was at a talk given by Andrew Tridgell about why he wrote tdb instead of using just using openldap. Answer: because it took him 3 days to get slapd configured and working. 3 days is an impressively short time going on my experiences with it. He actually said it wasn't because slapd had bugs, or slapd was too slow, or slapd didn't have a feature. It was just because in the final analysis, he could not see the typical samba user being able to make the thing work. When something is hard to configure typically the doco is blamed. But that is often wrong and is wrong in the case of openldap. The blame lies with the design of the system. The programmers fail to see the configuration of the system as another interface. They will put hours of work into designing an API, and devote 100's of lines of code to making sure that API is easy to use, that it hides the complexities of its implementation. Yet they ignore configuration, which in effect another API - it is the interface between the users and the program. Like most projects openldap uses many libraries to do its thing. But makes no attempt to hide that from the user. In order to configure openldap you have to understand ldap, sasl, tls, berkley db, but whats worse you have to understand how they interact with each other within openldap. For example, ssf is a sasl concept. simple_bind is an ldap concept. But the "security" option has "simple_bind=<ssf_factor>", so suddenly you have to know both, even if you have no intention of using one of them. Ick, ick, ick. If it had of been an API presented to other programmers, I bet the original designer who of thought "how can I hide all this behind a simple, clean, easy to understand interface". But he didn't, and so now openldap deservedly has the reputation as one of the harder pieces of open source software to get up and going. As a consequence it is deployed a lot less than it should be. </rant>
Date: Thu, 25 Oct 2007 16:33:30 -0700 From: Howard Chu <hyc@symas.com> To: russell-openldap@stuart.id.au CC: openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
russell-openldap@stuart.id.au wrote: > On Thu, 2007-10-25 at 05:18 -0700, Howard Chu wrote: >> Using ACLs to enforce this requirement is the wrong approach though. You >> should just use the "security" directive instead. With your approach you're >> missing the fact that SASL may not have sent any password at all to slapd >> (e.g., when using DIGEST-MD5 or an OTP mechanism). As such, you're imposing a >> constraint that makes no sense. > > So you are saying: > > security sasl=128 simple_bind=128 > > would achieve that? I guess it would. > > However, with the patch applied this would have the same > effect, with the addition that if some other authorisation > mechanism were introduced (eg pam), it would fail unless > it was encrypted or I explicitly allowed it. > > acl <password-stuff> > by tls_ssf=128 ... read > by sasl_ssf=128 ... read > by * none > > This may look icky to you, but to someone who is just > trying to deploy slapd it means there is one less > slapd.conf option I have to get my head around. There are no shortcuts when it comes to security. If you don't take the time to understand it you'll get it wrong, period. That's true of all systems, no matter how simple or complex - if you don't take the time to understand the system's security requirements, you will screw up. As in your example above, which should use "auth" access, not "read" access. > <rant> > > Perhaps ease of configuration doesn't seem so important. > But I was at a talk given by Andrew Tridgell about why > he wrote tdb instead of using just using openldap. > Answer: because it took him 3 days to get slapd > configured and working. 3 days is an impressively > short time going on my experiences with it. He actually > said it wasn't because slapd had bugs, or slapd was too > slow, or slapd didn't have a feature. It was just > because in the final analysis, he could not see the > typical samba user being able to make the thing work. He should have come and talked to us. (In fact, since then, he has. We've shown how easily a canned Samba config can be setup, and we'll be collaborating closely on schema issues and other things down the road.) > When something is hard to configure typically the doco > is blamed. But that is often wrong and is wrong in the > case of openldap. The blame lies with the design of > the system. The programmers fail to see the > configuration of the system as another interface. They > will put hours of work into designing an API, and > devote 100's of lines of code to making sure that API > is easy to use, that it hides the complexities of its > implementation. Yet they ignore configuration, which > in effect another API - it is the interface between > the users and the program. You presume a lot here. Configuration in OpenLDAP 2.3 and 2.4 is a lot more rational than it ever was in prior releases, and that's because it has been the focus of considerable attention. The fact that your old methods still work, allowing you to limp along without reading about all the new methods, is a testament to the care that was taken in building the configuration enhancements. > If it had of been an API presented to other > programmers, I bet the original designer who of thought > "how can I hide all this behind a simple, clean, easy > to understand interface". But he didn't, and so now > openldap deservedly has the reputation as one of the > harder pieces of open source software to get up and > going. As a consequence it is deployed a lot less > than it should be. Nonsense. The primary reason OpenLDAP has a bad reputation in some circles is because distros like RedHat continued to bundle obsolete versions years after they had been dropped by the Project, and so a vast number of users were never exposed to the myriad improvements made over time. Regardless, OpenLDAP usage is still growing, and it looks like the growth will continue to accelerate. None of this discussion is relevant to this ITS. -- -- 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/
Subject: Re: (ITS#5195) ssf not available during sasl bind From: Russell Stuart <russell-openldap@stuart.id.au> To: openldap-its@openldap.org Date: Fri, 26 Oct 2007 10:22:02 +1000
On Thu, 2007-10-25 at 16:33 -0700, Howard Chu wrote: > There are no shortcuts when it comes to security. If you don't take the time > to understand it you'll get it wrong, period. That's true of all systems, no > matter how simple or complex - if you don't take the time to understand the > system's security requirements, you will screw up. As in your example above, > which should use "auth" access, not "read" access. I am not sure I agree, but to borrow your words a discussion about short cuts to security seems irrelevant to this ITS, as is whether I made a typo in my example. The rather long winded rant is relevant in one minor way (sorry about the length). In your original counter example, you said correctly "slap_auxprop_lookup" is doing an internal search and thus doesn't expose the password. The fact that I would have to know that in order to realise that "acl ... by tls_ssf=" doesn't do what I want is what I was railing against. It is purely a technical detail. When plain text is used, the password is sent over the connection. The fact happens not to be the copy in the slapd database (and thus as you say the copy in the database is infinitely secure) is irrelevant to me, the user. You said that if "you don't take the time to understand [the] security [model], you will get it wrong, period". Well there is room for movement at both ends. You can insist the user spends a long time understanding slapd's security model, or you can make the model easier to understand. I think the patch does the latter. If you think I am wrong, ie it makes slapd configuration harder to understand, then by all means reject it.
Subject: Re: (ITS#5195) ssf not available during sasl bind From: Russell Stuart <russell-openldap@stuart.id.au> To: openldap-its@OpenLDAP.org Cc: russell-openldap@stuart.id.au Date: Fri, 26 Oct 2007 19:40:35 +1000
I have now tried: security tls=128 sasl=128 It didn't work. All the commands below work without the 'security' option. ldapsearch -x -ZZ -D "uid=openldap,dc=auth,dc=lubemobile,dc=com,dc=au" -w "$(ssu cat /etc/libnss-ldap.secret)" -b "dc=pwd,dc=lubemobile,dc=com,dc=au" "(uid=it)" ldap_bind: Confidentiality required (13) additional info: SASL confidentiality required Which, when I think about it may be reasonable. I am apparently saying I require a sasl ssf of 128, and obviously I don't have that. This was a surprise though: ldapsearch -ZZ -U "openldap" -b "dc=pwd,dc=lubemobile,dc=com,dc=au" "(uid=it)" ldap_sasl_interactive_bind_s: Confidentiality required (13) additional info: SASL confidentiality required Is that a bug? Anyway, bugs aside, assuming I now have some idea how it works its useless for my application. I want to insist that userPassword to be encrypted when sent and received, be that via CRAM-MD5 or friends or by using TLS, but clear text is fine for the rest of the information in the ldap database, and in fact anonymous connections unencrypted connections are the rule for VPN access. The 'security' option applies to all connections. Anyway, to state the problem as clearly as I can, I can't see how to do the following combination of things: . Allow anonymous access over unencrypted connections for the bulk of the database. . Allow simple binds, but they must be over encrypted connections to protect userPassword. . Allow sasl binds over unencrypted connections, but the must not use clear text. . Not particularly relevant to me, but it would be nice to allow sasl binds using clear text if they are over an encrypted connection. The patch does this of course, but if there is some other way then the patch is irrelevant, except perhaps from a usability point of view.
Date: Fri, 26 Oct 2007 19:59:50 -0700 From: Quanah Gibson-Mount <quanah@zimbra.com> To: russell-openldap@stuart.id.au, openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
--On Friday, October 26, 2007 9:47 AM +0000 russell-openldap@stuart.id.au wrote: > I have now tried: > > security tls=128 sasl=128 > > It didn't work. All the commands below work without > the 'security' option. This says: Require a TLS section of 128 bit security AND SASL security of 128. > ldapsearch -x -ZZ -D "uid=openldap,dc=auth,dc=lubemobile,dc=com,dc=au" > -w "$(ssu cat /etc/libnss-ldap.secret)" -b > "dc=pwd,dc=lubemobile,dc=com,dc=au" "(uid=it)" ldap_bind: You aren't using SASL here. So of course it fails. > Which, when I think about it may be reasonable. I am > apparently saying I require a sasl ssf of 128, and > obviously I don't have that. This was a surprise > though: Right. > ldapsearch -ZZ -U "openldap" -b "dc=pwd,dc=lubemobile,dc=com,dc=au" > "(uid=it)" ldap_sasl_interactive_bind_s: Confidentiality required (13) > additional info: SASL confidentiality required > > Is that a bug? I suggest reading the part on sasl-secprops in the slapd.conf (5) man page. It notes that the default is to setting is to block anonymous and plain SASL binds. > Anyway, bugs aside, assuming I now have some idea how it > works its useless for my application. I want to insist > that userPassword to be encrypted when sent and received, > be that via CRAM-MD5 or friends or by using TLS, but clear > text is fine for the rest of the information in the ldap > database, and in fact anonymous connections unencrypted > connections are the rule for VPN access. The 'security' > option applies to all connections. access to userPassword by users read sasl_ssf=128 break by users read tls=128 I think might do it. > Anyway, to state the problem as clearly as I can, I can't > see how to do the following combination of things: > > . Allow anonymous access over unencrypted connections > for the bulk of the database. Above acl followed by access to * by * read (or however else limited). > . Allow simple binds, but they must be over encrypted > connections to protect userPassword. See above ACL. > . Allow sasl binds over unencrypted connections, but > the must not use clear text. Read the sasl-secprops setting. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Date: Fri, 26 Oct 2007 20:10:13 -0700 From: Quanah Gibson-Mount <quanah@zimbra.com> To: openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
--On Saturday, October 27, 2007 3:00 AM +0000 quanah@zimbra.com wrote: > access to userPassword > by users read sasl_ssf=128 break > by users read tls=128 Replace users by self, sorry. Obviously you don't want any user to read it. ;) Although hm, anonymous need access at least for auth, so: access to userPassword by anonymous auth by self read sasl_ssf=128 break by self read tls=128 Note that in the anonymous access case, the user password is never transmitted from the server end, in any case. You could do a similar requirement as above, something like: 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, so no need to duplicate the requirements on the read access). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Subject: Re: (ITS#5195) ssf not available during sasl bind From: Russell Stuart <russell-openldap@stuart.id.au> To: Quanah Gibson-Mount <quanah@zimbra.com> Cc: openldap-its@openldap.org Date: Sat, 27 Oct 2007 13:52:58 +1000
On Fri, 2007-10-26 at 19:59 -0700, Quanah Gibson-Mount wrote: > > ldapsearch -ZZ -U "openldap" -b "dc=pwd,dc=lubemobile,dc=com,dc=au" > > "(uid=it)" ldap_sasl_interactive_bind_s: Confidentiality required (13) > > additional info: SASL confidentiality required > > > > Is that a bug? > > > I suggest reading the part on sasl-secprops in the slapd.conf (5) man page. > It notes that the default is to setting is to block anonymous and plain > SASL binds. I suspect you are right in that is the cause of the problem because a -Y DIGEST-MD5 fixes it. But, as I said, it worked before the security option was added. It worked because DIGEST-MD5 was the default. So why isn't it the default now? Now that you have pointed it out, I guess that the addition of the 'security' option prevented SASL from searching dn="" for the types of authentications supported. > access to userPassword > by users read sasl_ssf=128 break > by users read tls=128 > > I think might do it. You would think that would do it - certainly I did. But you would be wrong. Currently it doesn't, and that is what this ITS is about. The patch I supplied with the initial bug report changes things so it does work.
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no> Date: Mon, 29 Oct 2007 18:07:35 +0100 To: openldap-its@openldap.org Cc: russell-openldap@stuart.id.au Subject: Re: (ITS#5195) ssf not available during sasl bind
quanah@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
Date: Mon, 29 Oct 2007 10:22:02 -0700 From: Quanah Gibson-Mount <quanah@zimbra.com> To: h.b.furuseth@usit.uio.no, openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
--On Monday, October 29, 2007 5:08 PM +0000 h.b.furuseth@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
Date: Mon, 29 Oct 2007 13:10:23 -0700 From: Howard Chu <hyc@symas.com> To: quanah@zimbra.com CC: openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
quanah@zimbra.com wrote: > --On Monday, October 29, 2007 5:08 PM +0000 h.b.furuseth@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/
Date: Mon, 29 Oct 2007 15:51:47 -0700 From: Quanah Gibson-Mount <quanah@zimbra.com> To: hyc@symas.com, openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
--On Monday, October 29, 2007 8:13 PM +0000 hyc@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
Date: Mon, 29 Oct 2007 15:54:58 -0700 From: Howard Chu <hyc@symas.com> To: quanah@zimbra.com CC: openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
quanah@zimbra.com wrote: > --On Monday, October 29, 2007 8:13 PM +0000 hyc@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/
Date: Mon, 29 Oct 2007 16:04:51 -0700 From: Quanah Gibson-Mount <quanah@zimbra.com> To: hyc@symas.com, openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
--On Monday, October 29, 2007 10:57 PM +0000 hyc@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
Date: Mon, 29 Oct 2007 16:12:42 -0700 From: Howard Chu <hyc@symas.com> To: Quanah Gibson-Mount <quanah@zimbra.com> CC: openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
Quanah Gibson-Mount wrote: > --On Monday, October 29, 2007 10:57 PM +0000 hyc@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/
Date: Mon, 29 Oct 2007 16:31:58 -0700 From: Quanah Gibson-Mount <quanah@zimbra.com> To: hyc@symas.com, openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
--On Monday, October 29, 2007 11:15 PM +0000 hyc@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
Subject: Re: (ITS#5195) ssf not available during sasl bind From: Russell Stuart <russell-openldap@stuart.id.au> To: Hallvard B Furuseth <h.b.furuseth@usit.uio.no> Cc: openldap-its@openldap.org Date: Tue, 30 Oct 2007 09:45:12 +1000
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."
Date: Mon, 29 Oct 2007 18:38:25 -0700 From: Quanah Gibson-Mount <quanah@zimbra.com> To: russell-openldap@stuart.id.au, openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
--On Monday, October 29, 2007 11:45 PM +0000 russell-openldap@stuart.id.au wrote: > 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? GSSAPI -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Date: Mon, 29 Oct 2007 18:53:26 -0700 From: Howard Chu <hyc@symas.com> To: russell-openldap@stuart.id.au CC: openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
russell-openldap@stuart.id.au wrote: > 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. By the way, CRAM-MD5 has a few known weaknesses. Should use DIGEST-MD5 instead. http://www.ietf.org/rfc/rfc2831.txt (For what that's worth. Given that methods exist to create MD5 collisions, it's not clear how much longer DIGEST-MD5 will be useful.) > 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." Perhaps we should add a security option to separately specify the SSF for anonymous sessions. -- -- 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/
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no> Date: Tue, 30 Oct 2007 09:27:35 +0100 To: quanah@zimbra.com Cc: openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
quanah@zimbra.com writes: > --On Monday, October 29, 2007 11:45 PM +0000 russell-openldap@stuart.id.au > wrote: >> 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? > > GSSAPI And all SASL methods that use passwords, if SASL is configured to use another password store than slapd. Like Cyrus SASL's default sasldb. -- Regards, Hallvard
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no> Date: Tue, 30 Oct 2007 09:31:05 +0100 To: russell-openldap@stuart.id.au Cc: openldap-its@openldap.org Subject: Re: (ITS#5195) ssf not available during sasl bind
[Resending, I forgot Russell wasn't in the to/cc list of your reply. Don't know if that means he didn't receive it or if ITS did something clever.] quanah@zimbra.com writes: > --On Monday, October 29, 2007 11:45 PM +0000 russell-openldap@stuart.id.au > wrote: >> 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? > > GSSAPI And all SASL methods that use passwords, if SASL is configured to use another password store than slapd. Like Cyrus SASL's default sasldb. -- Regards, Hallvard
______________ © Copyright 2009, OpenLDAP Foundation, info@OpenLDAP.org
