[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: gluing directories with draft-ietf-ldapext-locate-02.txt



Sorry, but I have to respond to this one...

Customers assume that you've done the leg work and are delivering a secure system (I know - bad assumption, but...) If you offer an insecure system as an option, I think you've misrepresented some things (including what current technologies can do).

I agree with the fact that current technologies are weak in the security aspect, but I still find the SRV option useful. Assume that I've practiced all of the due diligence necessary to protect data from anonymous access. Assume further that I've arbitrated trust relationships between other (similar) institutions. Is it not useful to be able to discover services for which I'm eligible?

I think there is a tendency to consider these deployments insecure because they place the onus of security on the implementer rather than the protocol designer. That's OK in my book (although it means some additional work). More options means more flexibility (and yes, more potential to build an insecure system, but whose job is it to watch after the bottom line if not the local admin's).

        --Tom

At 08:09 PM 5/15/00 -0400, Lloyd, Alan wrote:
The fundamental problem is LDAP servers and referrals are absolutely useless
if one has any notion of authenticating users and providing logical
views/management of information across a distributed environment - according
to a trusted common authentication and ACI regime..

Given the whole world has be beat up over the last three months on the
internet by unidentified users - why do these developments NOT consider
security in any approaches!!!! ??????


Sorry - customers want commercial strength scaleable, deterministic, distributed protected directory services - the proposal is unworkable in this context..

regards alan

        -----Original Message-----
        From:   Sukanta Ganguly
        Sent:   Tuesday, May 16, 2000 2:03 AM
        To:     Alan.Lloyd@ca.com; ietf-ldapext@netscape.com;
Kurt@OpenLDAP.org
        Subject:        RE: gluing directories with
draft-ietf-ldapext-locate-02.txt

        Alan,
           I did not read so deeply into Kurt's proposal. But from what I
understood, since the DNS SRV records were used for advertising LDAP
servers, one could easily leverage it for gluing directories. Not to mention
the fact that this will not be the ONLY approach that will ever exists. If
the LDAP server provides the smarts for doing so I think clients would be
pleased to get better referals. Don't you?
           I do agree with your views, and I think I get it correct, that
with the DNS SRV approach, proper "service" oriented advertisements is not
yet defined. I would like a better mechanism wherein services hosted by LDAP
servers are properly defined so that service vendors could use a proper
advertising template and provide the relevant information and I as a service
consumer could lookup the "NET" and with some good and smart query tool
exactly locate the service vendor who would be ready to service my
requirements within the resource limits I specify. This is analogous to the
web approach taken today. I am thinking, dreaming and haven't had any formal
or informal discussions with anybody on this yet. I was planning on sending
an email to Bob Morgan/Paul Leach to run this idea by them and see what they
think about. This email actually brought me into the the mood of writing
this down and emailing it to everybody. Give me your thoughts on this.

        SG
        sganguly@novell.com <mailto:sganguly@novell.com>


>>> "Lloyd, Alan" <Alan.Lloyd@ca.com> 05/14/00 08:47PM >>> Is anyone concerned that "gluing directories with LDAP" is only providing a system which is slow, has lots of overheads, is more complex than X.500 and will only deal with publically accessable attributes for non authenticated users. - ie one cannot put a consistent ,distributed authentication and access control regime over this AND one cannot do predictable (response time) distributed searches that are controlled/protected by the server at the client access point - or provide "service" based correlation of the responses according to User profiles or domain access control settings.

        To me this is definitely not what "large scale" directory users
want...an
        unprotected, uncoordinated, non deterministic "information"
infrastructure

        Sorry - Just my views

        regards alan


-----Original Message----- From: Kurt D. Zeilenga Sent: Saturday, May 13, 2000 6:10 AM To: ietf-ldapext@netscape.com Subject: gluing directories with draft-ietf-ldapext-locate-02.txt

            The intro to this draft states this may be used by clients
            (or servers acting as clients).  I'd like to add that it
            may also be used by servers acting as servers to generate
            appropriate referrals to requests not held by the server.
            That is, if a client requests a DN not held by a server,
            that server could use DNS SRV to produce a suitable
            referral to the client.

            I have an example of such a server operating (experimentally)
            at ldap://root.openldap.org.  <ldap://root.openldap.org. >  It
will generate LDAPv3 (and
            LDAPv2+) referrals using the method similar to that described
            in the I-D.

            Enjoy!
                Kurt

            // pseudo code: real code is available from OpenLDAP public
            // source repository.
http://www.openldap.org/software/repo.html
<http://www.openldap.org/software/repo.html>
            domain=NULL
            foreach( rdn of dn ) // left to right
            {
                if multiple value rdn {
                    domain=NULL;
                    continue;
                }
                if rdn attribute type == "dc" {
                    if( domain != NULL ) {
                        domain = concat( domain, "." );
                    }
                    domain = concat( domain, rdn value );
                    continue;
                }
                domain=NULL;
            }

            if( domain != NULL ) {
                if( DNSSRV( domain ) ) {
                    return referral;
                }
            }
            return noSuchObject;