Using different encryption on localhost and networked connections

[Robert Henjes <henjes@informatik.uni-wuerzburg.de>]

Sorry for reopening / reasking the following issue.

I tried to scan through all posts, but this answer seemed to be the
closest one to my problem. (We're using OpenLDAP 2.4 on Debian Lenny)

Link:
http://www.openldap.org/lists/openldap-software/200409/msg00535.html
> If you're willing to concede that 127.0.0.0/8 will never appear outside of
> your loopback interface, you can synthesize this by checking peer IPs.
> 
> # 127.0.0.1 is allowed, regardless of ssf. world at large needs ssf check
> access to dn.<dnstyle1>=<what1>
>         by peername.ip=127.0.0.1 <access1>
>         by * none break
> # We're not coming via loopback; ssf must be checked.
> access to dn.<dnstyle1>=<what1>
>         by ssf=128 <access2>
>         by * none

Situation: 
For deployment we want to use TLS client certificates, as far as possible, using TLS encryption all the way long.

Problem:
Various LDAP client software and services do not support (TLS) client certificate verification. 

My proposed solution:
* All clients, which support client certificate verification, should directly connect using TLS to the LDAP server.
* All clients, esp. the management tools, should establish a ssh-tunnel to the server and connect through localhost entity.
* (optional) specific clients should be able to connect via specific access rules (but this is a future topic ;) )

Implementation:
This is not clear to me, how the previous posts are related to my problem, and how to configure the OpenLDAP server. 
I tried several scenarios with varying results, but no one was perfect yet.

Here a snippet of my current slapd.conf:
---------------
# the "ssl tls=1" is not necessary due to the special
# access rule in the remainder of this configuration

TLSCACertificateFile    /etc/ssl/CA/cacert.pem
TLSCertificateKeyFile   /etc/ssl/private/privkey.pem
TLSCertificateFile      /etc/ssl/certs/pubkey.pem
TLSVerifyClient         demand  # for highest security

# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
access to attrs=userPassword,shadowLastChange
        by peername.ip=127.0.0.1 write
        by ssf=128 dn="cn=admin,dc=example,dc=com" write
        by ssf=128 anonymous auth
        by ssf=128 self write
        by * none

# Security considerations (TESTING!!!!)
# http://www.openldap.org/lists/openldap-software/200409/msg00535.html
# access from 127.0.0.1 without encryption
access to dn.subtree="dc=example,dc=com"
        by peername.ip=127.0.0.1 write
        by * none break
# worldwide access requires tls encryption
access to dn.subtree="dc=example,dc=com"
        by ssf=128 write
        by * none

# Ensure read access to the base for things like
# supportedSASLMechanisms.  Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read

# The admin dn has full write access, everyone else
# can read everything.
access to *
        by dn="cn=admin,dc=example,dc=com" write
        by * read
---------------

Questions:
1) Turing off the option "ssl tls=1" means, a client can contact the server without encryption. If a password is transmitted, it will be rejected, but it is still transmitted unsecure. 
Due you have any recommendations according this issue?
Possible solution: The server only responds to unencrypted requests on the local interface. How can I achieve this? 
2) With the above presented solution, I can not change my own password as the desired user (Invalid credentials (49)), only as admin(root). Why?
3) What would be the appropriate way to achieve my goal?
 * Locking the dc=example,dc=com base from all unencrypted access from "worldwide" hosts. (admin should still have full access, but encryption has to be enforced)
 * Allowing access to the complete ldap tree without encryption from localhost

Thank you very much, any help or further link is appreciated. I spent almost one week now reading and completing the stuff, but sometimes it works, but a "whole" is left, otherwise only parts of the ldap server are accessible as desired.

Best regards,
Robert

P.S.: Though "googling" for several days now, I'm interested in any Link to a good website discussing the access rules besides the openldap documentation and presenting various use cases.


-- 
Dipl.-Inform. Robert Henjes
University of Wuerzburg,
Institute of Computer Science,
Chair of Distributed Systems (Informatik III),
Am Hubland, 97074 Wuerzburg, Germany

henjes@informatik.uni-wuerzburg.de
Tel: +49 931 31-86652
Fax: +49 931 888-6632