[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
DIT Traversal, Black Holes and Access Controls
Date forwarded: Fri, 19 Jun 1998 09:25:38 -0700 (PDT)
Date sent: Fri, 19 Jun 1998 10:23:35 -0600
From: "Ed Reed" <ED_REED@novell.com>
To: d.w.chadwick@iti.salford.ac.uk, howes@netscape.com,
ietf-ldapext@netscape.com
Subject: Re: LDAP Access Control
Forwarded by: ietf-ldapext@netscape.com
> David - a note on disallowing traversal of namespaces....
>
> We see this fairly often in customer requirements for enterprise
> directories. The engineering organization has a portion of the tree which
> is used for test purposes only, but for which it is convenient to have it
> linked into the rest of the namespace for single signon and name
> resolution purposes. However, they run the partitioning, schema
> management, and other aspects of the tree independently.
>
> Now, a high security research project comes along for which they want
> complete anonymity, but again, want to use their user names, etc defined
> in the public parts of the tree as part of their access controls and so
> forth in that portion of the tree.
>
> Note a few interesting things about resolve name operations in distributed
> directories, in this scenario...
>
> If you allow unauthenticated (ie, public) traversal of the namespace, it's
> quite possible to ascertain quite a lot about the organization and its
> view of itself.
this is where you need a GOOD access control model, (dare I say it) like
X.500. One of the reasons why X.500 ACI is so complex is so that tree
traversal is always allowed, but retreiving any information at all can be
completely disallowed. This is why we have the permissions such as
ReturnDN, which, if switched off, will ensure that tree traversal cannot retreive a
name if an operation is successful. Also, DiscloseOnError does a similar thing
for a failed operation. And since an operation can either only succeed or fail, we
have trapped the leaking of DNs in both cases.
I repeat that it should always be possible to traverse a tree but to retreive no
information from it. This has to be there so that high level domains such as
countries and states cannot block access to lower level domains such as
organisaitions.
> If you allow unauthenticated (ie, public) name resolution
> (for initial login, for instance) of objects in the hidden namespace, you
> AT LEAST have to allow visibility to the knowledge references for internal
> partitions within the namespace...which again provides quite a bit of
> information about it.
Again, not so. We tried to engineer X.500 so that Chaining would work, but
referrals would not be returned to the user (otherwise as you rightly point out,
the namespace is revealed). Clearly when you chain down the DIT, you are not
revealing anything, since the subordinate domain already knows the DNs of the
superior entries. Its a pity that LDAP does not support Chaining. We might
here have encountered a security/distributed directory problem with LDAP that
X.500 does not need to encounter.
>This would be particularly true in a Microsoft
> Active Directory Service, where each partition is doubling service as an
> NT domain.
>
Well I guess that's a problem that we did not design around when building
X.500:-)
> Bottom line is that some customers DO want to be able to create black
> holes in their namespace. And if you allow it, you have to treat it kind
> of like you do the ability to run without key recovery - if you lose the
> key, you've lost the data, with no recourse. Same thing applies to the
> namespace - if you create the black hole, and then fail to retain the
> ability to access and manage it, it's lost to you (unless you're willing
> to go in with database pointer editors to remove the blocking ACI -
> tantamount to key recovery in the example before).
>
This is actually a different scenario to the one I was painting. A black hole at
the bottom of the DIT (i.e.in the most subordinate domain) is not a problem to
anyone, but a black hole created at the top of the DIT is a severe problem to
those from a subordinate domain in the black hole who want to be visible and
not part of the black hole. If you are defining an international standard that
allows the one, you cannot easily disallow the other. Therefore X.500 did the
next best thing. It did not allow either, but it did allow the creation of a virtual
black hole in a single domain by the correct setting of the access control
policy. I personnaly think X.500 got it right here, when we are talking about an
Internet wide (as opposed to corporate wide) directory service.
> Such "fire walls" are certainly going to be necessary if corporate
> directories, like their networks, achieve greater connectivity to the
> outside, hostile world.
>
Firewalls are a different issue. We have built an extremely comprehensive
X.500/LDAP firewall at Salford which allows an organisation to create as many
black holes as it wants to the outside world.
David
> Ed
>
> -------------------
> Ed Reed, Technologist
> Group Technology Office
> Novell, Inc.
> +1 801 861 3320
>
> >>> "David Chadwick" <d.w.chadwick@iti.salford.ac.uk> 06/19/1998 01:51:36
> >>> >>>
>
>
>
***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 370 957 287
Email D.W.Chadwick@iti.salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
***************************************************