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

please publish - draft-ietf-ldapext-acl-model-08.txt



Internet Drafts Editor,
Please publish the attached draft:   draft-ietf-ldapext-acl-model-08.txt
Thanks.


ldapext working group:

Please find attached the next version of the ldap access control model.
The following is a summary list of the changes we made in this draft
based on mailing list comments, discussions, etc:
- list of what is out of scope for the model
- corrected and consistent ABNF and ASN.1
- authentication level is now a set of levels similar to what is in X.500; it is always
an explicitly required part of an ACI (see security considerations section)
- ipAddress and DNSName are retained as subjects (see security considerations
section)
- a few new permissions
u = unveil (disclose on error)
p = search filter (presence only)
g = get effective rights
- expanded section on access control decision making that discusses
applicability rules, precedences, inheritance, and the algorithm;
examples of applying the algorithm to make an access control decision
- added lots more examples in section 8 to cover interaction among ACI, use
of ipAddress in ACI, and use of authnLevel in ACI
- revision of getEffectiveRights control for simplicity
- expanded security considerations section
Please recall that the goal here from the last IETF meeting is to do a last call
on this draft before the August meeting. So please review so we can make a
last call happen real soon (remember that IF we need to do another revision
before the last call, the draft cutoff is July 20).
Please send comments to the list.
Thanks.
Ellen, Rob, and Rick






Internet-Draft                                                 E. Stokes
LDAP Extensions WG                                            B. Blakley
Intended Category: Standards Track                        Tivoli Systems
Expires: 29 December 2001                                       R. Byrne
                                                        Sun Microsystems
                                                                R. Huber
                                                       AT&T Laboratories
                                                            D. Rinkevich
                                                                 Momenta
                                                            29 June 2001

                    Access Control Model for LDAPv3
                 <draft-ietf-ldapext-acl-model-08.txt>

STATUS OF THIS MEMO

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. Internet-
Drafts are draft documents valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Comments and suggestions on this document are encouraged. Comments on
this document should be sent to the  LDAPEXT working group discussion
list:

          ietf-ldapext@netscape.com

COPYRIGHT NOTICE

Copyright (C) The Internet Society (2000).  All Rights Reserved.

ABSTRACT

This document describes the access control model for the Lightweight
Directory Application Protocol V3 (LDAPv3) directory service. It
includes a description of the model, the schema for the model, and the
LDAP control to the LDAP protocol.  The current LDAP APIs are sufficient
for the access control operations. A separate requirements document for
access control exists [REQTS].  The access control model used the



Stokes, et al            Expires 29 December 2001               [Page 1]




Internet-Draft            Access Control Model              29 June 2001



requirements document as a guideline for the development of this
specification and are reflected in this specification to the extent that
the working group could agree on an access control model.


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  and "MAY" used in this document
are to be interpreted as described in [Bradner97].



1.  Introduction

The ability to securely access (replicate and distribute) directory
information throughout the network is necessary for successful
deployment.  LDAP's acceptance as an access protocol for directory
information is driving the need to provide an access control model
definition for LDAP directory content among servers within an enterprise
and the Internet.  Currently LDAP does not define an access control
model, but one is needed to ensure consistent secure access,
replication, and management across heterogeneous LDAP implementations.
The major objective is to provide a simple, usable, and implementable,
but secure and efficient access control model for LDAP accessible
directory content while also providing the appropriate flexibility to
meet the needs of both the Internet and enterprise environments and
policies.  This document defines the model, the schema, and the LDAP
control.

This model does not (and cannot) fully specify the behavior of the
Access Control Model in a distributed environment (e.g. propagating
access control information across servers and ACI administration)
because there is no LDAP standard defining how to distribute directory
data between LDAP servers.  The behavior of the Access Control Model in
distributed environments is beyond the scope of this model.

The following topics are deemed interesting and useful for future work,
but are also beyond the scope of this model:

   - Permissions based on object class

   - Application permissions

   - How to get initial entryACI and subtreeACI attributes in the
     directory is server specific

   - Use of prescriptive ACIs and scoping via use of a ldapACISubEntry

   - Required permissions for LDAP extended operations and LDAP
     controls, such as a proxy permission and permission extensibility





Stokes, et al            Expires 29 December 2001               [Page 2]




Internet-Draft            Access Control Model              29 June 2001



   - The access rights required for the creation of the first entry in
     the directory

   - filter use in ACI

   - Mapping of SASL authentication identities (whose form is mechanism
     specific) to LDAP authorization identities (which are used for
     access control purposes)



2.  The LDAPv3 Access Control Model

Access Control mechanisms evaluate requests for access to protected
resources and make decisions about whether those requests should be
granted or denied.  In order to make a grant/deny decision about a
request for access to a protected resource, an access control mechanism
needs to evaluate policy data.  This policy data describes security-
relevant characteristics of the requesting subject and the rules which
govern the use of the target object.

No mechanism is defined in this document for storage of access control
information at the server beyond indicating that the attribute holding
access control information is an operational attribute.

The access control model defines

   - What flows on the wire for interoperability

     The existing LDAP protocol flows for ldap operations are used to
     manipulate access control information. These same flows on the wire
     apply when ACI is transmitted during replication.  A set of
     permissions and their semantics with respect to ldap operations is
     defined.  The permissions parallel the defined set of ldap
     operations.  Encoding of access control information on the wire is
     per the LDAPv3 specifications.

     There is a LDAP control defined, GetEffectiveRights.  LDAP clients
     use the control to manage and administer access control policy
     enforced by LDAP servers.

     Servers may store access control information in any way they
     choose. In particular, servers may use the access control
     mechanisms of their datastores to store and enforce LDAP access
     control, or they may implement/exploit access control managers
     external to their datastores.  Datastores and external access
     control managers MAY implement any access control rule syntax and
     semantics they choose, but the semantics MUST be compatible with
     those defined in the section titled "Required Permissions for Each
     LDAP Operation".




Stokes, et al            Expires 29 December 2001               [Page 3]




Internet-Draft            Access Control Model              29 June 2001



   - Attributes and classes for application portability of access
     control information.  Portable (LDAP) applications should only use
     the ACI in this model.

     Two access control information attributes (entryACI and subtreeACI)
     for application portability.  These attributes are used as input to
     the LDAP APIs so access control information can be addressed
     uniformly independent of how that information is accessed and
     stored at the server.  These same attributes appear in LDIF output
     for interchange of access control information.

     An access control information subentry class (ldapACISubEntry) and
     a set of attributes (supportedAccessControlSchemes which is used in
     the rootDSE, and accessControlSchemes which is used in the subentry
     ldapACISubEntry) to identity the access control mechanisms
     supported by a server and in a given part of the namespace,
     respectively.

   - A mechanism to control access to access control information:  The
     access control information operational attributes, entryACI and
     subtreeACI, are also used to control access to access control
     information (controls access to itself).  How to get initial
     entryACI and subtreeACI attributes in the directory is server
     specific and beyond the scope of this model.

Servers can support multiple access control mechanisms, but MUST be
capable of supporting the LDAP Mechanism in the DIT scoped by the
rootDSE (entire server's DIT) for that server and SHOULD be capable of
supporting the LDAP mechanism in an arbitrary part (subtree) of the DIT.

The accessControlSchemes attribute in the ldapACISubEntry indicates
which access control mechanisms are in effect for the scope of that
ldapACISubEntry.  The supportedAccessControlSchemes attribute in the
rootDSE indicates which access control mechanisms are supported by the
server; those mechanisms are in effect in that server's DIT unless
overridden by a mechanism defined in a ldapACISubEntry elsewhere in that
DIT.

Changing the value(s) of either the supportedAccessControlSchemes or
accessControlSchemes attributes changes the mechanism(s) in effect for
the scope of those attributes (where scope is either that of the rootDSE
or ldapACISubEntry).

Through the use of the supportedAccessControlSchemes attribute in the
rootDSE and the accessControlSchemes attribute in the ldapACISubEntry,
it is possible to run multiple mechanisms in either the same subtree or
separate subtrees.  This might occur if the underlying datastore for the
directory was accessible via LDAP and other applications.  In this case,
LDAP access should always be subjects to the LDAP access controls
described in this document.




Stokes, et al            Expires 29 December 2001               [Page 4]




Internet-Draft            Access Control Model              29 June 2001



3.  Access Control Mechanism Attributes

Two attributes are defined to identify which access control mechanisms
are supported by a given server and by a given subtree:
supportedAccessControlSchemes and accessControlSchemes.  (We chose these
names based on the X.500 attribute, AccessControlScheme which is
single-valued and defined in X.501).


3.1  Root DSE Attribute for Access Control Mechanism

The server advertises which access control mechanisms it supports by
inclusion of the 'supportedAccessControlSchemes' attribute in the root
DSE.  This attribute is a list of OIDs, each of which identify an access
control mechanism supported by the server.  By default, these are also
the mechanisms in effect in subtrees beneath the root in that server
unless overridden by a ldapACISubEntry (see section "Subentry Class
Access Control Mechanism").

 (<OID to be assigned>
    NAME      'supportedAccessControlSchemes'
    DESC      list of access control mechanisms supported
                by this directory server
    EQUALITY  objectIdentifierMatch
    SYNTAX    OID
    USAGE     dSAOperation
 )

The access control mechanism defined is:
     LDAPv3     <OID to be assigned>

Other vendor access control mechanisms MAY be defined (by OID) and are
the responsibility of those vendors to provide the definition and OID.


3.2  Subentry Class Access Control Mechanism

A given naming context MUST provide information about which access
control mechanisms are in effect for that portion of the namespace.
This information is contained in a subentry (ldapACISubEntry class),
derived from [SUBENTRY].  ldapACISubEntry MAY be used to define the
scope of an access control mechanism.  The value(s) held in the rootDSE
attribute, supportedAccessControlSchemes, are the mechanisms in effect
in subtrees beneath the root in that server unless overridden in a
ldapACISubEntry further down the tree held by that server.  The scope of
that ldapACISubEntry is to the end of the subtree held by that server or
until another ldapACISubEntry is encountered in that subtree held by
that server.  The ldapACISubEntry class is defined as:


 ( <OID to be assigned>



Stokes, et al            Expires 29 December 2001               [Page 5]




Internet-Draft            Access Control Model              29 June 2001



     NAME   'ldapACISubEntry'
     DESC   'LDAP ACI Subentry class'
     SUP    ldapSubEntry STRUCTURAL
     MUST   ( accessControlSchemes )
 )

The accessControlSchemes attribute MUST be in each ldapACISubEntry entry
associated with a naming context whose access control mechanism is
different from adjacent naming contexts supported by that directory
server.  accessControlSchemes lists the values (list of OIDs) that
define the access control mechanisms in effect for the scope of that
ldap access control subentry (either until another ldapACISubEntry is
encountered in that subtree or end of subtree is reached on the server).
Although, in general, this attribute will define only a single mechanism
(single value), more than one mechanism MAY be in effect for the scope
of that subentry.

 (<OID to be assigned>
    NAME      'accessControlSchemes'
    DESC      list of access control mechanisms supported
                in this subtree
    EQUALITY  objectIdentifierMatch
    SYNTAX    OID
    USAGE     dSAOperation
 )



4.  The Access Control Information Attributes, Syntax, and Rules

The access control information syntax and attributes, entryACI and
subtreeACI, are defined as:

 (<OID-aci-syntax>
   DESC 'attribute syntax for LDAP access control information'
 )

 (<OID to be assigned>
   NAME      'entryACI'
   DESC      'ldap access control information, scope of entry'
   EQUALITY  directoryComponentsMatch
   SYNTAX    <OID-aci-syntax>
   USAGE     directoryOperation
 )

 (<OID to be assigned>
   NAME      'subtreeACI'
   DESC      'ldap access control information, scope of subtree'
   EQUALITY  directoryComponentsMatch
   SYNTAX    <OID-aci-syntax>
   USAGE     directoryOperation



Stokes, et al            Expires 29 December 2001               [Page 6]




Internet-Draft            Access Control Model              29 June 2001



 )


Section 4.1 defines the ABNF and ASN.1 for these attributes, entryACI
and subtreeACI.

The intent of the attribute definitions is to define a common
interchange format and have a separation of responsibilities to allow
different people to administer the different attribute types. (X.500
overcomes this by allowing access control on a per-value basis, which is
complex). Any given LDAP server should be able to translate the defined
attribute into meaningful requests. Each server should be able to
understand the attribute; there should not be any ambiguity into what
any part of the syntax means.

While the end goal is to have a common behavior model between different
LDAP server implementations, the attribute definitions alone will not
ensure identical ACL processing behavior between servers.  Applicability
and precedence rules for making access decisions are defined later in
this section.  The semantics of how a server interprets the ACI syntax
are defined in the "Required Permissions for Each LDAP Operation"
section of this document.  Additionally, while the server must recognize
and act on the attribute when received over the wire, there are no
requirements for the server to physically store these attributes in this
form.

The attribute definitions maintain an assumption that the receiving
server supports ACI inheritance within the security model. If the server
does not support inheritance, the receiving server must expand any
inherited information based on the scope flag.

The attributes are defined so access control information (ACI) can be
addressed in a server in an implementation independent manner.  These
attributes are used in typical LDAP APIs, in LDIF output of ACI and in
transfer of ACI during replication. These attributes may be queried or
set on all directory objects.  The ABNF and definitions are given below.


4.1  The ABNF and ASN.1


4.1.1  ACI UTF-8 String Representation

The LDAP string encoding of values of the ACI syntax (<OID-aci-syntax>)
is described by the following ABNF [ABNF].  This string representation
MUST be supported.


 ACI = rights "#" attr "#" generalSubject

 rights = (("grant:" / "deny:") permissions) /



Stokes, et al            Expires 29 December 2001               [Page 7]




Internet-Draft            Access Control Model              29 June 2001



          ("grant:" permissions ";deny:" permissions)

 permissions = 1*(permission)

 permission = "a" / ; add
              "d" / ; delete
              "e" / ; export
              "i" / ; import
              "n" / ; renameDN
              "b" / ; browseDN
              "v" / ; view (entry level read permission)
              "t" / ; returnDN
              "r" / ; read
              "s" / ; search filter
              "p" / ; search filter (presence only)
              "w" / ; write (mod-add)
              "o" / ; obliterate (mod-del)
              "c" / ; compare
              "m" / ; make
              "u" / ; unveil (disclose on error permission)
              "g"   ; getEffectiveRights

 ; permissions r, w, o, s, p, c, m work on attributes
 ; permissions a, d, e, i, n, b, v, t, u, g work on entries
 ; permissions for attributes and permissions for entries are
 ;    never found in a single ACI

 attr = "[all]" / "[entry]" / (attribute *("," attribute))

 attribute = AttributeDescription
               ; The <AttributeDescription> rule is defined
               ; in Section 4.1.5 of [LDAPv3]

 generalSubject = context pureSubject

 context = "authnLevel:" authnLevel ":"

 pureSubject = anySubject / machineSubject / idBasedSubject

 anySubject =   "public:"

 machineSubject = "ipAddress:" ipAddressRange *( "," ipAddressRange ) /
                   "dns:" partialdomainname *( "," partialdomainname )

 partialdomainname = [ "*." ] domainname


 idBasedSubject = thisSubject /
                  oneSubject /
                  setOfSubjects




Stokes, et al            Expires 29 December 2001               [Page 8]




Internet-Draft            Access Control Model              29 June 2001



 thisSubject = "this:"
 oneSubject = ( "authzId-" authzId )
 setOfSubjects = ( "role:" dn ) /
                 ( "group:" dn ) /
                 ( "subtree:" dn )

 authnLevel = "none" /
              "weak" /
              "limited" /
              "strong"

 ; The <authzId> rule is defined in [AuthMeth].  It is
 ; repeated below for convenience.

 authzId = dnAuthzId / uAuthzId

 ; distinguished-name-based authz id.
 dnAuthzId  = "dn:" dn

 dn = utf8string ; with syntax defined in [UTF]

 ; unspecified userid, UTF-8 encoded.
 uAuthzId   = "u:" userid
 userid     = utf8string ; syntax unspecified
 ; A utf8string is defined to be the UTF-8 encoding of
 ; one or more ISO 10646 characters.

 ipAddress = IPv6address

 ; following is excerpted from [IPV6]
 IPv6address = hexpart [ ":" IPv4address ]
 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

 hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
 hexseq  = hex4 *( ":" hex4)
 hex4    = 1*4HEXDIG

 ipAddressRange = ipAddress [ HYPHEN ipAddress ]  ; IPv6 address range

 domainname = domaincomponent *( "." domaincomponent )

 OUTER = ALPHA / DIGIT
 INNER = ALPHA / DIGIT / HYPHEN
 HYPHEN = %x2D
 domaincomponent = OUTER [ *61( INNER ) OUTER ]


Note that the colon following the "public" and "this" subject options
exist only to simplify string parsing.

If an ACI is attempted to be added with an authz that is not understood,



Stokes, et al            Expires 29 December 2001               [Page 9]




Internet-Draft            Access Control Model              29 June 2001



then the server MUST reject that entryACI or subEntryACI value.  This
clarifies the statement in [AuthMeth] that allows for authzId may be
expanded in the future.

See section titled 'ACI Examples' for examples of the string
representation.



4.1.2  ACI Binary Representation

The ASN.1 type ACI is used to represent this syntax when transferred in
binary form.  This binary form SHOULD be supported.


 LDAP-Access-Control-Model
 DEFINITIONS EXTENSIBILITY IMPLIED ::=
 BEGIN

 IMPORTS
    AttributeType, DistinguishedName, CONTEXT
        FROM InformationFramework; -- from [X501]

 ACI ::= SEQUENCE {
    rights      SEQUENCE {
        grant           Permissions OPTIONAL,
        deny        [1] Permissions OPTIONAL }
            (WITH COMPONENTS { ..., grant PRESENT } |
            WITH COMPONENTS { ..., deny PRESENT }),
            -- at least one of grant or deny must be present --
    attr        CHOICE {
        all             NULL,
        entry       [1] NULL,
        attributes      SET (1..MAX) OF AttributeTypeAndOptions },
    authnLevel ::= ENUMERATED {
        none    (0),
        weak    (1),
        limited (2),
        strong  (3)}
    subject     GeneralSubject
 }

 -- An X.500 representation for an LDAP Attribute Description --
 AttributeTypeAndOptions ::= SEQUENCE {
    type        AttributeType,
    type-name   UTF8String OPTIONAL,
        -- A hint of what LDAP textual name to use when encoding an
        -- AttributeTypeAndOptions as an <AttributeDescription>.
    options     SEQUENCE SIZE (1..MAX) OF CONTEXT.&Assertion OPTIONAL
        -- A future revision will constrain CONTEXT.&Assertion to be
        -- the context assertion syntax of the CONTEXT information



Stokes, et al            Expires 29 December 2001              [Page 10]




Internet-Draft            Access Control Model              29 June 2001



        -- object defined by the X.500 working group to represent
        -- LDAP attribute options in the X.500 protocols.
        -- This is likely to be the UTF8String type.
 }

 GeneralSubject ::= CHOICE {
    anySubject          NULL,
    machineSubject  [1] MachineSubject,
    idBasedSubject      [2] IDBasedSubject
    -- may be expanded per [AuthMeth] --
 }

 MachineSubject ::= CHOICE {
    ipAddress       IPAddress,
    dns         [1] DomainName
 }

 IPAddress ::= UTF8String

 -- The character contents of an IPAddress string are encoded
 -- according to the <ipAddress> rule in Section 4.1.1.


 DomainName ::= UTF8String

 -- The character contents of a DomainName string are encoded
 -- according to the <partialdomainname> rule in Section 4.1.1.

 IDBasedSubject ::= CHOICE {
    thisSubject         NULL,
    oneSubject      [1] OneSubject,
    setOfSubjects   [2] SetOfSubjects
 }

 OneSubject ::= CHOICE {
    dn      DistinguishedName,
    user    UTF8String
 }

 SetOfSubjects ::= CHOICE {
    role        DistinguishedName,
    group   [1] DistinguishedName,
    subtree [2] DistinguishedName
 }


 Permissions ::= BIT STRING {
    add                 (0),
    delete              (1),
    export              (2),
    import              (3),



Stokes, et al            Expires 29 December 2001              [Page 11]




Internet-Draft            Access Control Model              29 June 2001



    renameDN            (4),
    browseDN            (5),
    viewEntry           (6),
    returnDN            (7),
    read                (8),
    search              (9),
    searchPresence      (10),
    write               (11),
    obliterate          (12),
    compare             (13),
    make                (14),
    unveil              (15),
    getEffectiveRights  (16)
    (CONSTRAINED BY { -- at least one bit must be set -- })
 }

 -- permissions read, write, obliterate, search,
 --   searchPresence, compare, make work on attributes
 -- permissions add, delete, export, import, renameDN,
 --   browseDN, viewEntry, returnDN, unveil,
 --   getEffectiveRights work on entries

 END



4.2  The Components of entryACI and subtreeACI Attributes

This section defines components that comprise the access control
information attributes, entryACI and subtreeACI.

The access control information in the entryACI attribute applies only to
the entry in which it is contained.

The access control information in the subtreeACI attribute applies to
each entry down the subtree unless it is overridden by an entry-specific
entryACI whose values are more specific or another subtreeACI lower in
the tree.

Use of prescriptive ACIs and scoping via use of a ldapACISubEntry is
outside the scope of this document.


4.2.1  Access Rights and Permissions

Access rights can apply to an entire object or to attributes of the
object. Access can be granted or denied.  Either or both of the actions
"grant" | "deny"  may be used when creating or updating entryACI and
subtreeACI.

Each of the LDAP access permissions are discrete. One permission does



Stokes, et al            Expires 29 December 2001              [Page 12]




Internet-Draft            Access Control Model              29 June 2001



not imply another permission.  The permissions which apply to attributes
and the entry parallel the type of ldap operations that can be
performed.

Permissions which apply to attributes:

   r   Read            Read attribute values
   w   Write           Modify-add values
   o   Obliterate      Modify-delete values
   s   Search          Search entries with specified
                          attributes
   p   searchPresence  Presence only filters
   c   Compare         Compare attributes
   m   Make            Make attributes on a new entry below
                          this entry


  1.  r  Read

      If granted, permits attributes and values to be returned in a read
      or search operation.

  2.  w  Write

      If granted, permits attributes and values to be added in a
      modify-add operation.

  3.  o  Obliterate

      If granted, permits attributes and values to be deleted in a
      modify-delete operation.

  4.  s  Search

      If granted, permits attributes and values to be included in the
      search filter of a search operation.

  5.  c  Compare

      If granted, permits attributes and value to be used in a compare
      operation.

  6.  p  SearchPresence

      If granted permits attributes and values to be included in
      presence tests in a search filter.

  7.  m  Make

      The attribute permission "m" is required for all attributes that
      are placed on an object when it is created. Just as the "w" and



Stokes, et al            Expires 29 December 2001              [Page 13]




Internet-Draft            Access Control Model              29 June 2001



      "o" permissions are used in the Modify operation, the "m"
      permission is used in the Add operation. Additionally, note that
      "w" and "o" have no bearing on the Add operation and "m" has no
      bearing on the Modify operation.  Since a new object does not yet
      exist, the "a" and "m" permissions needed to create it must be
      granted on the new object's parent. This differs from "w" and "o"
      which must be granted on the object being modified. The "m"
      permission is distinct and separate from the "w" and "o"
      permissions so that there is no conflict between the permissions
      needed to add new children to an entry and the permissions needed
      to modify existing children of the same entry.

Note:  Modify-replace values of an attribute require both "w" and "o"
permission.

Permissions that apply to an entire entry:

   a    Add        Add an entry below this entry
   d    Delete     Delete this entry
   e    Export     Export entry & subordinates to new
                      location
   i    Import     Import entry & subordinates below this
                      entry from some location
   n    RenameDN   Rename an entry's DN
   b    BrowseDN   Browse an entry's DN
   v    ViewEntry  A read level entry permission
   t    ReturnDN   Allows DN of entry to be disclosed in
                      an operation result
   u    Unveil     This is the discloseOnError permission
   g    GetEffectiveRights  This is get effective rights
                                permission


  1.  a  Add

      If granted, permits creation of an entry in the DIT subject to
      access control on all attributes and values to be placed in the
      new entry at time of creation.  In order to add an entry,
      permission must also be granted to add all attributes that exist
      in the add operation.

  2.  d  Delete

      If granted, permits the entry to be removed from the DIT
      regardless of controls on attributes within the entry.  Delete
      only works on leaf entries (same as X.500).

  3.  e  Export

      If granted, permits an entry and its subordinates (if any) to be
      exported; that is, removed from the current location and placed in



Stokes, et al            Expires 29 December 2001              [Page 14]




Internet-Draft            Access Control Model              29 June 2001



      a new location subject to the granting of suitable permission at
      the destination.  If the last RDN is changed, Rename is also
      required at the current location. In order to export an entry or
      its subordinates, there are no prerequisite permissions to
      contained attributes, including the RDN attributes; this is true
      even when the operation causes new attribute values to be added or
      removed as the result of the changes of RDN.

  4.  i  Import

      If granted, permits an entry and its subordinates (if any) to be
      imported; that is, removed from some other location and placed
      below the location to which the permission applies subject to the
      granting of suitable permissions at and below the source location.
      In order to import an entry or its subordinates, there are no
      prerequisite permissions to contained attributes, including the
      RDN attributes; this is true even when the operation causes new
      attribute values to be added or removed as the result of the
      changes of RDN.

  5.  n  RenameDN

      Granting Rename is necessary for an entry to be renamed with a new
      RDN.  There are many cases here surrounding the use of this
      permission.  See the section on 'Modify DN Operation'.

  6.  b  BrowseDN

      If granted, permits entries to be accessed using directory
      operations which do not explicitly provide the name of the entry.

  7.  v  ViewEntry

      If granted, permits entries to be accessed.  This entry level read
      permission is useful as it is not dependent on the scope or
      aliasing properties of the entry.

  8.  t  ReturnDN

      If granted, allows the distinguished name of the entry to be
      disclosed in the operation result.

  9.  u  Unveil

      If granted, allows the presence of the entry to be disclosed in
      the case where access is denied to the entry according to the
      access control rules.

 10.  g  getEffectiveRights

      If granted, allows the effective rights on that entry and the



Stokes, et al            Expires 29 December 2001              [Page 15]




Internet-Draft            Access Control Model              29 June 2001



      attributes within that entry to be returned, for _any_ subject.


4.2.2  Attributes

Attribute describes an attribute name in the form of a dotted decimal
OID for that <attr>. If the string (OID) refers to an attribute not
defined in the given server's schema, the server SHOULD report an error.
The use of "[entry]" or "[all]" helps to focus the permissions to either
entry or attribute quickly, and hence helps in parsing.

"[entry]" means the permissions apply to the entire object. This could
mean actions such as delete the object, or add a child object.  When
used in subtreeACI, the specified permissions (on the entry set of
permissions are legal here - see the ABNF) apply to each entry in the
subtree.

"[all]" means the permission set applies to all attributes of the entry.
When used in subtreeACI, "[all]" applies to all attributes of each entry
in the subtree.

If the keyword "[all]" and another attribute are both specified within
an ACI, the more specific permission set for the attribute overrides the
less specific permission set for "[all]".


4.2.3  Subjects and Associated Authentication

The following subjects are defined and MUST be supported:

   - authzId, defined per [AuthMeth]

   - group, defined as the distinguished name of a groupOfNames or
     groupOfUniqueNames entry

   - role, asserts a subject's organizational position and entitlement
     to perform the operations appropriate to that organizational
     position.  It is implementation defined how the association between
     authorization id and the role dn is made.

   - subtree, defined as some distinguished name of a non-leaf node in
     the DIT

   - ipAddress, in IPv6 text format [IPV6]

   - dnsName, a domain name or a wildcarded (left-most name or most
     specific part) domain name (see ABNF)

   - public, defined as public access





Stokes, et al            Expires 29 December 2001              [Page 16]




Internet-Draft            Access Control Model              29 June 2001



   - this, defined as the user whose name matches that of the entry
     being accessed

Other parties MAY define other subjects.  It is the responsibility of
those parties to provide the definition.  Adding new subjects may
inhibit interoperability.

A subject may be qualified by the level of authentication required for
access to a given attribute(s) or entry. authnLevel defines the minimum
requestor authentication level required for a given ACI.  For a
requestor's authentication level to exceed a minimum requirement, the
requestor's level must meet or exceed that specified in the ACI.

The authentication levels defined, in increasing order of
authentication, are:

   - none - no name and no password, or name but no password

   - weak - authentication mechanisms that are prone to both passive and
     active attacks [ATTACK]; for example, simple authentication (name
     and password)

   - limited - authentication mechanisms that protect against passive
     attacks but may be prone to active attacks; for example, DIGEST-MD5

   - strong - authentication mechanisms that protect against both
     passive and active attacks; for example, Kerberos with per-
     authentication or PKI authentication

The authnLevel applies to a subject as follows:

   - If the ACI is a grant, then the authnLevel applies if the subject
     is authenticated at or above that level.

   - If the ACI is a deny, then the authnLevel applies to that subject
     if authenticated at that level AND to all other subjects
     authenticated with levels below that.

Authentication level is always specified in an ACI.  For grant, this
means that you are granted access if you can prove your authentication
via a strong authentication mechanism, such as a digital signature.  For
deny, the meaning of this is "you are denied access if you are Mr. X and
you can prove it with a digital signature".  If you are not Mr. X you
are not denied access only if you can prove it (authenticate yourself)
with a digital signature. In other words, everyone who does not
authenticate with a digital signature is denied access.  Everyone who
authenticates with a digital signature is allowed access except Mr. X.

A recommended categorization of authentication mechanisms per
authentication level may be offered separately.  For each mechanism
categorized in the recommendations, implementations SHOULD NOT assign a



Stokes, et al            Expires 29 December 2001              [Page 17]




Internet-Draft            Access Control Model              29 June 2001



higher authentication level, but MAY assign a lower authentication
level.  For mechanisms not covered by the recommendation, the
implementation SHOULD specify a conservative level.  Implementations
SHOULD provide a means for the directory administrator to disable and/or
lower the authentication level associated with a mechanism.

Two interesting subjects not explicitly included, but can be composed
using subject and authnLevel are anonymous and authenticated.

   - anonymous:  authnLevel=none + anySubject(public)

   - authenticated:  authnLevel=weak + anySubject(public)


4.3  Access Control Decision Making

The ultimate goal of the Access Control Model is to define the way in
which an LDAP server determines an access control decision for a given
requested LDAP operation.  In fact, a requestor may require several
individual permissions in order to be authorized to carry out an LDAP
operation and we define these in section 5.  In this section we
introduce the concepts and algorithm that allow the server to decide if
a requestor has an individual permission on an individual resource.  The
concepts we require are firstly, the parameters which must be provided
in order for the Access Control Decision Algorithm to determine whether
the access is allowed or not.  Secondly, we define precisely when a
given ACI value will be involved in a given access control decision.
Thirdly, this model defines some precedence rules which the Algorithm
will use when dealing with more than one ACI value.  Finally, we can
define the Access Control Decision Algorithm which will determine the
access decision.  Throughout, we use the ABNF, when we need to refer to
portions of individual ACI values.

4.3.1  The Parameters to the Access Decision Algorithm

The decision algorithm answers the question "Does the specified
requestor have the specified permission on the specified resource?"  The
resource may be an entry (as for the Delete operation) or it may be an
attribute within an entry (as for the Modify operation) so we
characterize the resource like this: (targetEntry, targetAttribute
OPTIONAL).

The requestor is identified primarily by his authorization ID (which may
be omitted if the requestor has bound anonymously), but also includes
other context information about the requestor so it is represented like
this: (authzId OPTIONAL, ipAddress, dnsName, authnLevel).

The permission is one of the valid permissions defined by the model.

So, the parameters to the Access Control Decision Algorithm, which we
will refer to collectively as "the decision parameters" are:



Stokes, et al            Expires 29 December 2001              [Page 18]




Internet-Draft            Access Control Model              29 June 2001



   - resource: (targetEntry, targetAttribute OPTIONAL)

   - permission: permissionParameter

   - requestorSubject: (authzId OPTIONAL, ipAddress, dnsName,
     authnLevel)

If permissionParameter is an attribute-level parameter then
targetAttribute must be specified; if it is an entry-level permission
then targetAttribute is ignored.

The output is either "Access Allowed" or "Access Denied".


4.3.2  Applicability Rules

The applicability rules define whether a given ACI value, or portions of
it, apply to some given decision parameters.


4.3.2.1  Applicability Rules for Scope Types

These rules determine whether a specific ACI applies to the targetEntry
part of the decision parameters.

   - If the ACI in question is an entryACI, then ACI applies to the
     resource if the ACI is an attribute of the entry targetEntry.

   - If the ACI in question is a subtreeACI, then ACI applies to the
     resource if targetEntry is part of the subtree defined by the entry
     containing the ACI.


4.3.2.2  Applicability Rules for Permissions

If permissionParameter is an entry-level permission, then the ACI in
question applies if permissionParameter is mentioned in the permissions
list of the ACI.

If permissionParameter is an attribute-level permission, then the ACI in
question applies if permissionParameter is mentioned in the permissions
list and the ACI's attribute list applies to the target attribute per
"Applicability Rules for Attributes".

Note that for an ACI which contains both grant and deny permissions
lists, the grant permission list may not be available for the purposes
of this applicability rule--see point 3 in the "Applicability Rules for
Subjects".






Stokes, et al            Expires 29 December 2001              [Page 19]




Internet-Draft            Access Control Model              29 June 2001



4.3.2.3  Applicability Rules for Attributes

If an attribute is not specified as part of the resource, then this rule
does not apply.  If an attribute is specified, then the ACI in question
applies if its attribute list is [all] or if targetAttribute is
explicitly mentioned in the ACI's attribute list.

In the case where targetAttribute is an attribute type with options
(e.g. sn;lang-en;lang-uk), it is applicable if the ACI's attribute list
mentions a less specific form of targetAttribute.  For example, if the
list contained "sn;lang-en", then that list applies to the attribute
"sn;lang-en;lang-uk", but not the attribute "sn".

4.3.2.4  Applicability Rules for Subjects

Call the subject portion of the ACI in question aciSubject.  Then to
determine if aciSubject applies to requestorSubject we apply the
following rules:

  1.  The ACI in question is a grant ACI.  Then the ACI applies if both
      the context and pureSubject portions of aciSubject apply, as
      defined in "Applicability Rules for Context" and "Applicability
      Rules for pureSubject" below.

  2.  The ACI in question is a deny ACI.  There are three possibilities:

        a.  The pureSubject part applies (according to "Applicability
            Rules for pureSubject").  Then the ACI applies to
            requestorSubject.

        b.  The pureSubject part does not apply.  Then the ACI applies
            to any requestorSubject with an authnLevel less than the
            authnLevel of the ACI.

        c.  Otherwise the ACI does not apply.

  3.  The ACI in question is both a deny and grant ACI.  There are three
      possibilities:

        a.  aciSubject applies when evaluated as a grant ACI (per 1
            above).  Both the grant permissions and deny permissions of
            the ACI are available for the purpose of the "Applicability
            Rules for Attributes and Permissions".

        b.  aciSubject does not apply as a grant ACI but does apply as a
            deny ACI (per 2 above).  The deny permissions of the ACI are
            available for the purpose of the "Applicability Rules for
            Attributes" and the "Applicability Rules for Permissions".

        c.  aciSubject does not apply when evaluated as either a grant
            ACI or a deny ACI.  The ACI does not apply to



Stokes, et al            Expires 29 December 2001              [Page 20]




Internet-Draft            Access Control Model              29 June 2001



            requestorSubject.

Note: the deny behavior with authnLevel deserves explication.  In the
case where an ACI denies access to a given subject with a given
authnLevel, then naturally it will deny access to that given subject
authenticated at authnLevel or above.  Similarly, another user
authenticated at authnLevel or above, to which the pureSubject part does
not apply, will not be denied those rights by that ACI.

The interesting case is a user authenticated at a lower level than
authnLevel.  For such a user the ACM takes the view that as that user
has not proved to the system, to a sufficient degree of confidence, that
the pureSubject portion does not apply to him, then to be safe, he will
be denied those rights.

So if you deny access to a particular authzId with authnLevel of "none",
then that authzId will be denied access at any authentication level, but
it will not affect any other requestors.  On the other hand, if you deny
access to a particular authzId with an authnLevel of "strong", then that
will deny access to that user when authenticated strongly AND deny
access to ANY users authenticated with lower authentication levels.


4.3.2.5  Applicability Rules for pureSubject

If aciSubject is of type anySubject, then it applies to
requestorSubject.

If aciSubject is of type machineSubject, then if the ipAddress or dns
name from requestorSubject matches the ipAddress or dns name range in
aciSubject, then the ACI applies to requestorSubject if it is a deny ACI
or the deny part of a grant/deny ACI.  A grant ACI (or the grant part of
a grant/deny ACI) never applies if the subject is ipAddress: or dns:.
The note at the end of the "Precedence of Subjects within a Scope"
explains the reasoning behind this rule.

If the aciSubject is of type idBasedSubject, then it applies according
to the definition in "Applicability Rules for idBasedSubject".

4.3.2.6  Applicability Rules for Context

The context of aciSubject applies to requestorSubject if authnLevel from
requestorSubject is greater than or equal to the authnLevel specified in
the context part of aciSubject.


4.3.2.7  Applicability Rules for idBasedSubject

If idBasedSubject is of type thisSubject, then it applies to
requestorSubject if authzId from requestorSubject is of type "dn" and is
equal to the DN of the resource.



Stokes, et al            Expires 29 December 2001              [Page 21]




Internet-Draft            Access Control Model              29 June 2001



If idBasedSubject is of type oneSubject, then it applies to
requestorSubject if authzId from requestorSubject is equal to the
authzId specified in aciSubject.

If idBasedSubject is of type setOfSubjects, then it applies to
requestorSubject if authzId from requestorSubject is defined to be in
the set specified in aciSubject (i.e. is in that group, role or
subtree).  The "Precedence of Subjects within a Scope" includes rules
for determining membership in a setOfSubjects.


4.3.3  Precedence Rules

The precedence rules allow the Access Control Decision Algorithm to
determine which ACI values should take precedence over others.


4.3.3.1  Precedence of Scope Types


  1.  Entry

  2.  Subtree


4.3.3.2  Precedence of Position in the DIT

For a given subject DN (including authentication level) and target DN,
subtreeACI lower in the tree take precedence over those higher in the
tree.


4.3.3.3  Precedence of Subjects within a Scope


  1.  ipAddress or dns in a deny ACI or the deny part of a grant/deny
      ACI

  2.  authzId distinguished name ("authzId-dn:") or authzId userid
      ("authzId-u:")

  3.  this

  4.  role

      If the DN of a role or a group appears in a role (e.g. appears as
      a value of roleOccupant in an organizationalRole), it is
      recursively expanded.  For determination of precedence, the
      resulting expanded collection of names is considered to have come
      from a role regardless of the original source.




Stokes, et al            Expires 29 December 2001              [Page 22]




Internet-Draft            Access Control Model              29 June 2001



  5.  group

      If the DN of a role or a group appears in a group, it is
      recursively expanded. For determination of precedence, the
      resulting expanded collection of names is considered to have come
      from a group regardless of the original source.

  6.  subtree

      Subtrees may contain groups and/or roles.  They should be
      recursively expanded. For determination of precedence, members of
      groups or occupants of roles that apply because (after recursive
      expansion) the group or role is contained in a subtree are
      considered to have come from the subtree regardless of the
      original source.

  7.  public

The precedence of ipAddress and DNS names are treated specially, and
depend on the type of ACI involved.  Typical situations are:

   - If an ACL says to grant on the basis of IP address but deny on the
     basis of some other attribute (username, group, etc....), then the
     behavior we want is "deny".  Rationale: the user is prohibited from
     access, regardless of where he's sitting.

   - If an ACL says to deny on the basis of IP address but grant on the
     basis of some other attribute (username, group, etc....), then the
     behavior we want is also "deny".  Rationale: the user is allowed
     access, but not from where he's sitting.

In addition, a grant to an ipAddress with no other applicable ACI is
very dangerous from a security point of view, since it would grant
permissions to ANY user who has access to the machine with the given
address.  Thus ipAddress and dns subjects can be used only to deny
permission, not to grant them.  The "Applicability Rules for
pureSubject" enforce this.


4.3.3.4  Precedence of Attribute Specifications

Access controls specifying "[all]" attributes are of lower precedence
than specific lists.


4.3.3.5  Precedence of grant/deny

Deny takes precedence over grant.






Stokes, et al            Expires 29 December 2001              [Page 23]




Internet-Draft            Access Control Model              29 June 2001



4.3.3.6  Default

Deny is the default when there is no access control information or when
evaluation of the access control information yields no result that
allows the requester access.


4.3.4  Access Control Decision Algorithm

The Access Control Decision Algorithm takes as input the decision
parameters defined above and produces a grant or a deny decision.

In the case where we are interested in the permission set for a set of
entries and attributes (as in the case of evaluating the effective
rights in section 9), then we must apply the algorithm for each
entry/attribute and permission pair we are interested in.  Naturally
implementers are free to implement any algorithm which produces the same
decision given the same input and ACI values in a DIT.

The algorithm has two phases.  First, all the potentially applicable ACI
values are sorted into an ordered list of sets of ACI values of the same
precedence.  Then this list is scanned in order to find the set of ACIs
which will determine the access decision.

Phase 1: Order the potentially applicable ACI values

  1.  Determine all the entryACI and subtreeACI values that apply to
      targetEntry, according to  the "Applicability Rules for Scope
      Types".

  2.  Sort these ACIs into a list of sets of ACIs of equal precedence,
      according to the  "Precedence of Scope Types" and "Precedence of
      Position in the DIT" rules.

  3.  Determine which of the collected ACI values from step 1 apply to
      requestorSubject using the "Applicability Rules for Subjects".
      All the ACI values which do not apply to this subject are
      discarded.

  4.  The list of sets is sorted according to subject type from the
      "Precedence of Subjects within a Scope" rules.

  5.  Now we split the list into two separate lists keeping the same
      relative ordering of sets--one list has the sets that just contain
      ACI values that refer to entry-level permissions and the other has
      the sets that just contain ACI values that refer to attribute-
      level permissions.

  6.  Each set in the attribute-level list of sets is further divided
      into a list of sets of equal precedence according to "Precedence
      of Attributes Specification".



Stokes, et al            Expires 29 December 2001              [Page 24]




Internet-Draft            Access Control Model              29 June 2001



Note: At this point we have two lists of sets of ACI values, one dealing
with entry-level permissions the other dealing with attribute-level
permissions.  The lists have been sorted according to Scope, Position,
Subject and (for the attribute-level list) Attribute Specification
precedence rules.

Phase 2: Scan the lists to determine the access decision:

  1.  If permissionParameter is an entry-level permission (so that the
      optional targetAttribute field is not specified), then scan the
      list of entry-level sets in order.  The first set in the list that
      contains an ACI that applies to permissionParameter (as defined in
      the "Applicability Rules for Permissions" rules) determines the
      access decision--if an ACI in the set grants permissionParameter
      and no other denies it, then access is granted, otherwise access
      is denied.

  2.  If permissionParameter is an attribute-level permission then scan
      the list of attribute-level sets in order.  The first set in the
      list that contains an ACI that applies to permissionParameter AND
      applies to targetAttribute (as defined in the "Applicability Rules
      for Attributes" and "Applicability Rules for Permissions")
      determines the access decision--if an ACI in the set grants
      permissionParameter and no other denies it, then access is
      granted, otherwise access is denied.


4.3.5  Precedence/Inheritance Access Decision Example
The examples in this section refer to the following directory tree:

                             dc=com
                                 |
                        +--------+---------------+
                        |                        |
                    dc=tivoli                 dc=sun
                        |                        |
                    cn=ellen                  cn=rob

The ACI at dc=com:

 1. subtreeACI:grant:rsc#[all]#authnLevel:none:public:
 2. subtreeACI:deny:rsc#userPassword,subtreeACI,entryACI,salary#
                  authnLevel:none:public:
 3. subtreeACI:grant:bvt#[entry]#authnLevel:none:public:
 4. subtreeACI:grant:rscmow#[all]#authnLevel:strong:
                  authzID-dn:cn=rob,dc=sun,dc=com
 5. subtreeACI:grant:bvtugeinad#[entry]#authnLevel:strong:
                  authzID-dn:cn=rob,dc=sun,dc=com

The ACI at dc=tivoli,dc=com:




Stokes, et al            Expires 29 December 2001              [Page 25]




Internet-Draft            Access Control Model              29 June 2001



 6. subtreeACI:grant:rsc;deny:mow#[all]#authnLevel:strong:
                  authzID-dn:cn=rob,dc=sun,dc=com
 7. subtreeACI:deny:einad#[entry]#authnLevel:strong:
                  authzID-dn:cn=rob,dc=sun,dc=com

The ACI at cn=ellen,dc=tivoli,dc=com

 8. entryACI:grant:wo#[all]#authnLevel:strong:
                  authz-ID-dn:cn=ellen,dc=tivoli,dc=com
 9. entryACI: deny: wo#entryACI,subtreeACI,salary#authnLevel:strong:
                  authz-ID-dn:cn=ellen,dc=tivoli,dc=com

Example #1

 subject:  ("cn=rob,dc=sun,dc=com", ipaddress, dns name, strong):
 resource: ("cn=ellen,dc=tivoli,dc=com", salary)
 permission: "w"

Phase 1:  Find all applicable ACI based on the Applicability of Scope
          Types.

                      {1, 2, 3, 4, 5, 6, 7, 8, 9}

          Sort by Precedence of Scope Type and Precedence of Position in
          DIT:

                    {8, 9}, {6, 7}, {1, 2, 3, 4, 5}

          Determine which ACI are applicable based on the Subject:

                        {6, 7}, {1, 2, 3, 4, 5}

          Sort by Precedence of Subjects within Scope:

                       {6, 7}, {4, 5}, {1, 2, 3}

          Separate permissions applicable to entry and those applicable
          to attributes:

                        Entry: {7}, {5}, {3}
                        Attr:  {6}, {4}, {1, 2}

          Sort the permissions applicable to attributes by precedence of
          attribute specification:

                       Entry: {7}, {5}, {3}
                       Attr:  {6}, {4}, {2}, {1}

Phase 2:  Since "w" is an attribute permission, look at the Attr list.
          ACI 6 in the first sub-list mentions "w" and salary (via
          [all]) so this set defines the access--which is deny.



Stokes, et al            Expires 29 December 2001              [Page 26]




Internet-Draft            Access Control Model              29 June 2001



Example #2

 subject:  ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
 resource: ("cn=ellen,dc=tivoli,dc=com", salary)
 permission: "w"

Phase 1:  First the ACIs are ordered into the following sets whose
          subject matches the subject tuple:

                          Entry: {7}, {3}
                          Attr:  {6}, {2}, {1}

Phase 2:  For ACI 6 in the first set, which matched the subject because
          of the deny portion and limited < strong, the permissions
          available are "mow".  So, this ACI applies to "w" and salary
          (via [all]) and the access is "deny".

Example #3

 subject:  ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
 resource: ("cn=ellen,dc=tivoli,dc=com", salary)
 permission: "r"

Phase 1:  First the ACIs are ordered into the following sets whose
          subject matches the subject tuple:

                          Entry: {7}, {3}
                          Attr:  {6}, {2}, {1}

Phase 2:  As the grant portion of ACI 6 is not active, the first set
          that contains an ACI that applies to "r" and salary is {2}.
          As 2 denies access, access is denied.

Example #4

 subject:  ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
 resource: ("cn=ellen,dc=tivoli,dc=com", cn)
 permission: "r"

Phase 1:  First the ACIs are ordered into the following sets whose
          subject matches the subject tuple:

                          Entry: {7}, {3}
                          Attr:  {6}, {2}, {1}

Phase 2:  As the grant portion of ACI 6 is not active, the first set
          that contains an ACI that applies to "r" and cn is {1}.  As 1
          grants access, access is granted.






Stokes, et al            Expires 29 December 2001              [Page 27]




Internet-Draft            Access Control Model              29 June 2001



5.  Required Permissions for each LDAP Operation

This section defines the required permissions for each LDAP operation.
Even if these requirements are satisfied, the server may refuse to carry
out the operation due to other implementation specific security
considerations. For example, a server may refuse to modify an entry
because the database where that entry resides is in read only mode.
Another example might be that although LDAP access control has been
specified on the userPassword attribute a server may refuse
modifications due to some server specific policy governing access to
passwords.

Here, we specify the rights required by a user when performing an LDAP
operation in terms of the LDAP permissions specified above.  Recall that
"a, d, e, i, n, b, v, t, u" are permissions that apply to entries as a
whole while permissions "r, s, p, w, o, c, m, g" apply to attributes
within entries.

Required permissions for LDAP extended operations and LDAP controls
SHOULD be defined along with their specifications.  These requirements
could be expressed in terms of this model, for example by requiring one
of the existing permissions on some particular entry or attribute.  This
version of the LDAP access control model does not offer any mechanism to
extend the permission set or aci syntax to accommodate extended
operations or controls.

For the following, assume that the authorization identity of the user
doing the operation is authzId.


5.1  Bind Operation

This model does not require any permissions to allow a bind operation to
proceed.


5.2  Search Operation

Recall that the parameters of the Search operation per RFC 2251 [LDAPv3]
Section 4.5 are:

   SearchRequest ::= [APPLICATION 3] SEQUENCE {
        baseObject      LDAPDN,
        scope           ENUMERATED {
                baseObject              (0),
                singleLevel             (1),
                wholeSubtree            (2) },
        derefAliases    ENUMERATED {
                neverDerefAliases       (0),
                derefInSearching        (1),
                derefFindingBaseObj     (2),



Stokes, et al            Expires 29 December 2001              [Page 28]




Internet-Draft            Access Control Model              29 June 2001



                derefAlways             (3) },
        sizeLimit       INTEGER (0 .. maxInt),
        timeLimit       INTEGER (0 .. maxInt),
        typesOnly       BOOLEAN,
        filter          Filter,
        attributes      AttributeDescriptionList }

Suppose a server is processing a search request from user authzId with
parameters as above and is processing the entry with dn candidateDN to
decide if it may be returned or not.

Then the permissions required by authzId that need to be evaluated are
as follows:


  1.  permission "b" to the entry candidateDN if the entry is in the
      scope of the search but is not the base entry.

      If this permission is not granted then the dn candidateDN MUST NOT
      be returned nor any attribute type nor attribute value from this
      entry.

      Note: the "b" permission is included to allow different browsing
      or discovery rights to be assigned to different classes of users.

  2.  permission "v" to the entry candidateDN

      If this permission is not granted then the dn candidateDN MUST NOT
      be returned nor any attribute type nor attribute value from this
      entry.

      Note A: The "v" permission is the entry level read permission.
      This is included as it is useful to have one simple permission
      (not dependent on scope or aliasing) that protects all the
      components of an entry; the dn and the attributes.

      Note B: Disclosing the full distinguished name of an entry will
      inevitiably reveal the names of its ancestors.  This issue is
      discussed in detail below.

  3.  permission "p" or "s" to each attribute appearing in a search
      filter presence test during the evaluation of the search filter.
      permission "s" is required on attributes appearing in non-presence
      tests (see RFC2254, section 3: equalityMatch, substrings,
      greaterOrEqual, lessOrEqual, present, approxMatch,
      extensibleMatch) during the evaluation of the search filter.

      The above statement covers the case where the attributes are being
      evaluated as part of an extensibleMatch (RFC 2251 section 4.5.1)
      which appears in the filter.  In the case where the dnAttributes
      field of the extensibleMatch is true (and so the filter test is



Stokes, et al            Expires 29 December 2001              [Page 29]




Internet-Draft            Access Control Model              29 June 2001



      applied to the naming attributes in the dn of the entry) then we
      do not require any access checks to the attributes of the dn as
      access to these is taken to be granted by the "v" permission,
      which has already been required above.

      If there is an attribute in a filter element to which the required
      permission is not granted then that filter element evaluates to
      "Undefined" of the three-valued-logic of X.511(93).

      Note:  The motivation for the "p" permission is that if you have
      full filter rights on an attribute then in some cases that could
      be operationally the same as having read permission i.e. you could
      quickly determine the attribute value, and this may not be
      desirable.  For example, if the type of the attribute was integer
      then with full filter permissions you could quickly determine the
      value by doing a sequence of binary chop style searches using ">"
      and "<".  Whereas, with just the presence test ability, you would
      not have right to do those kind of searches, but you would be able
      to test for the presence of the attribute.

  4.  permission "r" to each attribute in the attribute list
      AttributeDescriptionList (or all attributes in the entry
      candidateDN if AttributeDescriptionList is *) whose type and/or
      value will be returned.

      Note A: The presence of an attribute in an entry is only ever
      volunteered by the server if "r" permission is granted to it,
      though a user may infer the presence of an attribute with "s" or
      "p" permission by using a presence test on that attribute in the
      search filter.

      Note B: Although both "r" and "s" permissions will typically be
      granted to attributes we keep both permissions as there are cases
      where the distinction is useful.  A reverse telephone lookup is an
      example of granting "r" but not "s" permission.

  5.  permission "t" to the entry candidateDN

      If this permission is not granted then the dn candidateDN MUST NOT
      be returned. If the server knows of an alias for the entry, this
      alias may be returned instead.  If no alias name is available then
      the entry candidateDN MUST be omitted from the search results.

      Note:  Disclosing the full distinguished name of an entry will
      inevitiably reveal the names of its ancestors.  This issue is
      discussed in detail below.

  6.  Disclose on error for the Search operation

      If there is no entry in the scope of the search which satisfies
      item 1 (browse right on the candidate entry) and item 2 (read



Stokes, et al            Expires 29 December 2001              [Page 30]




Internet-Draft            Access Control Model              29 June 2001



      level permission on the entry) and item 3 (right to use the filter
      on that entry) then the "u" permission on the base entry must be
      evaluated.  If "u" (disclose on error) is not granted to the base
      entry then the operation MUST fail with a "no such object error"
      and the matchedDN of the LDAPResult MUST be set to "".  If "u" is
      granted to the baseObject then the empty set of results is
      returned.

      Note: the point here is that if you do not have the right to
      discover at least one entry in the scope of the search then the
      disclose on error mechanism is there to prevent you discovering
      the base entry of the search.  The "t" permission is not
      considered here as it is not conceptually a permission involved in
      the discovery of entries but rather in how they are returned (dn
      vs. alias).


5.2.1  Protecting the naming attributes of DNs

Protecting the naming attributes in an entry's dn presents a problem for
access control.  The issue is that if access is granted to the dn of a
given entry, then via the naming attributes this dn contains, access is
also also granted to attribute values in other entries.  In addition,
knowledge about the existence of ancestor entries of a given entry is
also disclosed by the entry's dn.

It could be argued that there should be consistency in the ability of a
given requestor to see attribute values in the dn of an entry and his
ability to see those attributes in the entry where they actually reside.
Similarly, it could be argued that there should be consistency in the
ability of a requestor to see an entry and his ability to see its
ancestor entries.

The main reason we do not require such cross checking of permissions is
because of the extra work it entails for the server. There is a trade
off between the consistency this cross checking guarantees and the work
it takes to do that cross checking.

For LDAP servers the trade off has been to go in favor of speed.  In
addition there are some other points which mitigate these kind of
inconsistencies.  Firstly, it appears to be difficult to produce a real
world example where they really cause a problem.  Secondly there are
other methods of hiding DNs (and hence protecting the naming attribute
and ancestor information they contain) which are outside the scope of
access control, for example aliasing and LDAP proxying.


5.3  Modify Operation

Recall that the parameters of the Modify operation per RFC2251 [LDAPv3]
Section 4.6 are:



Stokes, et al            Expires 29 December 2001              [Page 31]




Internet-Draft            Access Control Model              29 June 2001



   ModifyRequest ::= [APPLICATION 6] SEQUENCE {
        object          LDAPDN,
        modification    SEQUENCE OF SEQUENCE {
                operation  ENUMERATED {
                                   add     (0),
                                   delete  (1),
                                   replace (2) },
                modification    AttributeTypeAndValues } }

   AttributeTypeAndValues ::= SEQUENCE {
        type    AttributeDescription,
        vals    SET OF AttributeValue }

Then the permissions required by authzId that need to be evaluated are
as follows:


  1.  permission "w" to each attribute being added to object

      If this permission is not granted to such an attribute, then the
      operation MUST fail.

  2.  permission "o" to each attribute for which a value is being
      deleted from object

      If this permission is not granted to such an attribute, then the
      operation MUST fail.

  3.  permissions "o" and "w" to each attribute being replaced in object

      If each of these items is satisfied then the operation is allowed
      by the access control model.  If one of these items is not
      satisfied, then the operation MUST fail.  In this case, if "u"
      (discloseOnError) is granted to object, then the usual error codes
      (such as noSuchObject, attributeOrValueExists, noSuchAttribute and
      insufficientAccess) and matchedDN value may be returned; if "u" is
      not granted to object then nosuchObject MUST be returned and
      matchedDN set to "".


5.4  Add Operation

Recall that the parameters of the Add operation per RFC2251 [LDAPv3]
Section 4.7 are:

   AddRequest ::= [APPLICATION 8] SEQUENCE {
        entry           LDAPDN,
        attributes      AttributeList }

   AttributeList ::= SEQUENCE OF SEQUENCE {
        type    AttributeDescription,



Stokes, et al            Expires 29 December 2001              [Page 32]




Internet-Draft            Access Control Model              29 June 2001



        vals    SET OF AttributeValue }

Then the permissions required by authzId that need to be evaluated are
as follows:


  1.  permission "a" to the parent of entry

      The access rights required for the creation of a root entry in the
      Directory are beyond the scope of this document.  They will be
      vendor specific.

  2.  permission "m" to the parent of entry for each attribute being
      added to entry

If each of these items is satisfied then the operation is allowed by the
access control model.  If one of these items is not satisfied, then the
operation MUST fail.  In this case, if "u" (discloseOnError) is granted
to the parent of entry, then the usual error codes (such as
noSuchObject, entryAlreadyExists, and insufficientAccess) and matchedDN
value may be returned; if "u" is not granted to the parent of entry,
then nosuchObject MUST be returned and matchedDN set to "".

Note A: We require "m" permission to each attribute to prevent an entry
from acquiring "unintended" rights (via group or role membership),  to
stop a "rogue" ACI being added that would prevent even admins deleting
the entry, and for general consistency with the MODIFY operation.


5.5  Delete Operation

Recall that the parameters of the Delete operation per RFC2251 [LDAPv3]
Section 4.10 are:

    DelRequest ::= [APPLICATION 10] LDAPDN

Then the permissions required by authzId that need to be evaluated are
as follows:


  1.  permission "d" to the entry in the Delete request

If each of these items is satisfied then the operation is allowed by the
access control model.  If one of these items is not satisfied, then the
operation MUST fail.  In this case, if "u" (discloseOnError) is granted
to the entry to be deleted, then the usual error codes (such as
noSuchObject, and insufficientAccess) and matchedDN value may be
returned; if "u" is not granted to object then nosuchObject MUST be
returned and matchedDN set to "".

Note: One could also require the "o" permission to be granted to allow



Stokes, et al            Expires 29 December 2001              [Page 33]




Internet-Draft            Access Control Model              29 June 2001



the operation to proceed, but customer experience has shown that the
requirement of the additional permission is not useful nor expected, and
X.500 requires only the "d" permission.


5.6  Modify DN Operation

Recall that the parameters of the Modify DN operation per RFC2251
[LDAPv3] Section 4.6 are:

   ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
        entry           LDAPDN,
        newrdn          RelativeLDAPDN,
        deleteoldrdn    BOOLEAN,
        newSuperior     [0] LDAPDN OPTIONAL }

The variants of the ModifyDN operation are listed below.  Combinations
of the write, obliterate, import, export and renameDN permissions are
needed for each variant.

  1.  Rename an entry by moving the conceptual RDN flag between two
      existing attribute values, without altering any attribute values
      at all.  Permissions needed are renameDN.

  2.  Rename an entry by adding a new attribute value.  Permissions
      needed are renameDN and write.

  3.  Rename an entry using an existing attribute value and delete the
      current attribute value.  Permissions needed are renameDN and
      obliterate.

  4.  Rename an entry adding a new attribute value and deleting the
      current attribute value.  Permissions needed are renameDN, write,
      and obliterate.

  5.  Move an entry to a new place in the DIT, keeping its existing RDN
      as is.  Permissions needed are import and export.

  6.  Move an entry to a new place coupled with 1. above Permissions
      needed are import, export, and renameDN.

  7.  Move coupled with 2. above.  Permissions needed are import,
      export, renameDN, and write.

  8.  Move coupled with 3. above.  Permissions needed are import,
      export, renameDN, and obliterate.

  9.  Move coupled with 4. above.  Permissions needed are import,
      export, renameDN, write, and obliterate.

For a given case, if the required permissions are granted, then the



Stokes, et al            Expires 29 December 2001              [Page 34]




Internet-Draft            Access Control Model              29 June 2001



operation is allowed by the access control model.  If, for a given case,
the required permissions are not granted, then the operation MUST fail.
If the access control failure is due to a missing attribute or entry
permission on entry, then if "u" (discloseOnError) is granted to entry,
then the usual error codes (such as noSuchObject, attributeOrValueExists
and insufficientAccess) and matchedDN value may be returned; if "u" is
not granted to entry then nosuchObject MUST be returned and matchedDN
set to "".  Similar logic applies if the access control failure was due
to a missing permission on newSuperior.


5.7  Compare Operation

Recall that the parameters of the Compare operation per RFC2251 [LDAPv3]
Section 4.10 are:

   CompareRequest ::= [APPLICATION 14] SEQUENCE {
        entry           LDAPDN,
        ava             AttributeValueAssertion }

Then the permissions required by authzId that need to be evaluated are
as follows:


  1.  permission "c" to the attribute in entry on which the comparison
      is being made.

If each of these items is satisfied then the operation is allowed by the
access control model.  If one of these items is not satisfied, then the
operation MUST fail.  In this case, if "u" (discloseOnError) is granted
to entry, then the usual error codes (such as noSuchObject, and
insufficientAccess) and matchedDN value may be returned; if "u" is not
granted to entry then nosuchObject MUST be returned and matchedDN set to
"".


5.8  Abandon Operation

Recall that the parameters of the Abandon operation per RFC2251 [LDAPv3]
Section 4.6 are:

   AbandonRequest ::= [APPLICATION 16] MessageID

authzId always has the right to send an Abandon Operation for an
operation he previously initiated.


5.9  Extended Operation

Recall that the parameters of the Extended operation per RFC2251
[LDA{v3] Section 4.12 are:



Stokes, et al            Expires 29 December 2001              [Page 35]




Internet-Draft            Access Control Model              29 June 2001



   ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
        requestName      [0] LDAPOID,
        requestValue     [1] OCTET STRING OPTIONAL }

The access required for an Extended Operation is beyond the scope of
this document.  The required access will normally be defined by the
implementer of the extended request.



6.  Required Permissions for Handling Aliases and References

Use of aliases and referrals are part of LDAPv3.  However, neither is
particularly well-defined.  Alias objects and attributes are defined in
RFC 2256 as derived from X.500, but LDAPv3 does not explicitly define
their semantics or behavior.  X.500 does define alias semantics and
behavior with respect to access control; we define its behavior in
LDAPv3 based on the X.511 (1993) [X511], section 7.11.1.  Referrals and
knowledge information are still under design in LDAPv3; they are defined
in X.500, however, X.500 does not specify their semantics and behavior
with respect to access control.  We define their semantics and behavior
in LDAPv3 in terms that should be independent of the future LDAPv3
definition of referrals and knowledge information.


6.1  ACI Distribution

Currently there is no LDAP standard defining how to distribute directory
data between LDAP servers. Consequently this model cannot fully specify
the behavior of the Access Control Model in a distributed environment.
The case of distribution via referrals is treated in the "Referrals"
section below. In the case of chaining (where one LDAP server forwards a
request to another on behalf of a client) then it is server specific how
the access control model behaves in this environment. Similarly it is
server specific how the server determines whether the chaining of an
operation is permitted in the first place. For example, the
implementation may choose to regard the local naming context and the
remote subordinate naming context as separate Access Control Specific
Areas, or it may regard the DIT as one Access Control Specific Area and
implement mechanisms to propagate access control information between the
two servers. The behavior of the Access Control Model in distributed
environments such as these is beyond the scope of this model.


6.2  Aliases

There are two things to protect with respect to aliases:  the real name
of the aliased object and the location of the server holding it.

If alias de-referencing is required in the process of locating a target
entry, no specific permissions are necessary for alias de-referencing to



Stokes, et al            Expires 29 December 2001              [Page 36]




Internet-Draft            Access Control Model              29 June 2001



take place. Access control is enforced at the object pointed to by the
alias.

If alias de-referencing would result in a continuationReference (e.g.
from a search operation), then browse permission is required to the
alias entry and read permission is required to the attribute.  Requiring
these permission closes the hole of discovery.


6.3  Referrals

If a referral is to be followed, no specific permissions are necessary
for the ldap client to follow the referral. Access control is enforced
at the referenced object.  If a referral is returned, then browse is
required on the entry and read permission is required to the attribute
containing the referral (we cannot name this attribute exactly today
because there are no RFCs on this). If the server implements a default
referral, then no special permissions are required to read and return
that referral.  Requiring these permissions closes the hole of
discovery.  In the default case, it is assumed that a default referral
is public.



7.  Controlling Access to Access Control Information

The entryACI and subtreeACI attributes are used to specify control for
who has permission to set/change access control information (entryACI
and subtreeACI).  The entryACI and subtreeACI attributes/OIDs are just
another attribute described with set of rights and permissions, and
subject as a value of the entryACI and subtreeACI attributes.  (See the
example in the "ACI Examples" section).

If the policy for controlling the entryACI and subtreeACI attributes are
not specified for any object in the tree, behavior is implementation
defined. For instance, if no object anywhere in the tree defines the
access for entryACI/subtreeACI within the entryACI/subtreeACI
attributes, then the server could simply assert that the 'root DN' is
considered the policy owner (controller for controlling access control)
for all objects.



8.  ACI Examples

Note that in the examples, the form "OID.<attrname>" refers to the OID
in dotted decimal form for the attribute <attrname>.  This shorthand
notation is used only for the examples.  In implementation, the dotted
decimal form of the OID is used.





Stokes, et al            Expires 29 December 2001              [Page 37]




Internet-Draft            Access Control Model              29 June 2001



8.1  Attribute Definition

The following examples show the access required to control access to the
entryACI and subtreeACI attributes.  The first example shows controlling
the access control on an individual entry and its attributes.  The
second example shows controlling the access control on a subtree.  The
authnLevel is set so that a reasonably secure form of authentication is
required, since changing ACI has significant security consequences.

 entryACI: grant:rwo#
    OID.entryACI#authnLevel:limited:role:cn=aciAdmin

 subtreeACI: grant:rwo#
    OID.subtreeACI#authnLevel:limited:role:cn=aciAdmin

The next example shows a subtreeACI attribute where a group  "cn=Dept
XYZ, c=US" is being given permissions to read, search, and compare
attribute attr1. The permission applies to the entire subtree below the
node containing this ACI.

 subtreeACI: grant;rsc#
      OID.attr1#authnLevel:weak:group:cn=Dept XYZ,c=US

The next example shows an ACI attribute where a role
"cn=SysAdmins,o=Company" is being given permissions to browseDN,
viewEntry, and returnDN for objects below this node.  The role is also
being given permission to read, search, and compare to attribute attr2
and read, search, compare, write, obliterate to attr3.  The permissions
apply to the entire subtree below the node containing this ACI.

 subtreeACI: grant:bvt#
            [entry]#authnLevel:weak:role:cn=SysAdmins,o=Company

 subtreeACI: grant:rsc#
            OID.attr2#authnLevel:weak:role:cn=SysAdmins,o=Company

 subtreeACI: grant:rscwo#
            OID.attr3#authnLevel:weak:role:cn=SysAdmins,o=Company


8.2  Modifying the entryACI and subtreeACI Values

Modify-Replace works as defined in the ldap operation modify. If the
attribute value does not exist, create the value. If the attribute does
exist, replace the value.  If the entryACI/subtreeACI value is replaced,
all entryACI/subtreeACI values are replaced.  To modify the
entryACI/subtreeACI attributes requires you to have 'w' and 'o'
permission on the entryACI/subtreeACI attribute (recall that a value of
entryACI/subtreeACI specifies entryACI/subtreeACI so one can control
access to the entryACI/subtreeACI attribute). The examples in this
section assume that you have access to control entryACI/subtreeACI.



Stokes, et al            Expires 29 December 2001              [Page 38]




Internet-Draft            Access Control Model              29 June 2001



A given subtreeACI for an entry:

 subtreeACI: deny:rw#[all]#authnLevel:weak:group:cn=Dept ABC

 subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ

perform the following change:

  dn: cn=someEntry
  changetype: modify
  replace: subtreeACI
  subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept LMN

The resulting ACI is:

 subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept LMN

( subtreeACI values for Dept XYZ and ABC are lost through the replace )

During an ldapmodify-add, if the ACI does not exist, the create the ACI
with the specific entryACI/subtreeACI value(s).  If the ACI does exist,
then add the specified values to the given entryACI/subtreeACI.  For
example a given ACI:

 subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ

with a modification:

  dn: cn=someEntry
  changetype: modify
  add: subtreeACI
  subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ

would yield an multi-valued ACI of:

 subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ

 subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ

To delete a particular ACI value, use the regular ldapmodify - delete
syntax

Given an ACI of:

 subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
 subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ

  dn: cn = some Entry
  changetype: modify
  delete: subtreeACI
  subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ



Stokes, et al            Expires 29 December 2001              [Page 39]




Internet-Draft            Access Control Model              29 June 2001



would yield a remaining ACI on the server of

subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ

The attributes which are defined for access control interchange may be
used in all LDAP operations.

Within the ldapmodify-delete operation, the entire acl may be deleted by
specifying

 dn: cn = some Entry
 changetype: modify
 delete: entryACI

 dn: cn = some Entry
 changetype: modify
 delete: subtreeACI

In this case, the entry would then inherit its ACI from other nodes in
the tree depending on the inheritance model.

Similarly, if all values of entryACI and subtreeACI are deleted, then
the access control information for that entry is defined by the
inheritance model.


8.3  Evaluation

These examples assume that the ACI entries listed in each example are
the only ACI which applies to the entry in question; if backing-store
ACI also exists, the effective policy may be different from that listed
in each example.

Assume cn=jsmith is a member of group cn=G1.  Assume cn=jsmith is a
member of group cn=G2.


Example #1

 dn: o=XYZ, c=US
 subtreeACI: grant:r#attr2
            #authnLevel:weak:group:cn=G1,ou=ABC,o=XYZ,c=US
 subtreeACI: grant:w#attr2
            #authnLevel:weak:group:cn=G2,ou=ABC,o=XYZ,c=US

What rights does cn=jsmith have to attr2 of o=XYZ,c=US?  Read-write (rw)
access; ACI is combined because both subjects (group) have same
precedence.






Stokes, et al            Expires 29 December 2001              [Page 40]




Internet-Draft            Access Control Model              29 June 2001



Example #2

 dn: o=XYZ, c=US
 subtreeACI: grant:rw#OID.attr3
            #authnLevel:weak:group:cn=G1,ou=ABC,o=XYZ,c=US
 subtreeACI:
deny:w#OID.attr3#authnLevel:weak:group:cn=G2,ou=ABC,o=XYZ,c=US

What rights does cn=jsmith have to attr3 of o=XYZ, c=US?  Read access;
write is denied (deny has precedence over grant).


Example #3

 dn: o=XYZ, c=US
 subtreeACI: grant:m#OID.attr5
            #authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
 subtreeACI: grant:m#OID.cn
            #authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
 subtreeACI: grant:m#OID.sn
            #authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
 subtreeACI: grant:a#[entry]
            #authnLevel:weak:authzID-dn:#cn=jsmith,o=ABC,c=US

What rights does cn=jsmith have to o=XYZ, c=US? Make(m) on attributes
attr5, cn, and sn and Add(a) on the entry.  These are the minimal yet
sufficient permissions to create a new object, cn=New, o=XYZ, c=US with
values for the attr5, cn, and sn attributes.  This example illustrates
how the "m" permission can be used to limit the attributes that can be
created on a new entry.


Example #4

 dn: c=US
 subtreeACI: grant:m#[all]#authnLevel:weak:subtree:c=US
 dn: o=XYZ, c=US
 subtreeACI: grant:a#[entry]#
            authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US

What rights does cn=jsmith have to o=XYZ, c=US? Make(m) on attributes
all attributes and Add(a) on the entry. These are sufficient permissions
to create a new object, cn=New, o=XYZ, c=US with values for any desired
attributes.  For administrators who do not wish to limit the attributes
that can be created on new entries, this example shows how a single
ldapACI at the top of the domain solves the problem.








Stokes, et al            Expires 29 December 2001              [Page 41]




Internet-Draft            Access Control Model              29 June 2001



Example #5

 dn: dc=com,dc=demo
 subtreeACI: grant:rw#description;lang-en#authnLevel:weak:authzID-dn:
             cn=rvh,dc=att,dc=com
 subtreeACI: grant:rw#description;lang-en,description;lang-fr#
             authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com

In this example, cn=rvh,dc=att,dc=com has "rw" access to the English-
language "description" attributes of entries under dc=com,dc=demo.
cn=rob,dc=sun,dc=com has "rw" rights to both English- and French-
language "description" attributes.  The example demonstrates that
"Attribute Descriptions", not just "Attribute Types", can be used in the
"attr" field of an ACI.  See [LangCode] for more information on the
attribute options used here.


8.4  ModDN

There are many different actions that can happen when the modDN command
are used. The following illustrates the permissions needed in order to
execute each scenario.  For all examples, we will assume the role
cn=Admins is working with the following entry:

 dn: cn=personA, o=Company
 cn: personA
 cn: FirstName
 sn: LastName
 objectclass: person


Example #1

Perform a modRDN only, using an existing attribute value. In this case,
we perform a modRDN and rename cn=personA, o=Company to cn=FirstName,
o=Company. The entryACI value for this entry must give the cn=Admin role
rename permission on the entry.

 entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin


Example #2

We wanted to perform a ModRDN and add a new attribute value. In this
case we are renaming cn=personA, o=Company to cn=newFirstName,
o=Company. The entryACI value must give the cn=Admin role rename
permission on the entry and w permission on the cn attribute.

 entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
 entryACI: grant:w#cn#authnLevel:weak:role:cn=Admin




Stokes, et al            Expires 29 December 2001              [Page 42]




Internet-Draft            Access Control Model              29 June 2001



Example #3

Perform a modRDN, using an existing attribute, but delete the old RDN
value. Here, we perform a modRDN and rename cn=personA, o=Company to
cn=FirstName, o=Company and set the deleteOldRdn flag to true. The
cn=Admin role must have permission to rename the entry, and to delete a
cn attribute value ( i.e. 'o' ).

 entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
 entryACI: grant:o#OID.cn#authnLevel:weak:role:cn=Admin


Example #4

Perform a modRDN, using an new cn attribute value (cn=newFirstName), and
delete the old RDN value (cn=personA). Here, we perform a modRDN and
rename cn=personA, o=Company to cn=newFirstName, o=Company and set the
deleteOldRdn flag to true. The cn=Admin role must have permission to
rename the entry, and to delete and write the cn attribute value.

 entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
 entryACI: grant:w,o#OID.cn#authnLevel:weak:role:cn=Admin


Example #5

We want to change the entry's location in the DIT ( modDN ) and keep the
same RDN Value. In this case we are moving cn=personA, o=Company to
cn=personA, o=CompanyB. The cn=Admin role must have export permission on
the original entry, and import permission on the new superior object (
the new parent ).  The cn=personA, o=Company entryACI is:

 entryACI: grant:e#[entry]#authnLevel:weak:role:cn=Admin

and the o=CompanyB entryACI is:

 entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin


Example #6

We want to change the entry's location in the DIT ( modDN ) and change
the RDN Value to an existing attribute value. In this case we are moving
cn=personA, o=Company to cn=FirstName, o=CompanyB. The cn=Admin role
must have rename and export permission on the original entry, and import
permission on the new superior object ( the new parent ).  The
cn=personA, o=Company entryACI is:

 entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin

and the o=CompanyB entryACI is:



Stokes, et al            Expires 29 December 2001              [Page 43]




Internet-Draft            Access Control Model              29 June 2001



 entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin


Example #7

We want to change the entry's location in the DIT ( modDN ) and change
the RDN Value to a new attribute value.  In this case we are moving
cn=personA, o=Company to cn=newFirstName, o=CompanyB. The cn=Admin role
must have rename and export permission on the original entry, write
permission on the naming attribute ( cn) and import permission on the
new superior object ( the new parent ).  The cn=personA, o=Company
entryACI is:

 entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
 entryACI: grant:w#OID.cn#authnLevel:weak:role:cn=Admin

and the o=CompanyB entryACI is:

 entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin


Example #8

We want to change the entry's location in the DIT ( modDN ) and change
the RDN Value to an existing attribute value, and delete the old RDN
value.  In this case we are moving cn=personA, o=Company to
cn=FirstName, o=CompanyB and deleting the attribute value personA. The
cn=Admin role must have rename and export permission on the original
entry, delete ('o') permission on the naming attribute (cn) and import
permission on the new superior object (the new parent).  The cn=personA,
o=Company entryACI is:

 entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
 entryACI: grant:o#cn#authnLevel:weak:role:cn=Admin

and the o=CompanyB entryACI is:

 entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin


Example #9

We want to change the entry's location in the DIT ( modDN ) and change
the RDN Value to a new attribute value, and delete the old RDN value.
In this case we are moving cn=personA, o=Company to cn=newFirstName,
o=CompanyB and deleting the attribute value personA. The cn=Admin role
must have rename and export permission on the original entry, write
('w'), and delete ('o') permission on the naming attribute (cn) and
import permission on the new superior object ( the new parent ).  The
cn=personA, o=Company entryACI is:




Stokes, et al            Expires 29 December 2001              [Page 44]




Internet-Draft            Access Control Model              29 June 2001



 entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
 entryACI: grant:wo#OID.cn#authnLevel:weak:role:cn=Admin

and the o=CompanyB entryACI is:

 entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin


8.5  Interaction Among ACI

These examples show how ACI in different parts of the tree interact.
Examples with varying authnLevel are given in the next section.

The examples refer to this fragment of a directory tree:

                               dc=com
                                  |
                         +--------+---------------+
                         |                        |
                     dc=tivoli                 dc=sun
                         |                        |
                     cn=ellen                  cn=rob

Example #1

If the ACI is as follows:

 at dc=com:  subtreeACI:grant:rw#[all]#authnLevel:weak:
                authzID-dn:cn=rob,dc=sun,dc=com
 at dc=tivoli,dc=com:  subtreeACI:grant:r#[all]#authnLevel:weak:
                          authzID-dn:cn=rob,dc=sun,dc=com

Then the effective rights of cn=rob,dc=sun,dc=com to all the attributes
of object cn=ellen,dc=tivoli,dc=com are "rw".  The ACI at
dc=tivoli,dc=com is redundant.

Example #2

If the ACI is as follows:

 at dc=com:  subtreeACI:grant:r#[all]# authnLevel:weak:
                authzID-dn:cn=rob,dc=sun,dc=com
 at dc=tivoli,dc=com:  subtreeACI:grant:w#OID.uid#authnLevel:weak:
                          authzID-dn:cn=rob,dc=sun,dc=com

Then cn=rob,dc=sun,dc=com has effective rights of "r" to all the
attributes of object cn=ellen,dc=tivoli,dc=com, and effective rights of
"rw" to the uid attribute of object cn=ellen,dc=tivoli,dc=com.  Also,
cn=rob,dc=sun,dc=com has effective rights of "r" to all attributes of
object cn=rob,cn=sun,cn=com.




Stokes, et al            Expires 29 December 2001              [Page 45]




Internet-Draft            Access Control Model              29 June 2001



Example #3

If the ACI is as follows:

 at dc=com:  subtreeACI:grant:rw#[all]#authnLevel:weak:
                authzID-dn:cn=rob,dc=sun,dc=com
 at dc=tivoli,dc=com:  subtreeACI:deny:w#[all]#authnLevel:weak:
                          authzID-dn:cn=rob,dc=sun,dc=com

Then cn=rob,dc=sun,dc=com has effective rights of "r" (but not "w") to
all the attributes of object cn=ellen,dc=tivoli,dc=com and has effective
rights of "rw" to all attributes of objects cn=rob,dc=sun,dc=com.

Example #4

If the ACI is as follows:

 at dc=com:  subtreeACI:grant:r#OID.uid#authnLevel:weak:
                authzID-dn:cn=rob,dc=sun,dc=com
 at dc=tivoli,dc=com:  subtreeACI:grant:w#OID.sn#authnLevel:weak:
                          authzID-dn:cn=rob,dc=sun,dc=com

Then cn=rob,dc=sun,dc=com has effective rights of "r" to the uid
attribute and "w" to the sn attribute of object
cn=ellen,dc=tivoli,dc=com.

Example #5

If the ACI is as follows:

 at dc=com:  subtreeACI:grant:r#OID.uid#authnLevel:weak:
                authzID-dn:cn=rob,dc=sun,dc=com
 at cn=rob,dc=sun,dc=com: entryACI:grant:rw#[all]#authnLevel:weak:
                             this:

Then cn=rob,dc=sun,dc=com has effective rights of "rw" to all attributes
of object cn=rob,dc=sun,dc=com.

Example #6

If the ACI is as follows:

 at dc=com:  subtreeACI:grant:rw#uid#authnLevel:weak:
                authzID-dn:cn=rob,dc=sun,dc=com
 at dc=tivoli,dc=com: subtreeACI:deny:w#uid#authnLevel:weak:
                         subtree:dc=sun,dc=com

Then cn=rob,dc=sun,dc=com has rights of "r" to the uid attribute of
object cn=ellen,dc=tivoli,dc=com.   While checking the "w" permission,
the subtreeACI at dc=tivoli,dc=com is lower in the tree than the
subtreeACI at dc=com, so it takes precedence at Step 1.



Stokes, et al            Expires 29 December 2001              [Page 46]




Internet-Draft            Access Control Model              29 June 2001



Example #7

If the ACI is as follows:

 at dc=com:  subtreeACI:grant:rw#OID.uid#authnLevel:weak:
                authzID-dn:cn=rob,dc=sun,dc=com
 at dc=com:  subtreeACI:deny:w#OID.uid#authnLevel:weak:
                subtree:dc=sun,dc=com

Then cn=rob,dc=sun,dc=com has rights of "rw" to the uid attribute of
object cn=ellen,dc=tivoli,dc=com.   While checking the "w" permission,
the two subtreeACI are at the same level in the tree (step 1) and the
Subject Type dn-dn has precedence over Subject Type subtree (step 2), so
the first ACI has precedence over the second.

Example #8

If the ACI is as follows:

 at dc=com:  subtreeACI:grant:rw#OID.uid#authnLevel:weak:
                subtree:dc=sun,dc=com
 at dc=com:  subtreeACI:deny:w#OID.uid#authnLevel:weak:subtree:dc=com

Then cn=rob,dc=sun,dc=com has rights of "r" to the uid attribute of
object cn=ellen,dc=tivoli,dc=com.   While checking the "w" permission,
the two subtreeACI are at the same level in the tree (step 1) and they
have the same Subject Type (step 2), so the precedence of deny over
grant (step 5) is the deciding factor.

Example #9

If the ACI is as follows:

 at dc=com:  subtreeACI:grant:rw#OID.uid#authnLevel:weak:
                subtree:dc=sun,dc=com
 at dc=com:  subtreeACI:deny:w#[all]#authnLevel:weak:subtree:dc=com

Then cn=rob,dc=sun,dc=com has rights of "rw" to the uid attribute of
object cn=ellen,dc=tivoli,dc=com.   While checking the "w" permission,
the two subtreeACI are at the same level in the tree (step 1) and they
have the same Subject Type (step 2), so the precedence of a specific
attribute list over "[all]" (step 4) is the deciding factor.

8.6  Use of ipAddress in ACI

Using the tree fragment from Section 8.5:








Stokes, et al            Expires 29 December 2001              [Page 47]




Internet-Draft            Access Control Model              29 June 2001



Example #1

If the ACI is as follows:

  at dc=com: subtreeACI: deny:adeinbvtug#[entry]#
                   authnLevel:strong:ipAddress:10.0.0.0-10.255.255.255
             subtreeACI: deny:rwospcm#[all]#
                   authnLevel:strong:ipAddress:10.0.0.0-10.255.255.255
             subtreeACI: grant:rscp#[all]#authnLevel:none:public:
             subtreeACI: grant:btv#[entry]#authnLevel:none:public:

Then any user regardless of the strength of their authentication is
denied all permissions if they happen to be connecting from an IP
address in the 10-net.  If they connect from any other address, they
have "rscp" permissions for all attributes and "btv" permissions for all
entries in the dc=com subtree.

Example #2

If the ACI is as follows:

  at dc=com: subtreeACI: grant:adeinbvtug#[entry]#
                   authnLevel:weak:ipAddress:10.0.0.0-10.255.255.255
             subtreeACI: grant:rspwocm#[all]#
                   authnLevel:weak:ipAddress:10.0.0.0-10.255.255.255

It will have no effect.  While it might seem that it would grant total
access to any user bound from an address in 10-net, the special rules
governing ipAddress and dns as subjects make them useful only for deny
ACI, not for grants.  This was done because the effects of a mistaken
grant to an IP address range or wildcarded DNS name could be extremely
serious.

An (insane) administrator who really wants to grant total access to
anyone on 10-net would have to specify:

  at dc=com: subtreeACI: grant:adeinbvtug#[entry]#authnLevel:weak:public:
             subtreeACI: deny:adeinbvtug#[entry]#
                   authnLevel:strong:ipAddress:0.0.0.0-9.255.255.255,
                   11.0.0.0-255.255.255.255
             subtreeACI: grant:rspwocm#[all]#authnLevel:weak:public:
             subtreeACI: deny:rspwocm#[all]#
                   authnLevel:strong:ipAddress:0.0.0.0-9.255.255.255,
                   11.0.0.0-255.255.255.255

This ACI depends on the fact that a "deny" works on the stated
authnLevel and all lower authnLevels while a "grant" works on the stated
level and all higher authnLevels.






Stokes, et al            Expires 29 December 2001              [Page 48]




Internet-Draft            Access Control Model              29 June 2001



8.7  Use of authnLevel in ACI

Using the tree fragment from Section 8.5:

Example #1

If the ACI is as follows:

 at dc=com:  subtreeACI:grant:rw#OID.sn#authnLevel:strong:
                authzID-dn:cn=rob,dc=sun,dc=com
 at dc=tivoli,dc=com: subtreeACI:grant:r#OID.sn#authnLevel:limited:
                         authzID-dn:cn=rob,dc=sun,dc=com

Then cn=rob,dc=sun,dc=com has effective rights of "rw" to the sn
attribute of object cn=ellen,dc=tivoli,dc=com if the BIND for this
session used strong authentication.  If the BIND for this session used
limited authentication, cn=rob,dc=sun,dc=com has effective rights of "r"
to  the sn attribute of object cn=ellen,dc=tivoli,dc=com.  If the BIND
for this session used weak or no authentication, cn=rob,dc=sun,dc=com
has no rights to object cn=ellen,dc=tivoli,dc=com.

Example #2

If the ACI is as follows:

 at dc=com: subtreeACI: grant:rw#sn#authnLevel:limited:
                     subtree:dc=sun,dc=com
 at dc=tivoli,dc=com: subtreeACI: grant:c;deny:w#sn#authnLevel:strong:
                     authzID-dn:cn=rob,dc=sun,dc=com

Then cn=rob,dc=sun,dc=com has effective rights of "rc" to the sn
attribute of object cn=ellen,dc=tivoli,dc=com if the BIND for this
session used strong authentication.  The "r" permission comes from the
fact that the grant part of the first ACI applies to BINDs at or above
the "limited" level.  If the BIND for this session used limited
authentication, cn=rob,dc=sun,dc=com has "r" rights to the sn attribute
of object cn=ellen,dc=tivoli,dc=com.  The deny part of the second ACI
applies to cases where the authnLevel is less than "strong", so it
overrides the grant of "w" permission in the first ACI.  If the BIND for
this session is at the weak or none authnLevel, the user has no
permissions.

Example #3

If the ACI is as follows:

 at dc=com: subtreeACI:grant:rs#sn#authnLevel:none:public
 at dc=com: subtreeACI:grant:w#sn#authnLevel:strong:
                     subtree:cn=rob,dc=sun,dc=com

Then cn=rob,dc=sun,dc=com has effective rights of "rsw" to the sn



Stokes, et al            Expires 29 December 2001              [Page 49]




Internet-Draft            Access Control Model              29 June 2001



attribute of object cn=ellen,dc=tivoli,dc=com if the BIND for this
session used strong authentication and effective rights "rs" if the BIND
for this session used any other form of authentication.  The grant in
the first ACI applies to BINDs at the "none" level and above, so it
applies to any authnLevel.

Example #4

If the ACI is as follows:

 at root: subtreeACI:grant:ps#[all]#authnLevel:none:public:
          subtreeACI:grant:cr#[all]#authnLevel:weak:subtree:

Then any user including the anonymous user (no name supplied to BIND)
has "ps" permissions to any entry on the server, and any user with an ID
on the server ("subtree:" specifies any DN in the subtree under root)
who has bound using "weak" or better authentication has "pscr"
permissions.

Example #5

If the ACI is as follows:

 at dc=com: subtreeACI:grant:rw#[all]#authnLevel:limited:
                 cn=ellen,dc=tivoli,dc=com
 at dc=tivoli,dc=com: subtreeACI:deny:w#[all]#authnLevel:strong:
                         cn=rob,dc=sun,dc=com

Then if bound at the strong authnLevel, user cn=ellen,dc=tivoli,dc=com
has permissions "rw" to all the attributes of the object
cn=ellen,dc=tivoli,dc=com, and permissions "rw" to all the attributes of
the object cn=rob,dc=sun,dc=com.  But if bound at the limited
authnLevel, user cn=ellen,dc=tivoli,dc=com has permissions "r" to all
the attributes of the object cn=ellen,dc=tivoli,dc=com, and permissions
"rw" to all the attributes of the object cn=rob,dc=sun,dc=com.

This is a consequence of the way that "deny" is processed with respect
to authnLevel.  Since cn=rob,dc=sun,dc=com is denied "w" permission when
authenticating at the "strong" authnLevel, ALL users are denied "w"
permission when bound at any weaker level (see the rules for authnLevel
in "Subjects and Associated Authentication").


9.  GetEffectiveRights Control

The access control information controls provide a way to manipulate
access control information in conjunction with a LDAP operation.  One
LDAP control is defined.  This control allows access control information
to be retrieved.  The control is:

     GetEffectiveRights - obtain the effective rights for a given



Stokes, et al            Expires 29 December 2001              [Page 50]




Internet-Draft            Access Control Model              29 June 2001



     directory entry(s) for a given subject during a ldap_search
     operation

The purpose of the getEffectiveRights control is to allow an
administrator or application to query the server about the rights of
another user of the directory.  This is important as it would allow the
administrator to verify the access control policy for a given subject.
Or it would allow an application for example, to propose to a user the
attributes which he has the right to modify or see in a given entry.

9.1  Request Control

This control may only be included in the ldap_search message as part of
the controls  field  of the  LDAPMessage, as  defined in  Section
4.1.12 of [LDAPv3].

The controlType is set to <OID to be assigned>. The criticality MAY be
either TRUE or FALSE (where absent is also equivalent to FALSE) at the
client's option.  The controlValue is an OCTET STRING, whose value is
the BER encoding of a value of the following SEQUENCE:

 GetEffectiveRightsRequest ::= SEQUENCE{
   gerSubject [0] GERSubject
 }


 GERSubject ::= SEQUENCE {
   gerOneSubject        [0] OneSubject -- from 4.1.2 , OPTIONAL
   germachineSubject    [1] GERMachineSubject,
   gerAuthnLEvel        [2] AuthnLevel, -- from 4.1.2
 }


 GERMachineSubject ::= SEQUENCE{
   gerOneIPAddress [0] IPAddress, -- from 4.1.2
   gerOneDNSName   [1] DomainName    -- from 4.1.2
 }



The getEffectiveRightsRequest specifies a subject, gerSubject, about
whom access control information is being requested.  The control asks
the server to evaluate and return the entry level rights possessed by
the gerSubject for each entry that is returned in the search results,
and for each returned or specifically requested attribute.  The server
will use the Access Decision Algorithm from section 4.3 to determine the
requested effective rights; it will be seen that the parameters defining
the subject in the Access Decision algorithm ((dn OPTIONAL, ipAddress,
dnsName, authnLevel)) are all present in this control.





Stokes, et al            Expires 29 December 2001              [Page 51]




Internet-Draft            Access Control Model              29 June 2001



9.2  Response Control

This control is included in the ldap_search_response message as part of
the controls field of the LDAPMessage, as defined in Section 4.1.12 of
[LDAPv3].

The controlType is set to <OID to be assigned>. There is no need to set
the criticality on the response.  The controlValue is an OCTET STRING,
whose value is the BER encoding of a value of the following SEQUENCE:

 GetEffectiveRightsResponse ::= {
   result  ENUMERATED {
      success                       (0),
      operationsError               (1),
      unavailableCriticalExtension (12),
      noSuchAttribute              (16),
      undefinedAttributeType       (17),
      invalidAttributeSyntax       (21),
      insufficientRights           (50),
      unavailable                  (52),
      unwillingToPerform           (53),
      other                        (80)
      }
 }

The effective rights returned are returned with each entry returned by
the search result.  The control response for ldap_search is:

 PartialEffectiveRightsList ::= SEQUENCE {
   entryLevelRights [0]      EffectiveRights,
   attributeLevelRights [1]  AttributeLevelRights
 }


 EffectiveRights ::= CHOICE {
   rights                [0] Permissions -- from 4.1.2,
   noRights              [1] NULL,
   errorEvaluatingRights [2] GerError
 }


 GerError ::= ENUMERATED
                 {generalError(0),insufficientAccess(1)}


 AttributeLevelRights ::= SEQUENCE OF {
      attr      [0] SEQUENCE OF Attribute,
      rights    [1] EffectiveRights
 }

For a given entry, the control response entryLevelRights field contains



Stokes, et al            Expires 29 December 2001              [Page 52]




Internet-Draft            Access Control Model              29 June 2001



the entry level effective rights that gerSubject has on that entry.  The
attributeLevelRights field contains a list of attributes and the
effective rights that gerSubject has for each of those attributes.  The
list of attributes consists of those attributes returned as part of the
search operation plus any explicitly requested attributes that were not
returned.  An attribute explicitly requested in the search request might
not be returned because the attribute is not in the entry, but we may
still be interested in the effective rights on it, for example to
determine if gerSubject could add that attribute to the entry.

The control returns the permissions that gerSubject has on a given entry
and its attributes.  In order to determine whether these permissions
suffice to allow gerSubject to perform a given LDAP operation on the
entry, the requestor will determine if these permissions satisfy the
required permissions for that LDAP operation, as defined in section 5.

Note that in the case where gerSubject does not have a particular
permission then this control does not allow the requestor to determine
whether that is because the permission was not granted to gerSubject or
whether it was because this permission has been explicitly denied.

The required permissions to see the effective rights of a subject on an
entry and its attributes are specified in 9.3.

If gerSubject has the same rights to a set of attributes in that entry
then the server may group the attributes together in a list.

Although this extends the search operation, there are no
incompatibilities between versions.  LDAPv2 cannot send a control, hence
the above structure cannot be returned to a LDAPv2 client.  A LDAPv3
client cannot send this request to a LDAPv2 server.  A LDAPv3 server not
supporting this control cannot return the additional data.

9.3  Access control for the Get Effective Rights Control

In the presence of the get effective rights control, the access controls
applied to the search operation use the requestor's authorization
identity.

For a given entry returned in the search results then in order to see
the effective rights of any subject for this entry and its attributes
the requestor requires:


  1.  "g" permission on the entry.

If 1. is not satisfied then the "insufficientAccess" error is returned
for the entryLevelRights of that entry and for each of the rights in the
AttributeLevelRights list.

Note A: the set of entries and attributes that are returned are those



Stokes, et al            Expires 29 December 2001              [Page 53]




Internet-Draft            Access Control Model              29 June 2001



visible to the requestor, not the gerSubject.  This means that it is
possible that if gerSubject could see an entry that the requestor could
not then it is impossible for the requestor, using the
getEffectiveRights control, to retrieve the effective rights of
gerSubject on that entry.  However, the idea here is that the requestor
will typically be a powerful administrator whose access rights will be a
superset of those of other users.

Note B: once a given subject has the "g" permission on a given entry
then he has the right to see the effective rights of _any_ subject on
that entry.  It might be useful to have a way to restrict the set of
subjects whose effective rights can be retrieved but that complicates
the model in that, for the "g" permission only, we no longer have a
target/subject type structure but rather a target/subject/otherSubject
structure.  Here, we choose the simpler model rather than this extra
functionality.

9.4  Get Effective Rights example

Suppose we have a DIT with the entries and access controls as described
in the following LDIF example:

 o=sun.com
 objectclass: top
 objectclass: organization
 o: sun.com
 subtreeACI: grant:rsc#[all]#authnLevel:none:public:
 subtreeACI: deny:rsc#[userPassword,subtreeACI,
                entryACI,salary]#authnLevel:none:public:
 subtreeACI: grant:bvt#[entry]#authnLevel:none:public:
 subtreeACI: grant:g#[entry]#authnLevel:limited:this:
 subtreeACI: grant:worsc#[all]#authnLevel:limited:this:
 subtreeACI: deny: wo[entryACI, subtreeACI, salary]#this
 subtreeACI: grant:rscmo,w#[all]#authnLevel:strong:group:
                cn=adminGroup,ou=Groups,o=sun.com
 subtreeACI: grant:bvtugeinad#[entry]#authnLevel:strong
                group: cn=adminGroup,ou=Groups,o=sun.com


 cn=admin,o=sun.com
 objectclass: top
 objectclass: person
 cn: admin
 sn: admin
 userPassword: secret
 salary: 10000


 ou=Groups,o=sun.com
 objectclass: top
 objectclass: organizationalUnit



Stokes, et al            Expires 29 December 2001              [Page 54]




Internet-Draft            Access Control Model              29 June 2001



 ou: Groups


 cn=adminGroup,ou=Groups,o=sun.com
 objectclass: top
 objectclass: groupOfUniqueNames
 uniquemember: cn=admin,o=sun.com


 ou=Eng,o=sun.com
 objectclass: top
 objectclass: organizationalUnit
 ou: Eng


 cn=Joe Engineer,ou=Eng,o=sun.com
 objectclass: top
 objectclass: person
 cn: Joe Engineer
 sn: Engineer
 userPassword: secret
 salary: 10000


 ou=Sales,o=sun.com
 objectclass: top
 objectclass: organizationalUnit


 cn=Joe Sales,ou=Sales,o=sun.com
 objectclass: top
 objectclass: person
 cn: Joe Sales
 sn: Sales
 userPassword: secret
 salary: 100000000000

The access control policy in this DIT policy may be described as
follows:

  1.  anonymous users have full read, search, and compare rights to the
      whole DIT, except for the important attributes userPassword,
      subtreeACI, entryACI, and salary.

  2.  Any user bound with a limited authentication level can modify any
      attributes in his own entry, except subtreeACI, entryACI and
      salary.

  3.  Any user can read all attributes in his own entry.





Stokes, et al            Expires 29 December 2001              [Page 55]




Internet-Draft            Access Control Model              29 June 2001



  4.  Any user bound with a limited authentication level can retrieve
      the effective rights on his own entry (including userPassword,
      salary, entryACI and subtreeACI).

  5.  users, bound with a strong authentication level, in the
      cn=adminGroup,ou=Groups,o=sun.com group have full rights in the
      whole DIT.

Then here are some examples of requests to get the effective rights and
the responses:

Example 1.  Suppose we issue a search authenticated to level strong as
"cn=admin,o=sun.com" (who is in the group
cn=adminGroup,ou=Groups,o=sun.com), with base "o=sun.com", search filter
"objectclass=*", requested attributes "* entryACI", with the
getEffectiveRights control subject set to "cn=Joe
Sales,ou=Sales,o=sun.com" and the MachineSubject specifying the
ipAddress and dnsName of the client machine and the authnLevel set to
limited.

Then the search result and effective rights we see are:

 o=sun.com
 objectclass: top
 objectclass: organization
 o: sun.com


 entryLevelRights: bvt
 attributeLevelRights: objectclass,o: rsc,entryACI: none
 ---
 cn=admin,o=sun.com
 objectclass: top
 objectclass: person
 cn: admin
 sn: admin
 userPassword: secret
 salary: 10000


 entryLevelRights: bvt
 attributeLevelRights: objectclass,cn,sn: rsc
                        userPassword,salary,entryACI: none
 ---
 ou=Groups,o=sun.com
 objectclass: top
 objectclass: organizationalUnit
 ou: Groups


 entryLevelRights: bvt



Stokes, et al            Expires 29 December 2001              [Page 56]




Internet-Draft            Access Control Model              29 June 2001



 attributeLevelRights: objectclass,ou: rsc,entryACI: none
 ---
 ou=Eng,o=sun.com
 objectclass: top
 objectclass: organizationalUnit


 entryLevelRights: bvt
 attributeLevelRights: objectclass,ou: rsc,entryACI: none
 ---
 cn=Joe Engineer,ou=Eng,o=sun.com
 objectclass: person
 cn: Joe Engineer
 sn: Engineer
 userPassword: secret
 salary: 10000


 entryLevelRights: bvt
 attributeLevelRights: objectclass,cn,sn: rsc
                        userPassword,salary,entryACI: none
 ---
 ou=Sales,o=sun.com
 objectclass: top
 objectclass: organizationalUnit


 entryLevelRights: bvt
 attributeLevelRights: objectclass,ou: rsc,entryACI: none
 ---
 cn=Joe Sales,ou=Sales,o=sun.com
 objectclass: person
 cn: Joe Sales
 sn: Sales
 userPassword: secret
 salary: 100000000000


 entryLevelRights: bvtg
 attributeLevelRights: objectclass,cn,sn,userPassword: rscow
                         salary,entryACI: rsc


9.5  Client-Server Interaction

The GetEffectiveRightsRequest control requests the rights that are in
effect for requested directory entry/attribute based on the specified
subject.  The server that consumes the search operation looks up the
rights for the returned directory information based on the subject and
returns that rights information as defined above.




Stokes, et al            Expires 29 December 2001              [Page 57]




Internet-Draft            Access Control Model              29 June 2001



There are six possible scenarios that may occur as a result of the
GetEffectiveRights control being included on the search request:


  1.  If the server does not support this control and the client
      specified TRUE for the control's criticality field, then the
      server MUST return unavailableCriticalExtension as a return code
      in the searchResponse message and not send back any other results.
      This behavior is specified in section 4.1.12 of [LDAPv3].

  2.  If the server does not support this control and the client
      specified FALSE for the control's criticality field, then the
      server MUST ignore the control and process the request as if it
      were not present.  This behavior is specified in section 4.1.12 of
      [LDAPv3].

  3.  If the server supports this control but for some reason the server
      cannot process it and the client specified TRUE for the control's
      criticality field, then the server SHOULD do the following: return
      unavailableCriticalExtension as a return code in the searchResult
      message.

  4.  If the server supports this control but for some reason the server
      cannot process it and the client specified FALSE for the control's
      criticality field, then the server should process as 'no rights
      returned' and include the result Unavailable in the
      GetEffectiveRightsResponse control in the searchResult message.

  5.  If the server supports this control and can return the rights
      information, then it should include the GetEffectiveRightsResponse
      control in the searchResult message with a result of success.

  6.  If the search request failed for any other reason, then the server
      SHOULD omit the GetEffectiveRightsResponse control from the
      searchResult message.

The client application is assured that the correct rights are returned
for scope of the search operation if and only if the
GetEffectiveRightsResponse control returns the rights.  If the server
omits the GetEffectiveRightsResponse control from the searchResult
message, the client SHOULD assume that the control was ignored by the
server.

The GetEffectiveRightsResponse control, if included by the server in the
searchResponse message, should have the GetEffectiveRightsResult set to
either success if the rights are returned or set to the appropriate
error code as to why the rights could not be returned.

The server may not be able to return a right because it may not exist in
that directory object's attribute; in this case, the rights request is
ignored with success.



Stokes, et al            Expires 29 December 2001              [Page 58]




Internet-Draft            Access Control Model              29 June 2001



10.  Security Considerations

This document proposes protocol elements for transmission of security
policy information.  Security considerations are discussed throughout
this model.  Because subject security attribute information is used to
evaluate decision requests, it is security-sensitive information and
must be protected against unauthorized modification whenever it is
stored or transmitted.

Interaction of access control with other directory functions (other than
the ones defined in this document) are not defined in this document, but
instead in the documents where those directory functions are defined.
For example, the directory replication documents should address the
interaction of access control with the replication function.

In general, IP addresses and DNS names should not be used as identities
(subjects) since they can be easily spoofed.  However, some widely-
deployed implementations have long supported and continue to support IP
addresses and DNS names in ACI to enforce access controls based on
topology.  Thus IP address and DNS name are retained in the access
control model though their use should be discouraged in new deployments.

It is good security practice to set defaults to the most secure
settings.  This is done to ensure that accidentally omitting a security
field does not compromise security.  Following this practice in the case
of authnLevel would result in a default of "strong".  This would have
meant that ACI with omitted authnLevel in directories where "strong"
authentication is not available (the great majority of environments at
this time) would deny all access, causing confusion among users and
administrators.  To avoid this problem, authnLevel is required on all
ACI.  This has the useful side-effect of forcing administrators to think
about the strength of their authentication system when setting up ACI.

All of the advantages of authnLevel-based access control may be lost if
system administrators do a poor job of associating actual authentication
mechanisms with the authnLevels in the model.  Administrators should use
external guidelines (for an example, see [AUTHMAP]) if they are not
completely familiar with the relative strengths of the authentication
mechanisms available in their environment.  In addition, administrators
in replicated environments should make sure that the
authnLevel/authentication mechanism mappings at all replicating sites
are consistent.



11.  References

[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, November 1997.

[ATTACK] R. Shirey, "Internet Security Glossary", RFC 2828, May 2000.



Stokes, et al            Expires 29 December 2001              [Page 59]




Internet-Draft            Access Control Model              29 June 2001



[ATTR] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
Access Protocol (v3)": Attribute Syntax Definitions, RFC 2252, December
1997.

[AUTHMAP] K. Zeilenga, "Authentication Mechanisms Levels", Internet
Draft, draft-zeilenga-auth-lvl-01.txt, April 2001.

[AuthMeth] M. Wahl, H. Alvestrand, J. Hodges, and R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000.

[Bradner97] S. Bradner, "Key Words for use in RFCs to Indicate
Requirement Levels", RFC 2119.

[DirCompMatch] S. Legg, "LDAP & X.500 Component Matching Rules",
Internet Draft, draft-legg-ldapext-component-matching-02.txt, May 30,
2001.

[ECMA] ECMA, "Security in Open Systems: A Security Framework" ECMA
TR/46, July 1988.

[IPV6] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
RFC 2373, July 1998.

[LangCode] M. Wahl, T. Howes, "Use of Language Codes in LDAP", RFC 2596,
May 1999.

[LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.

[REQTS] E. Stokes, R. Byrne, R. Blakley, "Access Control Requirements
for LDAP", RFC 2820, May 2000.

[SUBENTRY] E. Reed, "LDAP Subentry Schema", Internet Draft, draft-ietf-
ldup-subentry-08.txt, April 2001.

[UTF] M. Wahl, S. Kille, "Lightweight Directory Access Protocol (v3)": A
UTF-8 String Representation of Distinguished Names", RFC 2253, December
1997.

[X501] Recommendation X.501 (1993), "Information Technology--Open
Systems Interconnection--The Directory: Models".

[X511] ITU-T, "Information technology - Open Systems Interconnection -
The Directory: Abstract service definition", ITU-T Recommendation X.511
(1993) | ISO/IEC 9594-3:1994.


ACKNOWLEDGEMENT

This is to acknowledge the numerous companies and individuals who have
contributed their valuable help and insights to the development of this



Stokes, et al            Expires 29 December 2001              [Page 60]




Internet-Draft            Access Control Model              29 June 2001



specification.


AUTHOR(S) ADDRESS

 Ellen Stokes                       Bob Blakley
 Tivoli Systems                     Tivoli Systems
 9442 Capital of Texas Hwy N        9442 Capital of Texas Hwy N
 Austin, TX 78759                   Austin, TX 78759
 USA                                USA
 mail-to: estokes@tivoli.com        mail-to: blakley@tivoli.com
 phone: +1 512 436 9098             phone: +1 512 436 1564
 fax:   +1 512 436 1190             fax:   +1 512 436 1199

 Debbie Rinkevich                   Robert Byrne
 Momenta                            Sun Microsystems
 ---                                14 Chemin du Vieux Chene
 Austin, TX                         Meylan ZIRST 38240
 USA                                France
 mail-to: drinkevich@momenta.com    mail-to: robert.byrne@.sun.com
 phone: +1 512 732 0060  ext 125    phone: +33 (0)4 76 188 205

 Rick Huber
 AT&T Laboratories
 200 Laurel Avenue South
 Middletown, NJ  07748
 USA
 mail-to: rvh@att.com
 phone: +1 732 420 2632
 fax:   +1 732 368 1690
























Stokes, et al            Expires 29 December 2001              [Page 61]




Internet-Draft            Access Control Model              29 June 2001

























































Stokes, et al            Expires 29 December 2001              [Page 62]








                                CONTENTS


 1.  Introduction...................................................   2

 2.  The LDAPv3 Access Control Model................................   3

 3.  Access Control Mechanism Attributes............................   5
     3.1  Root DSE Attribute for Access Control Mechanism...........   5
     3.2  Subentry Class Access Control Mechanism...................   5

 4.  The Access Control Information Attributes, Syntax, and
     Rules..........................................................   6
     4.1  The ABNF and ASN.1........................................   7
          4.1.1  ACI UTF-8 String Representation   7
          4.1.2  ACI Binary Representation  10
     4.2  The Components of entryACI and subtreeACI Attributes......  12
          4.2.1  Access Rights and Permissions  12
          4.2.2  Attributes  16
          4.2.3  Subjects and Associated Authentication  16
     4.3  Access Control Decision Making............................  18
          4.3.1  The Parameters to the Access Decision
                 Algorithm  18
          4.3.2  Applicability Rules  19
          4.3.3  Precedence Rules  22
          4.3.4  Access Control Decision Algorithm  24
          4.3.5  Precedence/Inheritance Access Decision Example  25

 5.  Required Permissions for each LDAP Operation...................  28
     5.1  Bind Operation............................................  28
     5.2  Search Operation..........................................  28
          5.2.1  Protecting the naming attributes of DNs  31
     5.3  Modify Operation..........................................  31
     5.4  Add Operation.............................................  32
     5.5  Delete Operation..........................................  33
     5.6  Modify DN Operation.......................................  34
     5.7  Compare Operation.........................................  35
     5.8  Abandon Operation.........................................  35
     5.9  Extended Operation........................................  35

 6.  Required Permissions for Handling Aliases and References.......  36
     6.1  ACI Distribution..........................................  36
     6.2  Aliases...................................................  36
     6.3  Referrals.................................................  37

 7.  Controlling Access to Access Control Information...............  37

 8.  ACI Examples...................................................  37
     8.1  Attribute Definition......................................  38
     8.2  Modifying the entryACI and subtreeACI Values..............  38
     8.3  Evaluation................................................  40



                                 - i -











     8.4  ModDN.....................................................  42
     8.5  Interaction Among ACI.....................................  45
     8.6  Use of ipAddress in ACI...................................  47
     8.7  Use of authnLevel in ACI..................................  49

 9.  GetEffectiveRights Control.....................................  50
     9.1  Request Control...........................................  51
     9.2  Response Control..........................................  52
     9.3  Access control for the Get Effective Rights Control.......  53
     9.4  Get Effective Rights example..............................  54
     9.5  Client-Server Interaction.................................  57

10.  Security Considerations........................................  59

11.  References.....................................................  59







































                                 - ii -











Full Copyright Statement

Copyright (C) The Internet Society (2000).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.




























                                - iii -