>One can build trusted application that require client certificates at
>SSL handshake to authenticate client connected. Directory should trust
>data extracted from client's certificate by the application (gateway).
>Can't imaging other way except really smart client capable of decoding
>directory's answer with his private key. Going this way one can use
>signed (with user's private key) instructions to modify directory that
>client capable of producing and server to understand. Don't sure
>such a directory (or gateway) and client software exists.
It sort of does exist, but the only one that I know of is (and I'm sure there are
others) on my hp workstation :-) (UMICH ldap3.3.1 / SSLeay-0.8.1) and its pretty buggy
(random crashes - but at least it runs). BUT, there are some very theoretical problems
that are very difficult to overcome, namely in the way referrals are handled. It
seems to work ok for local directory implementations, but .....
.......(some Notes of mine that are about a year old...)
ldap_set_rebind_proc() only affects referrals handled
by the client, I believe. If you are chaining referrals through
the servers then a intermediate server could choose its method
of communication with down-stream servers independently.
I believe the rebind_proc would be called whenever the client
acts on a non-chained referral, i.e., not just the first referral returned,
but every referral returned to the client. However, chained referrals are
not returned to the client unless the search succeeds or a downstream
server does not carry out another level of chained referral. Whether or
not referrals chain at the server is a parameter in the LDAP protocol.
If they don't chain at the server then they can still be handled by the
client. This could either be at the application level or at the LDAP
library level, as I recall. I'm not sure about a mixed model; that
might work as well.
........end old notes
You can probably start to see the big problem - i.e. #1 if I as a server send a
referral, there is no way to indicate to the client that the next bind should continue
with the secure authentication to the directory. And #2 the binding method of server
side chained referrals.
........AND from page 1 of the ldap v3 rfc (ftp://ds.internic.net/rfc/rfc2251.txt)
This document describes a directory access protocol that provides
both read and update access. Update access requires secure
authentication, but this document does not mandate implementation of
any satisfactory authentication mechanisms.
In accordance with RFC 2026, section 4.4.1, this specification is
being approved by IESG as a Proposed Standard despite this
limitation, for the following reasons:
a. to encourage implementation and interoperability testing of
these protocols (with or without update access) before they
are deployed, and
b. to encourage deployment and use of these protocols in read-only
applications. (e.g. applications where LDAPv3 is used as
a query language for directories which are updated by some
secure mechanism other than LDAP), and
c. to avoid delaying the advancement and deployment of other Internet
standards-track protocols which require the ability to query, but
not update, LDAPv3 directory servers.
Readers are hereby warned that until mandatory authentication
mechanisms are standardized, clients and servers written according to
this specification which make use of update functionality are
UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
Implementors are hereby discouraged from deploying LDAPv3 clients or
servers which implement the update functionality, until a Proposed
Standard for mandatory authentication in LDAPv3 has been approved and
published as an RFC.
---------end standards stuff
So for now, you either break the protocol and have no interoperability, or have weak
authentication. Essentially a lose/lose scenario.,
My .01 cents worth (deflation)
--
Andrew Gray
The Open Group
+-------------------------------------------------------------------------+
| Administrative requests should be sent to [EMAIL PROTECTED] |
| List service provided by Open Software Associates, http://www.osa.com/ |
+-------------------------------------------------------------------------+
