Network Working                                  S.E. Hardcastle-Kille
Group                                        University College London
INTERNET-DRAFT                                                T. Howes
                                                University of Michigan
                                                        September 1991







         An Access Control Approach for Searching and Listing








Status of this Memo
This memo defines an extended ACL (Access Control List) mechanism for
the OSI Directory.  It is intended to meet strong operational
requirements to restrict searching and listing externally, while
allowing much more freedom within an organization.  In particular,
this mechanism makes it possible to restrict searches to certain sets
of attributes, and to prevent ``trawling'':  the disclosure of large
organizational data or structure information by repeated searches or
lists.  This capability is necessary for organizations that want to
hide their internal structure, or to prevent dumping of their entire
database.  This memo describes functionality beyond, but compatible
with, that expected in the 1992 X.500 standard.
This draft document will be submitted to the RFC editor for
information only.  Distribution of this memo is unlimited.  Please
send comments to the author or to the discussion group
<osi-ds@CS.UCL.AC.UK>.




INTERNET--DRAFT      Search and List Access Control     September 1991


1  Introduction

This memo defines an extended ACL (Access Control List) mechanism for
the OSI Directory.  It is intended to meet strong operational
requirements to restrict searching and listing externally, while
allowing much more freedom within an organization.  In particular,
this mechanism makes it possible to restrict searches to certain sets
of attributes, and to prevent ``trawling'':  the disclosure of large
organizational data or structure information by repeated searches or
lists.  This capability is necessary for organizations that want to
hide their internal structure, or to prevent dumping of their entire
database.  This memo describes functionality beyond, but compatible
with, that expected in the 1992 X.500 standard.
The mechanism proposed also allows the Administrative limit to be used
for system protection, rather than for access control purposes.  This
is useful, as the administrative limit is in practice ineffective as a
means of access control.


2  Search Control


A search access control is defined, which can be applied to subtree,
single level, or base object.  This last option is used to protect a
specific object from searching, and applies to the object during any
type of search.
This ACL controls who may and may not search by certain attributes,
and the number of entries that may be returned from a search on the
allowed attributes.  The normal single entry ACL still controls which
information may be returned from each entry.
This ACL approach will work consistently within a single DSA. When a
search is traversed over multiple DSAs and a SearchACL is being
applied, if a Security Error is returned, it should be assumed that
the overall ACL has been violated and a Security Error returned for
the whole search.

The ACLs are multiple value, and the most generous applicable should
be used.


SearchACL ATTRIBUTE
        WITH ATTRIBUTE-SYNTAX SearchACLSyntax



Hardcastle-Kille and Howes                                      Page 1




INTERNET--DRAFT      Search and List Access Control     September 1991



SearchACLSyntax ::= SEQUENCE -
        who AccessSelector,
         scope BITSTRING -
                subtree(1),
                single-level(2),
                base-object(3) " DEFAULT -subtree, single-level",
        max-results INTEGER,  -- limit for this category
        attribute-selection CHOICE -
           searchable-attributes [1] SET OF AttributeType,
           unsearchable-attributes [2] SET OF AttributeType
           ",
        min-key-length-in-substring INTEGER OPTIONAL,
        zero-results-if-limit-exceeded BOOLEAN DEFAULT TRUE
                "



The syntax works as follows:


who Controls who the syntax applies to

scope Defines the scope of the access control

max-results Defines the maximum number of results which can be
    returned.

attribute-selection Searchable attributes can be specified by
    inclusion or exclusion.  The ability to search or not to search
    the default set of attributes (those not explicitly specified
    elsewhere) can be specified by use of a null list in
    unsearchable-attributes and searchable-attributes respectively.

min-key-length-in-substring Gives minimum length to prevent dumping
    using a* b* in repeated searches.  This length should also be
    applied to filter items which compare string attributes.  Where a
    string range is identified, it must be narrower than
    min-key-length-in-substring.  For example if
    min-key-length-in-substring is 4, then a range abcde* to abcdf* is
    acceptable, whereas abcx* to abcy* is not.

zero-results-if-limit-exceeded Only return results if search is
    precise enough to match less than the limit.  This will usually be

Hardcastle-Kille and Howes                                      Page 2




INTERNET--DRAFT      Search and List Access Control     September 1991


    the case, as it is needed to block intelligent trawling.  If
    zero-results-if-limit-exceeded component is set to TRUE and the
    max-results limit is exceeded, no results shall be returned and
    the entire search is abandoned with a security error.  If
    zero-results-if-limit-exceeded component is set to FALSE and the
    max-results limit is exceeded, partial results are returned just
    as if a size limit had been reached, and the current portion of
    the search is abandoned.

Note that there may be a requirement to detect downloading by very
large numbers of repeated searches.  Mechanisms to prevent this will
be investigated in the light of experience.


2.1  Single Level Search

During a single level search, the application of the single level
search ACL is straight forward.  The ACL of the superior object is
used for the duration of the search, even if aliases are dereferenced
(i.e., the original ACL is used in this case, not the parent of the
object the alias points to if different from the original superior
object).  SearchACLs with scope base-object in each of the matched
entries should be examined.


2.2  Subtree Search

During a subtree search, the application of the subtree search ACL is
more complicated, since a subtree search may recurse over multiple
sub-subtrees.  When a sub-subtree is encountered during the search,
its subtree ACL should apply to the elements of the sub-subtree, if it
is more restrictive than the currently applicable subtree ACL. Note
that this same policy applies when aliases are involved, and the
searchaliases option is set.  In this case, the currently applicable
ACL is taken from the point of the alias, not from the ``natural''
parent of the aliased subtree as it appears in the DIT. This means
that a subtree ACL at the base of a subtree may not be sufficient to
protect the component sub-subtrees from unauthorized search.
During a subtree search, if any current search ACL is exceeded, the
current portion of the search is abandoned with a security error or a
size limit exceeded with partial results, depending on whether the ACL
exceeded had the no-results-if-limit-exceeded flag set.



Hardcastle-Kille and Howes                                      Page 3




INTERNET--DRAFT      Search and List Access Control     September 1991


3  List Control

A simplified version of search control is used to control listing.
This can be used to control listing at the base object of a list, or
to restrict listing of individual objects.


ListACL ATTRIBUTE
        WITH ATTRIBUTE-SYNTAX ListACLSyntax

ListACLSyntax := SearchACLSyntax
        (
                WITH COMPONENTS
                        -
                                who,
                                scope (single-level _ base-object),
                                max-results
                        "
        )



To prevent listing of an individual object, scope should be set to
base-object and max-results to zero.  This strategy will allow the
Admin limit to be used to do system protection, rather than for pseudo
ACL purposes.


4  Authentication Policy

In order to make this ACL mechanism useful, we need to address the
issue of authentication policy.  In validating the who component of
the ACLs defined above, we would like to be able to specify different
levels of security.  For example, a trusting individual might want to
believe all names, even those supplied over unauthenticated DSP, while
another might want names to be strongly authenticated, and another
might view the middle ground of simple authentication as sufficient.
The following attribute applies to the single object in which it
appears, though it will usually be inherited throughout an entire
subtree.



AuthenticationPolicy ATTRIBUTE

Hardcastle-Kille and Howes                                      Page 4




INTERNET--DRAFT      Search and List Access Control     September 1991


        WITH ATTRIBUTE-SYNTAX AuthenticationPolicySyntax
        SINGLE VALUE

-- Applies to any ACLs resident in the entry

AuthenticationPolicySyntax ::= SEQUENCE -
        modification AuthenticationPolicy,
        read-and compare AuthenticationPolicy,
        list-and-search AuthenticationPolicy "

AuthenticationPolicy ::= ENUMERATED -
        trust-name (0), -- believe supplied name which must be present
                        -- used if DSP trust chains are OK
        simple (1),
        strong (2) "

This attribute is single-valued and applies to all ACLs in the object
(including old-stype QUIPU ACLs).  To maintain backward compatibility,
if this attribute is absent the default shall be to require simple
authentication to validate names.

When applied to ordinary QUIPU ACLs, an authentication policy failure
causes no access to the entry to be granted.  When applied to a search
or list ACL, a failure causes the search or list to be abandoned with
a security error.

5  Access Selector


The Access Selector is taken from the QUIPU Access Controls.  It is
repeated here.  In a later version of the document, this information
will be integrated into an earlier section.



AccessSelector ::= CHOICE -
        entry [0] NULL,
                -- DUA identified by the entry
        other [2] NULL,
                -- This indicates 'public' rights
        prefix [3] NameList,
                -- This identifies a prefix name for specified DUAs
                -- e.g. anyone in the UK


Hardcastle-Kille and Howes                                      Page 5




INTERNET--DRAFT      Search and List Access Control     September 1991


        group [4] NameList
                -- For specifying group rights
        "

NameList ::= SET OF DistinguishedName



6  Security Considerations

This INTERNET--DRAFT / is concenred with controlling acces to data.


7  Author's Address

    Steve Hardcastle-Kille
    Department of Computer Science
    University College London
    Gower Street
    WC1E 6BT
    England

    Phone:  +44-71-380-7294


    EMail:  S.Kille@CS.UCL.AC.UK

    Tim Howes
    Research Systems
    University of Michigan
    535 West William St.
    Ann Arbor, MI 48103-4943


    Phone:  +1 313 764 2278


    EMail:  Tim.Howes@umich.edu







Hardcastle-Kille and Howes                                      Page 6