Re: authentification

[Michael Weiser <michael@weiser.saale-net.de>]

On Tue, 5 Sep 2000, Kurt D. Zeilenga wrote:

> >another question regarding authentication: If I use ssfs to make my users
> >athenticate via secure (e.g. ssl) connections, is there any chance that
> >passwords get transmitted in clear across the wire?
> Yes.  You cannot stop clients from sending data in the clear (password,
> filter, DN).  You can however refuse to accept or act upon the data.
Mhmm, perhaps that's enough though. You cannot stop anybody from being
stupid. ;)
 
> >defaultaccess: none
> >
> >access to cn="cn=.*,o=org,c=de" filter=(objectClass=person) attr=userPassword
> >    by dn="cn=Manager,o=org,c=de" ssf=112 write
> >    by self ssf=112 =w
> >    by * ssf=112 =x
> currently you need to grant auth access to "entry" as well.
> This requirement will be dropped in 2.0.1.
I'm granting this access one acl later for searching of the directory but 
also run 2.0.1 since yesterday evening.
 
> >But what I want is that the user
> >can only initiate a authentification across ssl-connections and normal
> >ldap should never come so far transmitting a password. Can someone make me
> >get it? ;)
> You can configure the server to only listen for LDAP over SSL.
That's what I did before but unfortunately there are these SSL interaction
problems with netscape so I needed to open normal ldap again.

> However, LDAP over SSL is deprecated (in favor of Start TLS) as it
> is not a Standard Track mechanism.  You may run into clients which
> only support Start TLS.   The current solution is to disable simple
> bind unless TLS is present (by using an TLS SSF ACL) and then to
> only to deploy clients which support relatively strong authentication
> (GSSAPI or TLS+simple or DIGEST-MD5).  
Currently I'm using a generic ssf as you can see above. This leaves some
more options than just tls which I hope enables users to seamlessly use
other authentication/transport security methods like StartTLS once they
get available. Is that assumption right? Does it open any backdoors like
allowing clients to use weak authentication and then switch to secure
transport or authenticating securely and then using an unencrypted
channel?

BTW: As far as I understand StartTLS it's a mechanism for coordinate the
establishing of a tls connection which then runs normally. Are there any
mechanisms for enhancing the *normal* LDAP authentication, like some
cryptographic challenge-response method?

BTW2: If I run ldapsearch -ZZ I get

ldap_start_tls: Success

an nothing else. But if I do a ldapsearch -Z I get

WARNING: could not start TLS
version: 2

#
# filter: (objectclass=*)
# requesting: ALL
#

and then normal responses. Are these the StartTLS problems you mentioned
on -devel? (I'm not that mad about getting this to work since normal TLS
runs fine with the client tools but it's just good to know, I think. :)

> Note that if "cn=Manager,o=org,d=de" is your rootdn, then this
> ACL (like all others) is ignored.  I generally recommend rootdn
> only be set during initial loading of the directory... having
> all users go through ACLs is a good idea.
>
> Additional note: rootdn does not allow "disallows" nor
> forgives "requires" nor dishonors "security" requirements.
> These are applied across the board.
Oha, so the rootdn configured in slapd.conf stands outside of normal acl 
checking but honours configured requires/securities/disallows? So I'll try
deleting the rootdn from slapd.conf to make the server use the directory
one as you suggest. Or did I miss the point?
 
> I recommend using "security" to set reasonable minimums,
> something like:
> 
> security ssf=56 update_ssf=112
> 
> access to attr=userPassword
>         by self ssf=112 =w
>         by anon tls_ssf=112 =x
> 
> access to *
>         by self write
>         by users read
That's what I do now although that I cannot inforce ssf=56 since non-ssl
clients should be able to search the directory *but not* authenticate
against it. Quite difficult situation... :-\
-- 
bye, Micha