RE: New draft on knowledge references in LDAP

["Lloyd, Alan" <Alan.Lloyd@ca.com>]

All very good - but what about systems where one has to authenticate the
users.. and the referred to servers have to know all the users through their
directory entries. The ...

Security Considerations

   This document defines mechanisms that can be used to "glue" LDAP (and
   other) servers together. The information used to specify this glue
   information should be protected from unauthorized modification.  If the
   server topology information itself is not public information, the
   information should be protected from unauthorized access as well.


These LDAP referal systems are only possible where everybody on the system
is an un-authenticated user.. ie one user cannot authenticate to a server
unless that user (by DN) and password can verified and ACI applied.

Therefore for LDAP referrals to work at all in this type of system the
knowledge of the servers must be "public" to any user of the system. And the
User must face the "follow the web refs" approach to life. However, where an
organisation wants a real distributed directory service with a real
distributed authentication system with real ACI to provide system protection
and logical views of information (through distributed searches, etc) then
X.500 is still the only way to go.

If you want an authenticated system - with LDAP servers - then its replicate
everything to everywhere...and then one does not need referrals!

I think the security considerations should say...Because distributed mutual
authentication is not possible with LDAP servers - the referral knowledge
must always be public.


regards alan

-----Original Message-----
From: Roland Hedberg [mailto:roland@catalogix.ac.se]
Sent: Thursday, July 13, 2000 5:24 PM
To: Ramsay, Ron
Cc: Roland Hedberg; ietf-ldapext@netscape.com; roland@catalogix.ac.se
Subject: Re: New draft on knowledge references in LDAP 


Ron,

> I was a little confused by your description of the nssr attribute.
> 
> In a search result, do you actually return the attribute as part of the
> entry it is in?

No.
 
> The X.500 model would have the nssr attribute in the superior entry
> (otherwise it couldn't be non-specific) and wouldn't return it without the
> manageDsaIt bit. It is not clear to me how you intend it should be used.

The intention was that the 'nssr' attribute would act as it's X.500 
equivalent.

More specifically there are two special cases where 'refer;nssr' is
needed: 
1) where a organization wants to keep the authority for a entry
even is all the children to that entry is managed by another organization.
2) when someone would like to support onelevel searches in a efficient
way when several entries on one level resides on different servers.

> X500 compliant implementations would not return multiple entries relating
to
> the nssr entry.

I'm not sure, given that you don't have chaining and therefore can not
rely on any intermediate server to remove duplicated entries, how you 
would go about to avoid duplicated entries.
The servers involved have no idea what has happend before or what is 
happening after they get the query, both acts as if they where the only 
one asked. So only the client has the complete picture.

-- Roland
------------------------------------------------
Roland Hedberg      phone     : +47 23 08 29 96
Dalsveien 53        mobile(NO): +47 90 66 44 52
No-0775 Oslo        mobile(SE): +46 70 520 420 3
Norway