openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5207) Password checking: external program
by hadmut＠danisch.de 30 Oct '07

30 Oct '07

Full_Name: Hadmut Danisch Version: 2.3.38 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.180.64.93) Hi, that's a feature request: Sometimes it is necessary to use other authentication methods than the regular password login. E.g. when using an insecure computer in an internet cafe to login into a web mail frontend, which accesses an imap server, which authenticates against LDAP. It would require to authenticate trough one-time-passwords, HTTP-Cookies or other unusual methods. Actually,SASL provides a way to use other methods like One-time-passwords, but is still too limited and there are too many programs (LDAP clients) out there that don't support sasl authentication. Therefore it would be nice if slapd could be configured to do the password checking over some external plugin or program, which could do any sort of unusual checking. This way a user could enter a one time password just as a normal LDAP login password, and pass it through the chain of programs, e.g. mailclient - maildaemon - LDAP or browser - webmailer - imap - LDAP. regards Hadmut

1 0

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

30 Oct '07

[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(a)zimbra.com writes: > --On Monday, October 29, 2007 11:45 PM +0000 russell-openldap(a)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

1 0

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

30 Oct '07

quanah(a)zimbra.com writes: > --On Monday, October 29, 2007 11:45 PM +0000 russell-openldap(a)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

1 0

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

29 Oct '07

russell-openldap(a)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/

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:45 PM +0000 russell-openldap(a)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

1 0

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

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