- Internet-Draft E. Stokes
- LDAP Extensions WG D. Byrne
- Intended Category: Standards Track IBM
- Expires: 5 April 2000 B. Blakley
- Dascom
- 5 October 1999
- Access Control Model for LDAP
- <draft-ietf-ldapext-acl-model-04.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:
+Internet-Draft E. Stokes
+LDAP Extensions WG B. Blakley
+Intended Category: Standards Track Tivoli Systems
+Expires: 14 January 2001 D. Rinkevich
+ IBM
+ R. Byrne
+ Sun Microsystems
+ 14 July 2000
- ietf-ldapext@netscape.com
+ Access Control Model for LDAPv3
+ <draft-ietf-ldapext-acl-model-06.txt>
- COPYRIGHT NOTICE
- Copyright (C) The Internet Society (1997). All Rights
- Reserved.
+STATUS OF THIS MEMO
- ABSTRACT
+This document is an Internet-Draft and is in full
+conformance with all provisions of Section 10 of RFC2026.
- This document describes the access control model for the
- Lightweight Directory Application Protocol (LDAP)
+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.
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 1]
+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 LDAP controls, and the extended operations to the LDAP
+protocol. The current LDAP APIs are sufficient for most
- Internet-Draft Access Control Model 5 October 1999
+Stokes, et al Expires 14 January 2001 [Page 1]
+\f
- directory service. It includes a description of the
- model, the LDAP controls, and the extended operations to
- the LDAP protocol. The current LDAP APIs are sufficient
- for most access control operations. An API (in a
- separate document) is needed for the extended operation
- getEffectiveAccess and specifyCredentials. RFC2219
- [Bradner97] terminology is used.
- 1. Introduction
+Internet-Draft Access Control Model 14 July 2000
- 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 across heterogeneous LDAP
- implementations. The major objective is to provide a
- simple, but secure, highly efficient access control model
- for LDAP while also providing the appropriate flexibility
- to meet the needs of both the Internet and enterprise
- environments and policies. This document defines the
- model and the protocol extensions (controls and extended
- operations).
- 2. Overview
+access control operations. An API (in a separate document)
+is needed for the extended operation getEffectiveAccess. A
+separate requirements document for access control exists
+[REQTS]. The access control model used the requirements
+documents 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.
- 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.
- The access control model defines
+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 while also providing the appropriate
+flexibility to meet the needs of both the Internet and
+enterprise environments and policies. This document defines
+the model and the protocol extensions (controls and extended
+operations).
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 2]
+This draft 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 draft.
+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
- Internet-Draft Access Control Model 5 October 1999
+Stokes, et al Expires 14 January 2001 [Page 2]
+\f
- - A wire protocol for interoperability: The existing
- LDAP protocol flows for add, delete, modify, and
- search are used to manipulate access control
- information. There are additional LDAP controls and
- extended protocol operations defined to further help
- management of access control information:
- getEffectiveRights and specifyCredentials.
- - A set of access control information (ACI) attributes
- 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 addressed and stored at
- the server. These same attributes appear in LDIF
- output for interchange of access control
- information.
- - A set of attributes to identity the access control
- mechanisms supported by a server and a given part of
- the namespace.
+Internet-Draft Access Control Model 14 July 2000
- Encoding of access control information on the wire is per
- the LDAPv3 specifications.
- The instantiation of an access control model at the
- directory server is not defined in this document.
- No mechanisms are defined in this document to control
- access to access control information or for storage of
- access control information at the server; this is vendor
- dependent.
+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.
- A separate requirements document for access control
- exists. The access control model used the requirements
- documents 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.
+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 mechanisms specified in this document are
+neutral with respect to policy inheritance mechanisms,
+explicit vs. implicit denial, and group nesting.
+The access control model defines
- 3. Terminology
+ - What flows on the wire for interoperability
- An "access control list" contains the access control
- policy information controlling access to an object or
+ The existing LDAP protocol flows for ldap operations
+ are used to manipulate access control information. A
+ set of permissions and their semantics with respect to
+ ldap operations is defined. The permissions parallel
+ the types of ldap operations defined. What is
+ transmitted is exactly what is read back. Encoding of
+ access control information on the wire is per the
+ LDAPv3 specifications.
+ There is an additional LDAP control and extended
+ protocol operation defined, getEffectiveRights. LDAP
+ clients use the control and extended operation 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
+ 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 "Operational
+ Semantics of Access Control Operations".
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 3]
+ - Attributes and classes for application portability of
+ access control information
+ An access control information attribute (ldapACI) for
+ application portability: This attribute is used as
+ input to the LDAP APIs so access control information
+Stokes, et al Expires 14 January 2001 [Page 3]
+\f
- Internet-Draft Access Control Model 5 October 1999
+Internet-Draft Access Control Model 14 July 2000
- collection of objects. An access control list consists
- of a set of access control list entries.
- An "access control list entry" defines a single subject
- security attribute's granted rights for the objects
- governed by the access control list to which it belongs.
- The "access control information" (aci) for an object or a
- collection of objects defines which subject security
- attributes entitle a subject to which granted rights.
- The access control information for an object may be
- stored in an access control list.
+ can be addressed uniformly independent of how that
+ information is addressed and stored at the server.
+ This same attribute appears in LDIF output for
+ interchange of access control information.
- An "access decision" is a boolean-valued function which
- answers the question: "can the subject with these subject
- security attributes perform this operation on this
- object?"
+ 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.
- An "access decision function" is an algorithm which makes
- an access decision based on subject security attributes,
- access control information, an object identifier, and an
- operation name (possibly augmented by additional
- contextual information).
+ - An attribute in the rootDSE, discloseOnError, to
+ control whether it is permissible for the server to
+ return the name of an entry or attribute in an error
+ (or empty set) operation result. This closes a hole on
+ the ability to discover information you are not
+ authorized to discover.
- An "access decision function interface" is a programmatic
- interface through which applications can request an
- access decision.
+ - A mechanism to control access to access control
+ information: The access control information attribute,
+ ldapACI, is used to control access to access control
+ information (controls access to itself). How to get an
+ initial ldapACI in the directory is server specific and
+ beyond the scope of this model.
- An "access identity" is an identity which is used by an
- access decision function to make an access decision.
+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.
- An "audit identity" is an identity which does not, in the
- absence of additional information, enable a party
- receiving and examining it to determine which subject it
- belongs to.
+The accessControlSchemes attribute in the ldapACISubEntry
+indicates which access control mechanism is in effect for
+the scope of that ldapACISubEntry. The
+supportedAccessControlSchemes attribute in the rootDSE
+indicates which acess 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.
- A "credential" is a collection of subject security
- attributes.
+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).
- "effective rights" are the complete set of rights a
- subject is entitled to based on all access control lists
- which apply to a specific object and based on all of the
- subject's security attributes.
+Through the use of the mechanism rootDSE attribute and
+ldapACI subentry, it is possible to run multiple mechanisms
+in either the same subtree or separate subtrees. If two
- "granted rights" are the complete set of rights an access
+Stokes, et al Expires 14 January 2001 [Page 4]
+\f
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 4]
+Internet-Draft Access Control Model 14 July 2000
- Internet-Draft Access Control Model 5 October 1999
+mechanisms are run in the same subtree, it is desirable that
+the result be the same independent of mechanism, but
+definition and discussion of this is beyond the scope of
+this model.
- control list entitles a subject to based on a specific
- subject security attribute.
+3. Access Control Mechanism Attributes
- A "group" is a privilege attribute asserting a subject's
- membership in the collection of subjects whose name is
- that of the group.
+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).
- An "identity" is a subject security attribute which is
- unique to a single subject.
- A "privilege attribute" is a subject security attribute
- which may be shared by several subjects.
+3.1 Root DSE Attribute for Access Control Mechanism
- "required rights" are the complete set of rights needed
- to authorize a requester to perform a specific operation
- on an object of a specific type.
+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").
- A "right" is the basic unit of access control
- administration. For each object type in an information
- system, a security administrator defines a set of
- required rights for each operation. For each object in
- the system, a security administrator defines a set of
- granted rights for each subject security attribute. When
- an access decision is required, an access decision
- function checks to make sure that the requester's subject
- security attributes have been granted all required rights
- needed to perform the requested operation on the
- specified target object.
+ (<OID to be assigned>
+ NAME 'supportedAccessControlSchemes'
+ DESC list of access control mechanisms supported
+ by this directory server
+ SYNTAX LDAPOID
+ USAGE dSAOperation
+ )
- A "role" is a privilege attribute asserting a subject's
- organizational position and entitlement to perform the
- operations appropriate to that organizational position.
+The access control mechanism defined is:
+ LDAPv3 <OID to be assigned>
- A "subject' is an entity which initiate actions in an
- information system.
+Other vendor access control mechanisms MAY be defined (by
+OID) and are the responsibility of those vendors to provide
+the definition and OID.
- A "subject security attribute" is a defined property
- which is used by a security policy evaluation system to
- make policy decisions.
+3.2 Root DSE Attribute for Control of Disclosing Errors
+The server specifies whether it is permissible for the name
+of an entry or attribute to be disclosed in an error (or
+empty) operation result. This rootDSE attribute is
+discloseOnError. The default for discloseOnError is false
+(0) or not to disclose on error. The lack of this attribute
- 4. The Model
- The access control mechanism described in this draft
+Stokes, et al Expires 14 January 2001 [Page 5]
+\f
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 5]
+Internet-Draft Access Control Model 14 July 2000
+in the rootDSE is interpreted as the default.
- Internet-Draft Access Control Model 5 October 1999
+ (<OID to be assigned>
+ NAME 'discloseOnError'
+ DESC specify whether to return the name of an
+ entry or attribute in an error (or
+ empty) operation result; 0=do not
+ disclose (default); 1=disclose
+ SYNTAX LDAPString
+ USAGE dSAOperation
+3.3 Subentry Class Access Control Mechanism
- addresses these activities:
+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:
- - Definition of subject security attributes
- information
- - Definition of access control policy
+ ( <OID to be assigned>
+ NAME 'ldapACISubEntry'
+ DESC 'LDAP ACI Subentry class'
+ SUP ldapSubEntry STRUCTURAL
+ MUST ( accessControlSchemes )
+ )
- - Retrieval of subject security attributes
+The accessControlSchemes attribute MUST be in each ldap
+access control subentry 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. 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.
- - Retrieval of effective access rights
+ (<OID to be assigned>
+ NAME 'accessControlSchemes'
+ DESC list of access control mechanisms supported
+ in this subtree
- - Externalization of access control policy information
- 4.1 Access Control Information Model
- This document does not define formats for storage of
- access control information; it does define the
- operational semantics of access control operations.
+Stokes, et al Expires 14 January 2001 [Page 6]
+\f
+Internet-Draft Access Control Model 14 July 2000
+ SYNTAX LDAPOID
+ USAGE dSAOperation
+ )
+4. The Access Control Information Attribute (ldapACI)
+The access control information attribute, ldapACI, is
+defined as:
+ (<OID to be assigned>
+ NAME 'ldapACI'
+ DESC 'ldap access control information'
+ EQUALITY caseIgnoreMatch
+ SYNTAX directoryString
+ USAGE directoryOperation
+ )
+The intent of the attribute definition is to design a common
+interchange format. Any given LDAP server should be able to
+translate the below defined attribute into meaningful
+operation 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
+definition alone will not ensure identical ACL processing
+behavior between servers. The semantics of how a server
+interprets the ACI syntax are defined in the "Operational
+Semantics of Access Control" 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 this
+attribute.
+The attribute definition maintains an assumption that the
+receiving server supports 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. If the server does not support partial
+inheritance and both the entry and subtree scope are used,
+then entry is the prevailing scope. (It is possible for two
+values in the ldapACI attribute to have different scopes
+given the syntax of ldapACI; one might contain 'entry' and
+another might contain 'subtree'. This implies that some
+ldapACI values inherit down the DIT and othersdo not - hence
+partial inheritance of the ldapACI attribute.)
+The attribute is defined so access control information (ACI)
+Stokes, et al Expires 14 January 2001 [Page 7]
+\f
+Internet-Draft Access Control Model 14 July 2000
+can be addressed in a server independent of server
+implementation. This attribute is used in typical LDAP APIs
+and in LDIF output of ACI. This attribute may be queried or
+set on all directory objects. The BNF and definitions are
+given below.
+4.1 The BNF
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 6]
+4.1.1 ACI String Representation
+ Values of this syntax are encoded according to the
+ following BNF which follows the BNF encoding
+ conventions described in [ABNF]:
+ ldapACI = scope "#" rights "#" attr "#" subject
+ scope = "entry" / "subtree"
+ rights = (("grant:" / "deny:") permissions) /
+ ("grant:" permissions ";deny:" permissions)
+ permissions = [permission *("," permission)]
- Internet-Draft Access Control Model 5 October 1999
+ permission = "a" / ; add
+ "d" / ; delete
+ "e" / ; export
+ "i" / ; import
+ "n" / ; renameDN
+ "b" / ; browseDN
+ "t" / ; returnDN
+ "r" / ; read
+ "s" / ; search
+ "w" / ; write (mod-add)
+ "o" / ; obliterate (mod-del)
+ "c" / ; compare
+ "m" / ; make
+ attr = "[all]" / "[entry]" / (attribute *("," attribute))
+ attribute = ; OID syntax (1.3.6.1.4.1.1466.115.121.1.38)
+ ; from [ATTR]
- The diagram below illustrates the componentry of a LDAP
- system and the placement of the function specified in
- this draft.
+ subject = ["authnLevel:" authnLevel ":"]
+ (("authzID-" authzID) /
+ ("role:" dn) /
+ ("group:" dn) /
+ ("subtree:" dn) /
+ ("ipAddress:" ipAddress) /
+ "public:" /
- +-------------+
- | Application |<--attrs to address ACI
- +-------------+ - aCI
- +--------+ - vendorACI
- | LDAP | - policyOwner
- | Client |
- +--------+
- |
- | <-- LDAP controls
- | - getEffectiveAccess
- | - specifyCredentials
- | <-- LDAP extended operations
- | - getEffectiveAccess
- v
- +-----------------------------+
- | LDAP Server (e.g. SLAPD) |
- +-----------------------------+
- . |
- . |
- . |
- . |
- v v
- +----------+ +-----------+
- | Access | | |<-attrs to define
- | Control |<--| Datastore | access control mechanisms
- | Manager | | | - supportedACIMechanisms
- +----------+ +-----------+ - aCIMechanism
- LDAP clients use the controls and extended operations
- specified in this document to 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 access control managers
- external to their datastores. Datastores and external
- access control managers may implement any access control
- rule syntax and semantics they choose, as long as the
- semantics are compatible with that defined in the section
- titled "Operational Semantics of Access Control
- Operations".
+Stokes, et al Expires 14 January 2001 [Page 8]
+\f
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 7]
+Internet-Draft Access Control Model 14 July 2000
+ "this:")
- Internet-Draft Access Control Model 5 October 1999
+ authnLevel = "any" /
+ "simple" /
+ sasl
+ sasl = "sasl:"
+ ("any" /
+ mechanism)
+ mechanism = ; sasl mechanism from 4.2 of [LDAPv3]
- The access control administration mechanisms specified in
- this document are neutral with respect to policy
- inheritance mechanisms, explicit vs. implicit denial,
- and group nesting.
+ authzID = ; authzID from [AuthMeth] repeated below
+ ; for convenience
- 4.2 Bind and Credentials
+ authzId = dnAuthzId / uAuthzId
- A bind authenticates a principal to the directory. A
- principal is represented by a DN. A principal has a set
- of credentials that are used to determine access to
- resources specified in ldap operations. These
- credentials may be pushed to the server by the client by
- using the specifyCredentials control (see section on the
- specifyCredentials control) or may be pulled by the
- server from the directory data, i.e. access control
- information associated with a directory entry using
- normal LDAP operations. Credentials may be local with
- respect to the server. If the credentials are not local
- to the server, i.e. owned by another server or
- administrative scope, then the server may decide to
- define a trust model that states how to evaluate the
- trust of a credential at bind time. The definition of
- such a trust model is outside the scope of this document.
+ ; 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
- 5. Access Control Mechanism Attributes
+ ipAddress = printableString
+ ; dotted decimal form (e.g. 10.0.0.6)
+ ; or use wildcards such as 12.3.45.* to
+ ; specify a specific subnetwork
+ ; or 123.45.6.*+255.255.255.115 to
+ ; specify a subnetmask
+ ; or use a wildcard domain name such as
+ ; *.airius.com to specify a specific
+ ; DNS domain
- There are several attributes defined associated with
- access control. Two attributes are defined to identity
- which access control mechanisms are supported by a given
- server and by a given subtree: supportedACIMechanisms
- and aCIMechanism.
+ printableString ; printableString syntax from [ATTR]
- 5.1 Root DSE Attribute for Access Control Mechanism
+Note that the colon following the "public" and "this"
+subject options exist only to simplify string parsing.
- The server advertises which access control mechanisms it
- supports by inclusion of the 'supportedACIMechanisms'
- attribute in the root DSE. This attribute is a list of
- OIDs, each of which identify an access control mechanism
- supported by the server.
+Note also that per [AuthMeth], authzID may be expanded in
+the future.
- (<OID to be assigned>
- NAME 'supportedACIMechanisms'
+See section titled 'ACI Examples' for examples of the string
+representation.
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 8]
+Stokes, et al Expires 14 January 2001 [Page 9]
+\f
- Internet-Draft Access Control Model 5 October 1999
+Internet-Draft Access Control Model 14 July 2000
- DESC list of access control mechanisms supported
- by this directory server
- SYNTAX LDAPOID
- USAGE dSAOperation
- )
- The access control mechanism defined is:
- LDAPv3 <OID to be assigned>
- Other vendor access control mechanisms can be defined (by
- OID) and are the responsibility of those vendors to
- provide the definition and OID.
+4.1.2 ACI Binary Representation
+ The following ASN.1 data type is used to represent this
+ syntax when transferred in binary form:
- 5.2 Subschema Attribute for Access Control Mechanism
+ ldapACI ::= SEQUENCE {
+ scope ENUMERATED {
+ entry (0),
+ subtree (1) },
+ rights SEQUENCE OF CHOICE {
+ grant [0] Permissions,
+ deny [1] Permissions },
+ attr CHOICE {
+ all [0] NULL,
+ entry [1] NULL,
+ attributes [2] SEQUENCE OF Attribute },
+ subject SEQUENCE {
+ authnLevel CHOICE {
+ any [0] NULL,
+ simple [1] NULL,
+ sasl [2] CHOICE {
+ any [0] NULL,
+ mechanism [1] LDAPString -- from [LDAPv3]
+ }
+ },
+ subject CHOICE {
+ dn [0] DN,
+ user [1] utf8String
+ role [1] DN,
+ group [2] DN,
+ subtree [3] DN,
+ ipAddress [4] IPAddress,
+ public [6] NULL,
+ this [7] NULL }, } -- may be expanded
+ per [AuthMeth]
- A given naming context must provide information about
- which access control mechanism is in effect for that
- portion of the namespace. The following attribute must
- be in each subschema entry associated with a naming
- context whose access control mechanism is different from
- adjacent naming contexts supported by that directory
- server.
+ Permissions ::= SEQUENCE OF ENUMERATED {
+ add (0),
+ delete (1),
+ export (2),
+ import (3),
+ renameDN (4),
+ browseDN (5),
+ returnDN (6),
+ read (7),
+ search (8),
+ write (9),
+ obliterate (10),
+ compare (11),
+ make (12) }
- aCIMechanism lists the value (an OID) that defines the
- access control mechanism in effect for the scope of that
- subschema entry.
- (<OID to be assigned>
- NAME 'aCIMechanism'
- DESC list of access control mechanism supported
- in this subtree
- SYNTAX LDAPOID
- USAGE dSAOperation
- )
+Stokes, et al Expires 14 January 2001 [Page 10]
+\f
- 6. Access Control Information Attributes
- The intent of the following attribute definitions is to
- design a common interchange format. Any given LDAP
- server should be able to translate the below defined
- attributes into a meaningful operation requests. Each
+Internet-Draft Access Control Model 14 July 2000
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 9]
+ Attribute ::= AttributeType -- from [LDAPv3]
+ IPAddress ::= PrintableString -- (e.g. 10.0.0.6)
+4.2 The Components of ldapACI Attribute
- Internet-Draft Access Control Model 5 October 1999
+This section defines components that comprise the access
+control information attribute, ldapACI.
+4.2.1 Scope
- server should be able to understand the attributes; there
- should not be any ambiguity into what any part of the
- syntax means.
+Two scopes for access control information are defined:
- While the end goal is to have a common behavior model
- between different LDAP server implementations, the
- attribute definition alone will not ensure identical ACL
- processing behavior between servers. The semantics of
- how a server interprets the ACI syntax are defined in the
- "Operational Semantics of Access Control' 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 this attribute.
+ - entry - the access control information in the ldapACI
+ attribute applies only to the entry in which it is
+ contained
- The attribute definition maintains an assumption that the
- receiving server supports 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.
+ - subtree - the access control information in the ldapACI
+ attribute applies to each entry down the subtree unless
+ it is overridden by an entry-specific ldapACI whose
+ values are more specific.
- Three attributes are defined so access control
- information (ACI) can be addressed in a server
- independent of server implementation. These attributes
- are used in typical LDAP APIs and in LDIF output of ACI.
- There are three attributes which may be queried or set on
- all directory objects: aci, vendorAci and policyOwner.
- Their BNF and definitions are defined below.
+Use of prescriptive ACIs and scoping via use of a
+ldapACISubEntry is outside the scope of this document.
- 6.1 The BNF
+4.2.2 Access Rights and Permissions
- < aci > ::= < acl entry syntax >
- + [ '#' <acl entry syntax > ]*
+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 ldapACI.
- < vendorAci > ::= <oid> + '#' + < printable string >
+Each of the LDAP access permissions are discrete. One
+permission does not imply another permission. The
+permissions which apply to attributes and the entry parallel
+the type of ldap operations that can be performed.
- < acl entry syntax > ::= <familyOID> + '#' + <scope > + '#'
- + < rights > + '#' + < dnType >
- + '#' + < subjectDn >
+Permissions which apply to attributes:
- < policyOwner > ::= < familyOid > + '#' + <scope >
- + '#' +< dnType > + '#' + < subjectDn >
+ r Read Read attribute values
+ w Write Modify-add values
+ o Obliterate Modify-delete values
+ s Search Search entries with specified attributes
+ c Compare Compare attributes
+ m Make Make attributes on a new entry below
+ this entry
- < subjectDn > ::= < printable string > | "public" | "this"
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 10]
+Stokes, et al Expires 14 January 2001 [Page 11]
+\f
+Internet-Draft Access Control Model 14 July 2000
- Internet-Draft Access Control Model 5 October 1999
+ 1. r Read
+ If granted, permits attributes and values to be
+ returned in a read or search operation.
- < familyOid > ::= < oid >
+ 2. w Write
- <scope > ::= "entry" | "subtree" | <level>
+ If granted, permits attributes and values to be added
+ in a modify operation.
- < level > ::= numericstring
+ 3. o Obliterate
- < dnType > ::= "access-id" | "role" | "group"
+ If granted, permits attributes and values to be
+ deleted in a modify operation.
- < rights > ::= [ ] | [ < right > + [ '$'
- + <right> ] * ]
+ 4. s Search
- < rightsList > ::= <permissions> + ';' + <attrs>
+ If granted, permits attributes and values to be
+ included in a search operation.
- < right > ::= <action > + ';' + <rightsList>
+ 5. c Compare
- < action > ::= "grant" | "deny"
+ If granted, permites attributes and value to be used
+ in a compare operation.
- < permissions > ::= [ ] | [ < permission >
- + [ ',' + <permission> ] ] *
+ 6. m Make
- < attrs > ::= [ < attributeString>
- + [ ',' + < attributeString > ] * ]
+ The attribute permission "m" is required for all
+ attributes that are placed on an object when it is
+ created. Just as the "w" and "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.
- < attributeString > ::= "[all]" | "[entry]"
- | <printableString >
+Note: Modify-replace values of an attribute requires "w"
+and "o" permission.
- < permission > ::= "a" | "d" | "r" | "s" | "w" |
- "c" | "g" | "s" | "m" | "u" | "e"
+Permissions that apply to an entire entry:
- These are the permissions defined for the IETF family OID.
- "a" corresponds to add
- "d" corresponds to delete
- "r" corresponds to read
- "w" corresponds to write
- "c" corresponds to compare
- "g" corresponds to get
- "s" corresponds to set
- "m" corresponds to manage
- "u" corresponds to use
- "e" corresponds to editDn
+ a Add Add an entry below this entry
- 6.2 Other Defined Parameters
- This section defines additional parameters that are used
+Stokes, et al Expires 14 January 2001 [Page 12]
+\f
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 11]
+Internet-Draft Access Control Model 14 July 2000
+ d Delete Delete this entry
+ e Export Export entry & subordinates to new
+ location
+ i Import Import entry & subordinates from some
+ location
+ n RenameDN Rename an entry's DN
+ b BrowseDN Browse an entry's DN
+ t ReturnDN Allows DN of entry to be disclosed in
+ an operation result
- Internet-Draft Access Control Model 5 October 1999
+ 1. a Add
+ If granted, permits creation of an entry in the DIT
+ subject to 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 at least the mandatory attributes.
- in the three (3) attributes that address access control
- information.
+ 2. d Delete
+ If granted, permits the entry to be removed from the
+ DIT regardless of controls on attributes within the
+ entry.
- 6.2.1 Rights Families and Rights
+ 3. e Export
- The rightsFamilyOID tells what permission set etc. will
- follow in the string. The idea was to allow a different
- permission set, scope etc. but with the same syntax.
- So, for a single aCIMechanism ( the IETF one ) there
- could be multiple rights families; one which IETF
- defines, and MUST be recognized by servers claiming
- support for this ACI mechanism, and other rights families
- for models which can use the defined syntax, but need a
- different permission set etc.
+ If granted, permits an entry and its subordinates (if
+ any) to be exported; that is, removed from the current
+ location and placed in 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 attributed, 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.
- The following rights families are defined:
- LDAPv3 <OID to be assigned>
+ 4. i Import
- Other rights families can be defined (by OID). It is the
- responsibility of those parties to provide the definition
- and OID.
+ If granted, permits an entry and its suordinates (if
+ any) to be imported; that is, removed from some other
+ location and placed a t the location to which the
+ permission applies subject to the granting of suitable
+ permissions at the source location. In order to
+ import an entry or its subordinates, there are no
+ prerequisite permissions to contained attributed,
+ 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.
- 6.2.1.1 LDAPv3 Rights Family
- Access rights can apply to an entire object or to
- attributes of the object. Each of the LDAP access rights
- are discrete. One permission does not imply another
- permission. The rights may be ORed together to provide
- the desired rights list. The rights which apply to
- attributes and the entry parallel the type of ldap
- operations that can be performed.
+Stokes, et al Expires 14 January 2001 [Page 13]
+\f
- Rights which apply to attributes:
- 1 Read Read attribute values
- 2 Write Write attribute values
- 4 Search Search entries with specified attributes
- 8 Compare Compare attributes
- Rights that apply to an entire entry:
- 16 Add Add an entry below this entry
- 32 Delete Delete this entry
+Internet-Draft Access Control Model 14 July 2000
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 12]
+ 5. n RenameDN
+ Granting Rename is necessary for an entry to be
+ renamed with a new RDN, taking into account
+ consequential changes to the distinguished names of
+ subordinate entries, if any; if the name of the
+ superior is unchanged, the grant is sufficient. In
+ order to rename an entry, there are no prerequisite
+ permissions to contained attributed, 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.
+ 6. b BrowseDN
+ If granted, permits entries to be accessed using
+ directory operations which do not explicitly provide
+ the name of the entry.
+ 7. t ReturnDN
+ If granted, allows the distinguished name of the entry
+ to be disclosed in the operation result.
- Internet-Draft Access Control Model 5 October 1999
+All permissions (for grant and deny) for an attribute/entry
+and a given subject MUST be contained within one ldapACI
+value, i.e. (in abbreviated form)
+ ldapACI: ...grant OID.attr1 subjectA
+ ldapACI: ...deny OID.attr1 subjectA
+must be ldapACI: ...grant ... deny... OID.attr1 subjectA
- 64 EditDN Edit an entry's DN
+Using the defined BNF it is possible for the permission
+string to be empty. The ACI
- Rights that apply to the object to which the directory
- entry points:
+ ldapACI: subtree#grant#OID.attr1#group:cn=Dept XYZ,c=US
- 128 Manage Perform a privileged operation; used to
- restrict access to operations which
- read or write especially sensitive data
- 256 Use Execute; useful in controlling access to
- the objects referred to by directory
- entries rather than in controlling
- access
- to the directory entries themselves
- 512 Get Get retrieves the attribute values
- 1024 Set Set writes the attribute values
+ ldapACI: subtree#grant:r,s#[all]#group:cn=Dept XYZ,c=US
- The rights that apply to the object to which the
- directory entry points (manage/use/get/set) are best
- described by example. Suppose the object to which the
- directory entry points is a pointer.
+means that this group (Dept XYZ) is granted permission to
+read and search all attributes except OID.attr1 because
+OID.attr1 is more specific than "[all]".
- Manage addresses the right to perform a privileged
- operation such as administrative operations on the
- printer. It can be used to restrict access to operations
- which read/write especially sensitive data. Examples of
- these operations are start queue, stop queue, and flush
- queue.
- Use addresses the right to execute and is useful to
- control access to the objects referred to by the
- directory entry. This right is not applicable to the
- printer example; however, some objects support access to
- user functions as well as data and administrative
- functions to which this right could apply.
+4.2.3 Attributes
- Get in this printer example addresses the right to send
- data access commands to the print that retrieve data. An
- example is list jobs in the queue.
+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. "[entry]" means
- Set in this printer example addresses the right to send
- data modification commands to the printer that affect
- printer operations. Examples are send job to print queue
- and flush job from queue.
+Stokes, et al Expires 14 January 2001 [Page 14]
+\f
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 13]
+Internet-Draft Access Control Model 14 July 2000
+the permissions apply to the entire object. This could mean
+actions such as delete the object, or add a child object.
+"[all]" means the permission set apply to all attributes of
+the entry.
+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]".
- Internet-Draft Access Control Model 5 October 1999
+4.2.4 Subjects and Associated Authentication
+The following subjects are defined and MUST be supported:
- 6.2.2 DN Types
+ - authzID, defined per [authmeth]
- The following DN Types strings are defined and MUST be
- supported:
+ - group, defined as the distinguished name of a
+ groupOfNames or groupOfUniqueNames entry
- - access-id
+ - role
- - group
+ - subtree, defined as the distinguished name of a non-
+ leaf node in the DIT
- - role
+ - ipAddress,
- An access-id is a non-collection (non-group and non-role
- objects) DN that can be authenticated.
+ - public, defined as public access
- Other parties can (and will) define other DN Types. It
- is the responsibility of those parties to provide the
- definition and OID.
+ - this, defined as the user whose name matches that of
+ the entry being accessed
- 6.3 Basic ACI Attribute (aCI)
+Other parties MAY define other subjects. It is the
+responsibility of those parties to provide the definition.
- ( aciOID NAME 'aCI' DESC 'Access control information'
- EQUALITY caseIgnoreMatch SYNTAX directoryString )
+A subject may be qualified by the type of authentication
+required for access to a given attribute(s) or entry. If no
+authnLevel is present, then no specific type of
+authentication is additionally required for access. If
+authnLevel is specified, then that type of authentication is
+additionally required for access. The authnLevels parallel
+the authentication mechanisms specified for LDAPv3: simple,
+SASL (any type of SASL mechanism), and a SASL-specific
+mechanism. The authnLevel of is not an acceptable mechanism
+for this case) as part of obtaining access.
- Within the access control syntax, the family OID
- describes the permissions, dnType, subjectDn and scope
- that will be found in the following string. If the OID
- within the ACI attribute is listed as other than the IETF
- family oid, the syntax is the same as listed below, but
- one or more of the scope, dnType, subjectDn or
- permissions may vary from the IETF defined syntax.
- Within the access control syntax, there is a string which
- describes the rights. This is a composite of the
- permissions and resources to which the subject is being
- granted or denied access. The set of permissions is
- fixed. Either of the actions "grant" | "deny" may be
- used when creating or updating ACI.
+4.3 Grant/Deny Evaluation Rules
- The attributeString is an attribute Name (defined to be a
- printable string). If the string refers to an attribute
- not defined in the given server's schema, the server
- SHOULD report an error. Another option for the
- attributeString is "[entry]". This is provided to
- describe permissions which apply to an entire object.
- This could mean actions such as delete the object, or add
+The decision whether to grant or deny a client access to a
+particular piece of information is based on several pieces
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 14]
+Stokes, et al Expires 14 January 2001 [Page 15]
+\f
+Internet-Draft Access Control Model 14 July 2000
- Internet-Draft Access Control Model 5 October 1999
+of information found within the ldapaci value. Throughout
+the decision making process, there are guiding principals.
+ - Specificity: More specific policies MUST override less
+ specific ones (e.g. individual user entry in ACI takes
+ precedence over group entry).
- a child object. The third option for attributeString is
- "[all]" which means the permission set should apply to
- all attributes.
+ - Deny takes precedence over Grant.
- 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]".
+ - When there are conflicting ACI values, deny takes
+ precedence over grant.
- If two ACIs contain identical familyOID, scope, DnTypes
- and DNs, the permission given DN is specified in two
- distinct acis on any given entry, the rights lists can be
- combined into one list. For example,
+ - Deny is the default when there is no access control
+ information.
- aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
- aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept
- XYZ
+Precendence of Scope Types (highest to lowest)
- is the equivalent of
+ - entry
- aci: 1.2.3.4#subtree#grant;r,w;[all];
- r,attribute1#group#cn=Dept XYZ
+ - subtree
- Using the defined BNF it is possible for the permission
- string to be empty. The ACI
+Precedence of Subjects within a Scope (highest to lowest):
- aci: 1.2.3.4#subtree#grant;;attribute1$grant;r,s;
- [all]#group#cn=Dept XYZ,c=US
+ - ipAddress
- means that this group is granted permission to read and
- search all attributes except attribute1.
+ - authzID, this
- Similarly, the ACI
+ - group, role, this, public
- aci: 1.2.3.4#subtree##group#cn=Dept XYZ, c=US
+ - subtree, public
- simply means that no permissions have been defined for
- this group. It is up to the server implementation as to
- whether the group does or does not receive permission to
- attributes on an entry with an empty rights list.
+Although other types MAY be defined given the BNF, use of
+the well-known types aids in interoperability and
+operational consistency.
- Multiple attributeStrings can be listed after any given
- permission set; for instance, "r,w ; attribute1,
- attribute2". This means that if the server supports a
- attribute aggregation mechanism, attribute1 and
+Access Decision algorithm:
+ 1. Determine all the ldapACI values which could apply to
+ the target DN which is being accessed. This is the DN
+ of the entry which is being queried in a search,
+ modified, deleted, etc. When determining all the
+ ldapACI values, the scope field should be used. All
+ ldapACI values with a scope of 'entry' take precedence
+ over ldapACI values with a scope of 'subtree'.
+ 2. Determine which ldapACI (of the set determined in step
+ 1) apply to the bound DN. This is determined by
+ looking at the subject (combination of subject type
+ and subject value) and bind type. If no bind is in
+ effect (this is possible in ldapv3), then treat this
+ lack of bind as if bound as anonymous. Start with the
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 15]
+Stokes, et al Expires 14 January 2001 [Page 16]
+\f
- Internet-Draft Access Control Model 5 October 1999
+Internet-Draft Access Control Model 14 July 2000
- attribute2 should be considered to be part of the same
- group. If the server does not support a grouping
- mechanism, the permission set applies independently to
- attribute1 and attribute2. For servers that do not
- support attribute grouping, "grant ; r,w ; attribute1,
- attribute2" results in the same operations as "grant ;
- r,w; attribute1$grant; r,w; attribute2"
+ most specific subject type. If at any time, at least
+ one ldapACI value exists for a specificity level, then
+ processing stops; the exception here is 'this' because
+ this may also be combined with group to use power of
+ 'this'. Evaluation should take place on set of
+ ldapACI values which are all of the same specificity
+ level. Subjects of the same precedence are combined
+ using union semantics.
+ 3. Evaluate the remaining ldapACI values and determine a
+ grant/deny decision. If conflicting ldapACI value
+ exists for the same attribute, or attributes (i.e. one
+ ldapACI grants permission and another denies
+ permission), then deny takes precedence over grant.
+ For example, if one is granted permission to
+ "objectclass" in one ldapACI value by being a member
+ of group cn=Admin, and denied permission by being a
+ member of cn = NontrustedAdmins, then the bound user
+ would not receive permission to objectclass.
- 6.3.1 LDAP Operations
+ The rule of specificity also applies to the
+ attributes. If one is denied permission to "[ all ]"
+ attributes, but granted permission to "objectclass"
+ then the more specific value of "objectclass" takes
+ precedence over the less specific value of "[ all ] ".
+ In this case the user would be granted permission to
+ "objectclass" but denied permission to all other
+ attributes.
- 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: aci
+5. Required Permissions for each LDAP Operation
- In this case, the entry would then inherit its ACI from some
- other node in the tree depending on the server inheritance
- model.
+This section defines the required permissions for each LDAP
+operation but 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 the access control is
+available to the userPassword attribute a server may refuse
+modifications due to some server specific policy governing
+access to passwords.
- Deleting the last ACI value from an entry is not the same as
- deleting the ACI from the entry. It is possible for an entry
- to contain an ACI with no values. In this case, nothing is
- returned to the client when querying the aci. It is server
- dependent whether access is granted or denied in the absence
- of any ACI information. Deleting an ACI value which does
- not exist will result in an unchanged ACI and a return code
- specifying that the attribute value does not exist.
+Here, we specify the rights required by a user when
+performing an LDAP operation in terms of the LDAP
+permissions specified in section 6.1. Recall that "a, d,
+e, i, n, b,t" are permissions that apply to entries as a
+whole while permissions "r, s, w, o, c, m" apply to
+attributes within entries.
- 6.4 ACI Examples
- 6.4.1 Attribute Definition
+Stokes, et al Expires 14 January 2001 [Page 17]
+\f
- Pretend IETFFamilyOID = 1.2.3.4
- The following two examples show an administrative
- subdomain being established. The first example shows a
- single user being assigned the policyOwner for the entire
+Internet-Draft Access Control Model 14 July 2000
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 16]
+Required permissions for LDAP extended operations and LDAP
+controls are beyond the scope of this draft.
+There is a requirement that a user should not be able to
+infer the existence of data in the Directory, if the user
+does not have the required access rights to that data. An
+example of this requirement would be in a hosting
+environment where you would not want any users from the coke
+subtree to be able to even discover that the pepsi tree was
+hosted on the same server. This "discloseOnError" feature
+will be set once for server in the rootDSE advertised by the
+attribute discloseOnError. The default for discloseOnError
+is false (0). The lack of this attribute in the rootDSE is
+interpreted as the default. The details of its effects are
+addressed below, operation by operation.
+For the following, assume that the authorization identity of
+the user doing the operation is authzID.
- Internet-Draft Access Control Model 5 October 1999
+5.1 Bind Operation
+This draft does not require any permissions to allow a bind
+operation to proceed.
- domain. The second example shows a group of ids assigned
- to the policy Owner.
+5.2 Search Operation
- policyOwner: 1.2.3.4#subtree#access-id#cn=Hoyt
+Recall that the parameters of the Search operation per RFC
+2251 [LDAPv3] Section 4.5 are:
- policyOwner: 1.2.3.4#subtree#group#cn=System Owners,
- o=Company
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2) },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeDescriptionList }
- The next example shows an aci attribute where a group
- "cn=Dept XYZ, c=US" is being given permissions to read,
- search and compare attribute1. The permission should
- apply to the entire subtree below the node containing
- this ACI.
+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.
- aci:1.2.3.4#subtree#grant;r,s,c;
- attribute1#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
- add objects below this node, and read, search and compare
- attributes 2 and 3. The permission should apply to the
- entire subtree below the node containing this ACI.
- aci: 1.2.3.4#subtree#grant;a;[entry]$grant;
- r,s,c;attribute2, attribute3#role#
- cn=SysAdmins,o=Company
+Stokes, et al Expires 14 January 2001 [Page 18]
+\f
- 6.4.2 Modifying the ACI Values
- Replace works similarly to all other attributes. If the
- attribute value does not exist, create the value. If the
- attribute does exist, replace the value. If the ACI value
- is replaced, all ACI values are replaced.
- A given aci for an entry:
+Internet-Draft Access Control Model 14 July 2000
- aci: 1.2.3.4#subtree#deny;r,w;[all]$grant;r,s,c;
- attribute2#group#cn=Dept ABC
- aci: 1.2.3.4#subtree#grant;r;[all]$grant;r,s,c;
- attribute1#group#cn=Dept XYZ
- perform the following change:
+Then the permissions required by authzID that need to be
+evaluated are as follows:
+ 1. permission "b" 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.
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 17]
+ If this permission is granted then the dn candidateDN
+ MAY be returned.
+ Note: The idea of the "b" permission is to say "a user
+ has discovery rights" at a certain entry in the
+ directory. Assuming that the further required
+ permissions below are satisfied then having "b" right
+ is enough to allow the server to return candidateDN.
+ Of course candidateDN contains in it's components,
+ attributes and attribute values for all the ancestors
+ of candidateDN. This can lead to the slightly odd
+ situation that we can discover the naming attribute of
+ an entry and that attribute's value by virtue of
+ having the required searching permissions to it's
+ child but not by searching the entry directly.
+ 2. permission "s" to each attribute appearing in a
+ presence test during the evaluation of the search
+ filter. permission "r" to each attribute appearing in
+ non-presence tests (see rfc1960, section 3:
+ equalityMatch, substrings, greaterOrEquial,
+ 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 then we do not
+ require any access checks to the attributes of the dn
+ candidateDN as access to these is taken to be granted
+ by the "b" 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 A: Although both "r" and "s" permissions will
+ typically be granted to attributes we keep both
- Internet-Draft Access Control Model 5 October 1999
+Stokes, et al Expires 14 January 2001 [Page 19]
+\f
- dn: cn=someEntry
- changetype: modify
- replace: aci
- aci: 1.2.3.4#subtree#grant;r,w;[all];#group#cn=Dept LMN
- The resulting acl is:
- aci: 1.2.3.4#subtree#grant;r,w;[all];#group#cn=Dept LMN
- ( aci values for Dept XYZ and ABC are lost through the
- replace )
+Internet-Draft Access Control Model 14 July 2000
- During an ldapmodify-add, if the ACI does not exist, the
- create the ACI with the specific aci value(s). If the ACI
- does exist, then add the specified values to the given ACI.
- For example a given ACI:
- aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
- with a modification:
+ permissions as there are cases where the distinction
+ is useful. For example, the ability to grant the
+ right to discover that a user entry contains a
+ userPassword attribute, but not to read it's value
+ ("s" but not "r"). The converse, granting "r" but not
+ "s" permission is less easy to motivate.
- dn: cn=someEntry
- changetype: modify
- add: aci
- aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ
+ Note B: There is an unusual behaviour with respect to
+ naming attributes illustrated in the following
+ example:
- would yield an multi-valued aci of:
+ Suppose I have "b" rights to cn=fred,o=sun.com and "r"
+ rights to attribute objectclass but not "r" rights to
+ cn then with search filter (objectclass=*) I get back
+ the dn and objectclass (and so can see the value of
+ cn), but with a search filter of (cn=fred) I do not
+ get anything.
- aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
- aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ
- To delete a particular aci value, use the regular ldapmodify
- - delete syntax
+ 3. permission "r" to each attribute in the attribute list
- Given an ACI of:
+ AttributeDescriptionList (or all attributes in the
+ entry candidateDN if AttributeDescriptionList is *)
+ whose type and/or value will be returned.
- aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
- aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ
+ Note: 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" permission by using a presence
+ test on that attribute in the search filter.
- dn: cn = some Entry
- changetype: modify
- delete: aci
- aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ
+ 4. permission "t" to the entry candidateDN
- would yield a remaining ACI on the server of
+ 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.
+ 5. Disclose on error for the Search operation
+ If every entry in the scope of the search fails to
+ satisfy item 1 (browse right on the candidate entry)
+ or item 2 (right to use the filter on that entry) and
+ if discloseOnError is not granted to the baseObject
+ entry then the operation MUST fail with a "no such
+ object error" and the matchedDN of the LDAPResult MUST
+ be set to "". If every entry in the scope of the
+ search fails to satisfy items 1 or 2 above and
+ discloseOnError is granted to the baseObject then the
+ empty set of results is returned.
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 18]
+Stokes, et al Expires 14 January 2001 [Page 20]
+\f
- Internet-Draft Access Control Model 5 October 1999
+Internet-Draft Access Control Model 14 July 2000
- aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
+5.3 Modify Operation
+Recall that the parameters of the Modify operation per
+RFC2251 [LDAPv3] Section 4.6 are:
- 6.5 Vendor ACI Attribute (vendorAci)
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ modification SEQUENCE OF SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2) },
+ modification AttributeTypeAndValues } }
- ( vendorAciOID NAME 'vendorACI' DESC 'Vendor specific
- Access control information' EQUALITY caseIgnoreMatch SYNTAX
- directoryString )
- The Vendor specific ACI information is listed in its own
- attribute. This may be used by vendors to provide vendor
- specific access control related information which can not be
- expressed in defined ACISyntax. Within the vendorACI, the
- oid determines the format or the printable string to follow.
+ AttributeTypeAndValues ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+Then the permissions required by authzID that need to be
+evaluated are as follows:
- 6.6 Policy Owner Attribute (policyOwner)
- ( policyOwnerOID NAME 'policyOwner' DESC 'Policy Owner
- Access Control Information' EQUALITY caseIgnoreMatch
- SYNTAX directoryString )
+ 1. permission "w" to each attribute being added to object
- Policy ownership controls administrative subdomains. It
- can also control who has permission to set / change acls
- for implementations that do not have ACI controlling
- access to itself. If there are multiple policy owners
- it is implementation specific as to the behavior of
- whether policy owner #1 can override policy owner # 2.
+ If this permission is not granted to such an
+ attribute, then the operation MUST fail. In this
+ case, if discloseOnError is not granted to the entry
+ then "no such object" error is returned; if
+ discloseOnError is granted to the entry and a
+ duplicate attribute value is being added then
+ "attribute value already exists" error is returned; if
+ discloseOnError is granted to the entry and no
+ duplicate value is being added then an "insufficient
+ access" error is returned.
- The syntax for policyOwner includes the 'scope' flag.
- Servers which do not support inheritance must expand the
- policyOwner inheritance similar to the expansion of the
- ACI. The scope and any inheritance hierarchy for policy
- ownership is distinct from any inheritance hierarchy
- defined for ACI values.
+ 2. permission "o" to each attribute for which a value is
+ being deleted from object
- If the policy owner is not specified for any object in
- the tree, behavior is implementation defined. For
- instance, if no object anywhere in the tree has a
- policy owner, then the server could simply assert that
- the 'root DN' is considered the policy owner for all
- objects. An alternate approach might be that the
- implementation defines the entryDN to be the policy
- owner.
+ If this permission is not granted to such an attribute
+ then the operation MUST fail. In this case, if
+ discloseOnError is not granted to the entry then "no
+ such object" error is returned; if discloseOnError is
+ granted to the entry and the attribute or one of the
+ values to be deleted does not exist then a "no such
+ attribute or value" error is returned; if
+ discloseOnError is granted to the entry and the
+ attribute and all values specified to be deleted exist
+ then an "insufficient access" error is returned.
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 19]
+Stokes, et al Expires 14 January 2001 [Page 21]
+\f
+Internet-Draft Access Control Model 14 July 2000
- Internet-Draft Access Control Model 5 October 1999
+ 3. permissions "o" and "w" to each attribute being
+ replaced in object
- 7. Operational Semantics of Access Control Operations
+ If one of these these permissions is not granted to
+ such an attribute then the operation MUST fail. In
+ this case, if discloseOnError is not granted to the
+ entry then a "no such object" error is returned; if
+ discloseOnError is granted to the entry then
+ "insufficient access" error is returned.
- The semantics of access control operations described in
- this document are defined operationally in terms of
- "histories". A history is a sequence of actions (x1, x2,
- ..., xN).
+5.4 Add Operation
- 7.1 Types of actions
+Recall that the parameters of the Add operation per RFC2251
+[LDAPv3] Section 4.7 are:
- We consider five types of actions:
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
- - LDAP Access Control Policy Update actions:
- invocations of ldap modify when used to add, delete,
- or replace the aci attribute; invocations of ldap
- add when used to add an entry with an aci attribute.
- A LDAP Access Control Policy Update action may
- replace the policy (by completely replacing the aci
- attribute with new policy information) or it may
- grant or deny specific rights while leaving others
- unaffected.
- - LDAP Access Control Policy Query operations:
- invocations of ldap search when used to retrieve the
- aci attribute; invocations of ldap search with the
- getEffectiveRightsRequest control; invocations of
- the ldapGetEffectiveRightsRequest extended
- operation.
+ AttributeList ::= SEQUENCE OF SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
- - Datastore Access Control Policy Update Actions: any
- operation implemented by the server which LDAP is
- using as its datastore which changes the access
- policy enforced with respect to attempts to access
- LDAP directory entries and their attributes.
+Then the permissions required by authzID that need to be
+evaluated are as follows:
- - LDAP Access Request operations: invocations of LDAP
- entry or attribute access operations (Read, Update,
- Search, Compare, etc...).
+ permission "a" to the parent of entry
- - Other operations: anything else, including Datastore
- operations which do not change the access policy
- enforced by the server.
+ 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.
+ 1. permission "m" to the parent of entry for each
+ attribute being added to entry
+If any of these permissions are not granted then the
+operation MUST fail. In this case if discloseOnError is on
+and the entry to be added does not already exist then
+"insufficient access" is returned. If it does exist then
+"Entry already exists" is returned. If discloseOnError is
+off then "No such object" is returned (meaning the parent
+object).
+If they are all granted then the operation MAY proceed.
+Note: We require "m" permission to each attribute to prevent
+an entry from aquiring "unintended" rights (via group or
+role membership), to stop a "rogue" ACI being added that
+would prevent even admins deleting the entry and general
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 20]
+Stokes, et al Expires 14 January 2001 [Page 22]
+\f
+Internet-Draft Access Control Model 14 July 2000
- Internet-Draft Access Control Model 5 October 1999
+consistency with the MODIFY operation.
- 7.2 Semantics of Histories
+Note: The access rights required for the creation of the
+first entry in the directory are beyond the scope of this
+document.
- The semantics of histories are defined as follows:
- - LDAP Update (Replace), LDAP Query
+5.5 Delete Operation
- The Query will show that the subject has all rights
- granted by the Update operation, and no rights not
- granted by the Update operation.
+Recall that the parameters of the Delete operation per
+RFC2251 [LDAPv3] Section 4.10 are:
- - LDAP Update (Grant), LDAP Query
+ DelRequest ::= [APPLICATION 10] LDAPDN
- The Query will show that the subject has all rights
- granted by the Update operation. The Query may show
- that the subject also has other rights not granted
- by the Update operation, depending on the policy in
- force before the Update operation.
+Then the permissions required by authzID that need to be
+evaluated are as follows:
- - LDAP Update (Deny), LDAP Query
- The Query will show that the subject does not have
- any right denied by the Update operation. The Query
- may show that the subject has rights not denied by
- the Update operation, depending on the policy in
- force before the Update operation.
+ 1. permission "d" to the entry in the Delete request
- - LDAP Update (Replace), LDAP Access Request
+If this permission is not granted, then the operation MUST
+fail. In this case if discloseOnError is on and the entry
+to be deleted exists then "insufficient access" is returned.
+If it does not exist then "No such Object" is returned. If
+discloseOnError is off then "No such object" is returned
+(meaning the parent object).
- The Request will succeed if it requires only rights
- granted to the requesting subject by the Update
- operation. The Request will fail with an access-
- denied exception if it requires any right not
- granted by the Update operation.
+If this permission is granted, then the operation MAY
+proceed.
- - LDAP Update (Grant), LDAP Access Request
+Note: One could also require the "o" permission to be
+granted to allow 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.
- The Request will succeed if it requires only rights
- granted to the requesting subject by the Update
- operation. The Request may succeed if it requires
- rights not granted by the Update operation,
- depending on the policy in force before the Update
- operation.
- - LDAP Update (Deny), LDAP Access Request
+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 }
+Then the permissions required by authzID that need to be
+evaluated are as follows:
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 21]
+Stokes, et al Expires 14 January 2001 [Page 23]
+\f
- Internet-Draft Access Control Model 5 October 1999
+Internet-Draft Access Control Model 14 July 2000
- The Request will fail with an access-denied
- exception if it requires any right denied to the
- requesting subject by the Update operation. If the
- Request requires only rights which were not denied
- by the Update operation, it may succeed, depending
- on the policy in force before the Update operation.
- - LDAP Update (Replace), Other, LDAP Query
+ 1. If newSuperior is not present (ie. only the RDN is
+ being renamed) then permission "n" to entry is
+ required.
- The Query will show that the subject has all rights
- granted by the Update operation, and no rights not
- granted by the Update operation.
+ 2. If newSuperior is present then permission "e" to entry
+ and permission "i" to newSuperior are required.
- - LDAP Update (Grant), Other, LDAP Query
+If any of these permissions are not granted then the
+operation MUST fail. In this case, if discloseOnError is on
+then an "insufficient access error" is returned. Otherwise,
+"No such object" is returned.
- The Query will show that the subject has all rights
- granted by the Update operation. The Query may show
- that the subject also has other rights not granted
- by the Update operation, depending on the policy in
- force before the Update operation.
+If they are all granted then the operation MAY proceed.
- - LDAP Update (Deny), Other, LDAP Query
+Note A: We do not require any additional permissions in the
+case where deleteoldrdn is TRUE.
- The Query will show that the subject does not have
- any right denied by the Update operation. The Query
- may show that the subject has rights not denied by
- the Update operation, depending on the policy in
- force before the Update operation.
+Note B: These permissions allow the naming attribute of an
+entry (or entries) to be changed even though "o" and "w"
+permissions are not available on the entry. Distinguishing
+the permissions like this allows us to grant permissions for
+the ModifyDN operation, but not the Modify operation and
+vice versa.
- - LDAP Update (Replace), Other, LDAP Access Request
- The Request will succeed if it requires only rights
- granted to the requesting subject by the Update
- operation. The Request will fail with an access-
- denied exception if it requires any right not
- granted by the Update operation.
+5.7 Compare Operation
- - LDAP Update (Grant), Other, LDAP Access Request
+Recall that the parameters of the Compare operation per
+RFC2251 [LDAPv3] Section 4.10 are:
- The Request will succeed if it requires only rights
- granted to the requesting subject by the Update
- operation. The Request may succeed if it requires
- rights not granted by the Update operation,
- depending on the policy in force before the Update
- operation.
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+Then the permissions required by authzID that need to be
+evaluated are as follows:
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 22]
+ 1. permission "c" to the attribute in entry on which the
+ comparison is being made.
+If any of these permissions are not granted then the
+operation MUST fail. In this case, if discloseOnError is on
+then an "insufficient access error" is returned. Otherwise,
+"No such object" is returned.
+If they are all granted then the operation MAY proceed.
- Internet-Draft Access Control Model 5 October 1999
- - LDAP Update (Deny), Other, LDAP Access Request
+Stokes, et al Expires 14 January 2001 [Page 24]
+\f
- The Request will fail with an access-denied
- exception if it requires any right denied to the
- requesting subject by the Update operation. If the
- Request requires only rights which were not denied
- by the Update operation, it may succeed, depending
- on the policy in force before the Update operation.
- - LDAP Update (Replace), Datastore Policy Update, LDAP
- Query
- The result of the Query is not defined.
- - LDAP Update (Grant), Datastore Policy Update, LDAP
- Query
+Internet-Draft Access Control Model 14 July 2000
- The result of the Query is not defined.
- - LDAP Update (Deny), Datastore Policy Update, LDAP
- Query
- The result of the Query is not defined.
+5.8 Abandon Operation
- - LDAP Update (Replace), Datastore Policy Update, LDAP
- Access Request
+Recall that the parameters of the Abandon operation per
+RFC2251 [LDAPv3] Section 4.6 are:
- The result of the Access Request is not defined.
+ AbandonRequest ::= [APPLICATION 16] MessageID
- - LDAP Update (Grant), Datastore Policy Update, LDAP
- Access Request
+authzID always has the right to send an Abandon Operation
+for an operation he previously initiated.
- The result of the Access Request is not defined.
- - LDAP Update (Deny), Datastore Policy Update, LDAP
- Access Request
+5.9 Extended Operation
- The result of the Access Request is not defined.
+Recall that the parameters of the Extended operation per
+RFC2251 [LDA{v3] Section 4.12 are:
+ 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 implementor of the extended request.
- 8. Access Control Parameters for LDAP Controls & Extended
- Operations
- This section defines the parameters used in the access
+6. Required Permissions for Handling Aliases and References
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 23]
+Use of aliases and referrals are part of LDAPv3. However,
+neither is particularly well-defined. Alias
+objects/attributes are defined in RFC 2256 as derived from
+X.500, but LDAPv3 does not explicitly define its 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, section 7.11.1. Referrals and
+knowledge information are still under design in LDAPv3; they
+are defined in X.500, however, X.500 punts on 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 draft 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"
- Internet-Draft Access Control Model 5 October 1999
+Stokes, et al Expires 14 January 2001 [Page 25]
+\f
- control LDAP controls and extended operations in this
- document.
- targetDN specifies the initial directory entry in DN
- syntax on which the control or extended operation is
- performed.
+Internet-Draft Access Control Model 14 July 2000
- whichObject specifies whether the access control
- information (in the get effective rights control) which
- is retrieved is for the target directory entry (ENTRY) or
- the target directory entry and its subtree (SUBTREE).
- rightsFamily specifies the family of rights that will be
- retrieved for the get effective rights control or
- extended operation performed. A rights family has a
- defined set of rights.
- rightsList in the get effective rights control or
- extended operations response is of the form specified in
- the BNF for <rightsList>.
+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 seperate 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 draft.
- dnType speficies the type of subject security attribute.
- Defined types are access-id, group, and role.
- subjectDN is a LDAP string that defines the subject or
- value of the dnType. The subjectDN may be a DN or
- another string such as IPAddress (dotted-decimal string
- representation) on which access control is get/set. If
- the subject is an entry in the directory, then the syntax
- of the LDAP string is DN. Two well-known subjectDNs
- strings are defined
+6.2 Aliases
- - public - meaning public access for all users
+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.
- - this - meaning the user whose name matches the entry
- being accessed
+If alias de-referencing is required in the process of
+locating a target entry, no specifc permissions are
+necessary for alias de-referencing to 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 'aliasedObjectName' attribute.
+Requiring these permission closes the hole of discovery.
- 9. Access Control Information (ACI) Controls
+6.3 Referrals
- The access control information controls provide a way to
- manipulate access control information in conjunction with
- a LDAP operation. Two LDAP controls are defined. These
- controls allow access control information to be get/set
+If a referral is to be followed, no specifc 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 - only drafts). 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.
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 24]
+Stokes, et al Expires 14 January 2001 [Page 26]
+\f
- Internet-Draft Access Control Model 5 October 1999
+Internet-Draft Access Control Model 14 July 2000
- while manipulating other directory information for that
- entry. The controls are:
- - getEffectiveRights to obtain the effective rights
- for a given directory entry(s) for a given subject
- during a ldap_search operation
+7. Controlling Access to Access Control Information
- - specifyCredentials to specify a set of credentials
- for the bind identity (DN) during a ldap_bind
- operation
+The ldapACI attribute is used to specify control for who has
+permission to set/change access control information
+(ldapACI). The ldapACI attribute/OID is just another
+attribute described with a scope, set of rights and
+permissions, and subject as a value of the ldapACI
+attribute. (See the example in the "ACI Examples" section).
- 9.1 getEffectiveRights Control
+If the policy for controlling the ldapACI attribute is 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 ldapACI within the
+ldapACI attribute, then the server could simply assert that
+the 'root DN' is considered the policy owner (controller for
+controlling access control) for all objects.
- 9.1.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].
+8. ACI Examples
- 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:
+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.
- getEffectiveRightsRequest ::= SEQUENCE {
- effectiveRightsRequest SEQUENCE OF SEQUENCE {
- rightsFamily LDAPOID | "*",
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- },
- dnType "access-id"|"group"|"role"|"*",
- subjectDN LDAPString,
- }
- }
- The effectiveRightsRequest is a set of sequences that
- state the whichObject (entry or entry plus subtree) and
- specifics of the control request to be performed. One or
- more rightsFamily can be be obtained for a given
- subjectDN ad dnType. A "*" in the rightsFamily field
- indicates that the rights for all rights families defined
- for the subjectDN / dnType are to be returned. A "*" in
+8.1 Attribute Definition
+
+The following examples show the access required to control
+access to the ldapACI attribute. 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.
+
+ ldapACI: entry#grant:r,w#
+ OID.ldapACI#authnLevel:any:role:cn=aciAdmin
+
+ ldapACI: subtree#grant:r,w#
+ OID.ldapACI#authnLevel:any:role:cn=aciAdmin
+
+The next example shows a ldapACI 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.
+Authentication of a specified type is not required.
+
+ ldapACI:subtree#grant;r,s,c#
+ OID.attr1#group:cn=Dept XYZ,c=US
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 27]
+\f
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+The next example shows an ACI attribute where a role
+"cn=SysAdmins,o=Company" is being given permissions to add
+objects below this node and read, search, and compare
+attributes attr2 and attr3. The permission applies to the
+entire subtree below the node containing this ACI.
+
+ ldapACI: subtree#grant:a#
+ [entry]#role:cn=SysAdmins,o=Company
+
+ ldapACI: subtree#grant:r,s,c#
+ OID.attr2#role:cn=SysAdmins,o=Company
+
+ ldapACI: subtree#grant:r,s,c#
+ OID.attr3#role:cn=SysAdmins,o=Company
+
+
+8.2 Modifying the ldapACI 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 ldapACI value is replaced, all ldapACI values are
+replaced.
+
+A given ldapACI for an entry:
+
+ ldapACI: subtree#deny:r,w#[all]#group:cn=Dept ABC
+
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
+
+perform the following change:
+
+ dn: cn=someEntry
+ changetype: modify
+ replace: ldapACI
+ ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN
+
+The resulting ACI is:
+
+ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN
+
+( ldapACI 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 ldapACI value(s). If the
+ACI does exist, then add the specified values to the given
+ldapACI. For example a given ACI:
+
+ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 28]
+\f
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+with a modification:
+
+ dn: cn=someEntry
+ changetype: modify
+ add: ldapACI
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
+
+would yield an multi-valued ACI of:
+
+ ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
+
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
+
+To delete a particular ACI value, use the regular ldapmodify
+- delete syntax
+
+Given an ACI of:
+
+ ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
+
+ dn: cn = some Entry
+ changetype: modify
+ delete: ldapACI
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
+
+would yield a remaining ACI on the server of
+
+ldapACI: subtree#grant:r,w#[all]#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: ldapACI
+In this case, the entry would then inherit its ACI from some
+other node in the tree depending on the server inheritance
+model.
+Similarly, if all values of ldapACI are deleted, then the
+access control information for that entry is defined by that
+implementation's inheritance model.
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 25]
- Internet-Draft Access Control Model 5 October 1999
+Stokes, et al Expires 14 January 2001 [Page 29]
+\f
- the dnType field specifies that all DN types are to be
- used in returning the effective rights. This control is
- applied to the filter and scope set by the ldap_search
- operation, i.e. base, one-level, subtree.
- 9.1.2 Response Control
+Internet-Draft Access Control Model 14 July 2000
- 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>. The
- criticality MAY be either TRUE or FALSE (where absent is
- also equivalent to FALSE). 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)
- }
- }
+8.3 Evaluation
- The effective rights returned are returned with each
- entry returned by the search result. The control
- response for ldap_search is:
+These examples assume that the ldapACI 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.
+See section 10 for a discussion of the semantics of ldapACI
+entries when backing-store ACI administration is also used.
- PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE {
- rightFamily LDAPOID,
- rightsList LDAPString,
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- }
- dnType LDAPString
- subjectDN LDAPString
+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
+ ldapACI: subtree#grant:r#attr1
+ #authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US
+ ldapACI: subtree#grant:w#attr1
+ #group:cn=G1,ou=ABC,o=XYZ,c=US
+ What rights does cn=jsmith have to attr1 of o=XYZ,c=US?
+ Read (r) access; authzID is higher precedence than
+ group.
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 26]
+ Example #2
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:r#attr2
+ #group:cn=G1,ou=ABC,o=XYZ,c=US
+ ldapACI: subtree#grant:w#attr2
+ #group:cn=G2,ou=ABC,o=XYZ,c=US
+ What rights does cn=jsmith have to attr2 of o=XYZ,c=US?
+ Read-write (r,w) access; ACI is combined because both
+ subjects (group) have same precedence.
+ Example #3
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:r,w#attr3
+ #group:cn=G1,ou=ABC,o=XYZ,c=US
+ ldapACI: subtree#deny:w#attr3#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).
- Internet-Draft Access Control Model 5 October 1999
+ Example #4
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:w#attr4
+ #authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US
- }
- 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.
+Stokes, et al Expires 14 January 2001 [Page 30]
+\f
- 9.1.3 Client-Server Interaction
- The getEffectiveRightsRequest control requests the rights
- that MUST be in effect for requested directory
- entry/attribute based on the subject DN. The server that
- consumes the search operation looks up the rights for the
- returned directory information based on the subject DN
- and returns that rights information.
- There are six possible scenarios that may occur as a
- result of the getEffectiveRights control being included
- on the search request:
+Internet-Draft Access Control Model 14 July 2000
- 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 such as cannot process specified
- rightsFamily 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
+ ldapACI: subtree#grant:r#attr4#subtree:ou=ABC,ou=XYZ,c=US
+ What rights does cn=jsmith have to attr4 of o=XYZ, c=US?
+ Write (w); rights given to an authzID take precedence
+ over those given to a subtree.
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 27]
+ Example #5
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:m#OID.attr5
+ #authzID-dn:cn=jsmith,o=ABC,c=US
+ ldapACI: subtree#grant:m#OID.cn
+ #authzID-dn:cn=jsmith,o=ABC,c=US
+ ldapACI: subtree#grant:m#OID.sn
+ #authzID-dn:cn=jsmith,o=ABC,c=US
+ ldapACI: subtree#grant:a#[entry]
+ #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 #6
+ dn: c=US
+ ldapACI: subtree#grant:m#[all]#subtree:c=US
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:a#[entry]#
+ 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 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.
- Internet-Draft Access Control Model 5 October 1999
+9. Operational Semantics of Access Control Operations
+The semantics of access control operations described in this
+document are defined operationally in terms of "histories".
+A history is a sequence of actions (x1, x2, ..., xN).
- the searchResult message.
- 4. If the server supports this control but for some
- reason such as cannot process specified
- rightsFamily and the client specified FALSE for the
- control's criticality field, then the server should
- process as 'no rights returned for that family' 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 per the rightsFamily information, then
- it should include the getEffectiveRightsResponse
- control in the searchResult message with a result
- of success.
+Stokes, et al Expires 14 January 2001 [Page 31]
+\f
- 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.
+Internet-Draft Access Control Model 14 July 2000
- 9.2 specifyCredentials Control
- This control is used with the ldap_bind() operation to
- push credentials from the client to the server. A
- privilege attribute certificate is an example of a
+9.1 Types of actions
+We consider five types of actions:
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 28]
+ - LDAP Access Control Policy Update actions: invocations
+ of ldap modify when used to add, delete, or replace the
+ aci attribute; invocations of ldap add when used to add
+ an entry with an aci attribute. A LDAP Access Control
+ Policy Update action may replace the policy (by
+ completely replacing the aci attribute with new policy
+ information) or it may grant or deny specific rights
+ while leaving others unaffected.
+ - LDAP Access Control Policy Query operations:
+ invocations of ldap search when used to retrieve the
+ aci attribute; invocations of ldap search with the
+ getEffectiveRightsRequest control; invocations of the
+ ldapGetEffectiveRightsRequest extended operation.
+ - Datastore Access Control Policy Update Actions: any
+ operation implemented by the server which LDAP is using
+ as its datastore which changes the access policy
+ enforced with respect to attempts to access LDAP
+ directory entries and their attributes.
+ - LDAP Access Request operations: invocations of LDAP
+ entry or attribute access operations (Read, Update,
+ Search, Compare, etc...).
+ - Other operations: anything else, including Datastore
+ operations which do not change the access policy
+ enforced by the server.
- Internet-Draft Access Control Model 5 October 1999
+9.2 Semantics of Histories
+The semantics of histories are defined as follows:
+ - LDAP Update (Replace), LDAP Query
- credential that could be pushed from the client to the
- server.
+ The Query will show that the subject has all rights
+ granted by the Update operation, and no rights not
+ granted by the Update operation.
+ - LDAP Update (Grant), LDAP Query
- 9.2.1 Request Control
+ The Query will show that the subject has all rights
+ granted by the Update operation. The Query may show
+ that the subject also has other rights not granted by
+ the Update operation, depending on the policy in force
+ before the Update operation.
- This control is included in the ldap_bind 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:
- specifyCredentialRequest ::= SEQUENCE {
- credential LDAPString
- }
- }
+Stokes, et al Expires 14 January 2001 [Page 32]
+\f
- The credential specifies the credential (e.g. groups,
- roles, etc) that the client is requesting be associated
- with the bind DN for access control determination in
- subsequent ldap operations. This provides a 'push' model
- for credentials where the client attempts to 'push' the
- credential to the server. The server may process at bind
- time as follows:
- - server may unconditionally ignore
- - server may unconditionally accept
- - server may define trust model and evaluate of the
- trust of each credential
+Internet-Draft Access Control Model 14 July 2000
- If this control is not used, it is assumed that the
- server determines (pulls) the credentials associated with
- the bind DN when needed in subsequent ldap operations to
- provide access control.
- 9.2.2 Response Control
- This control is included in the ldap_bind message as part
- of the controls field of the LDAPMessage, as defined in
+ - LDAP Update (Deny), LDAP Query
+ The Query will show that the subject does not have any
+ right denied by the Update operation. The Query may
+ show that the subject has rights not denied by the
+ Update operation, depending on the policy in force
+ before the Update operation.
+ - LDAP Update (Replace), LDAP Access Request
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 29]
+ The Request will succeed if it requires only rights
+ granted to the requesting subject by the Update
+ operation. The Request will fail if it requires any
+ right not granted by the Update operation.
+ - LDAP Update (Grant), LDAP Access Request
+ The Request will succeed if it requires only rights
+ granted to the requesting subject by the Update
+ operation. The Request may succeed if it requires
+ rights not granted by the Update operation, depending
+ on the policy in force before the Update operation.
+ - LDAP Update (Deny), LDAP Access Request
+ The Request will fail if it requires any right denied
+ to the requesting subject by the Update operation. If
+ the Request requires only rights which were not denied
+ by the Update operation, it may succeed, depending on
+ the policy in force before the Update operation.
+ - LDAP Update (Replace), Other, LDAP Query
- Internet-Draft Access Control Model 5 October 1999
+ The Query will show that the subject has all rights
+ granted by the Update operation, and no rights not
+ granted by the Update operation.
+ - LDAP Update (Grant), Other, LDAP Query
+ The Query will show that the subject has all rights
+ granted by the Update operation. The Query may show
+ that the subject also has other rights not granted by
+ the Update operation, depending on the policy in force
+ before the Update operation.
- Section 4.1.12 of [LDAPv3].
+ - LDAP Update (Deny), Other, LDAP Query
- The controlType is set to <OID to be assigned>. The
- criticality MAY be either TRUE or FALSE (where absent is
- also equivalent to FALSE). The controlValue is an OCTET
- STRING, whose value is the BER encoding of a value of the
- following SEQUENCE:
+ The Query will show that the subject does not have any
+ right denied by the Update operation. The Query may
+ show that the subject has rights not denied by the
+ Update operation, depending on the policy in force
- specifyCredentialsResponse ::= {
- result ENUMERATED {
- success (0),
- operationsError (1),
- unavailableCriticalExtension (12),
- unavailable (52),
- unwillingToPerform (53),
- other (80)
- }
- }
- No data is returned; just the result is returned.
- Although this extends the bind operation, there are no
- incompatibilities between versions. LDAPv2 cannot send a
- control. A LDAPv3 client cannot send this request to a
- LDAPv2 server. A LDAPv3 server not supporting this
- control cannot return the additional data.
+Stokes, et al Expires 14 January 2001 [Page 33]
+\f
- 9.2.3 Client-Server Interaction
- The specifyCredentialsRequest control specifies the
- credentials that the client wants the server to use for
- access control in subsequent ldap operations. The server
- that consumes the bind operation may unconditionally
- accept, ignore, or evaluate the trust of the specified
- credentials at bind time and returns only a success or
- failure response (no data returned).
- There are six possible scenarios that may occur as a
- result of the specifyCredential control being included on
- the bind request:
+Internet-Draft Access Control Model 14 July 2000
- 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
+ before the Update operation.
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 30]
+ - LDAP Update (Replace), Other, LDAP Access Request
+ The Request will succeed if it requires only rights
+ granted to the requesting subject by the Update
+ operation. The Request will fail if it requires any
+ right not granted by the Update operation.
+ - LDAP Update (Grant), Other, LDAP Access Request
+ The Request will succeed if it requires only rights
+ granted to the requesting subject by the Update
+ operation. The Request may succeed if it requires
+ rights not granted by the Update operation, depending
+ on the policy in force before the Update operation.
+ - LDAP Update (Deny), Other, LDAP Access Request
+ The Request will fail if it requires any right denied
+ to the requesting subject by the Update operation. If
+ the Request requires only rights which were not denied
+ by the Update operation, it may succeed, depending on
+ the policy in force before the Update operation.
- Internet-Draft Access Control Model 5 October 1999
+ - LDAP Update (Replace), Datastore Policy Update, LDAP
+ Query
+ The result of the Query is not defined.
+ - LDAP Update (Grant), Datastore Policy Update, LDAP
+ Query
- unavailableCriticalExtension as a return code in
- the bindResponse message. This behavior is
- specified in section 4.1.12 of [LDAPv3].
+ The result of the Query is not defined.
- 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].
+ - LDAP Update (Deny), Datastore Policy Update, LDAP Query
- 3. If the server supports this control but for some
- reason such as cannot process specified credential
- (e.g. server decided to evaluate the trust of that
- credential and the result is the server not
- trusting all the credentials or unconditionally
- ignores the credential) 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 bindResult message and omit the
- specifyCredentialResponse control in the bindResult
- message.
+ The result of the Query is not defined.
- 4. If the server supports this control but for some
- reason such as cannot process specified credential
- (e.g. server decided to evaluate the trust of that
- credential and the result is the server not
- trusting all the credentials or unconditionally
- ignores the credential) and the client specified
- FALSE for the control's criticality field, then the
- server should process as 'credential ignored' and
- include the result Unavailable in the
- specifyCredentialResponse control in the bindResult
- message.
+ - LDAP Update (Replace), Datastore Policy Update, LDAP
+ Access Request
- 5. If the server supports this control and evaulates
- the trust of that credential and the result is the
- server trusting all the credentials, then it should
- include the specifyCredentialResponse control in
- the bindResult message with a result of success.
+ The result of the Access Request is not defined.
- 6. If the bind request failed for any other reason,
- then the server SHOULD omit the
- specifyCredentialResponse control from the
+ - LDAP Update (Grant), Datastore Policy Update, LDAP
+ Access Request
+ The result of the Access Request is not defined.
+ - LDAP Update (Deny), Datastore Policy Update, LDAP
+ Access Request
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 31]
+Stokes, et al Expires 14 January 2001 [Page 34]
+\f
- Internet-Draft Access Control Model 5 October 1999
+Internet-Draft Access Control Model 14 July 2000
- bindResult message.
+ The result of the Access Request is not defined.
- The client application is assured that the correct
- credentials are used by the server when specified by the
- client for subsequent ldap operations if and only if the
- specifyCredentialResponse is successful. If the server
- omits the specifyCredentialResponse control from the
- bindResponse message, the client SHOULD assume that the
- control was ignored by the server.
- The specifyCredentialResponse control, if included by the
- server in the bindResponse message, should have the
- bindResult set to either success if the credentials were
- accepted by the server or set to the appropriate error
- code as to why the credentials were not accepted.
+10. Access Control Parameters for LDAP Controls & Extended
+Operations
- 10. Access Control Extended Operation
+This section defines the parameters used in the access
+control LDAP controls and extended operations in this
+document.
- An extended operation, get effective rights, is defined
- to obtain the effective rights for a given directory
- entry for a given subject. This operation may help with
- the management of access control information independent
- of manipulating other directory information.
+targetDN specifies the initial directory entry in DN syntax
+on which the control or extended operation is performed.
+whichObject specifies whether the access control information
+(in the get effective rights control) which is retrieved is
+for the target directory entry (ENTRY) or the target
+directory entry and its subtree (SUBTREE).
- 10.1 LDAP Get Effective Rights Operation
+rights in the get effective rights control or extended
+operation response is of the form specified in the BNF for
+<rights>.
- ldapGetEffectiveRightsRequest ::= [APPLICATION 23]
- SEQUENCE {
- requestName [0] <OID to be assigned>,
- requestValue [1] OCTET STRING OPTIONAL }
+subject is a LDAP string that defines the subject. Access
+control is get/set on a subject. The syntax of the subject
+is the same as the subject field in the BNF.
- where
- requestValue ::= SEQUENCE {
- targetDN LDAPDN,
- updates SEQUENCE OF SEQUENCE {
- rightsFamily LDAPOID | "*",
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- },
- dnType LDAPOID | "*",
- subjectDN LDAPString,
+11. Access Control Information (ACI) Controls
+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 while
+manipulating other directory information for that entry.
+The control is:
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 32]
+ - getEffectiveRights to obtain the effective rights for a
+ given directory entry(s) for a given subject during a
+ ldap_search operation
+11.1 getEffectiveRights Control
+11.1.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].
- Internet-Draft Access Control Model 5 October 1999
+Stokes, et al Expires 14 January 2001 [Page 35]
+\f
- }
- }
- The requestName is a dotted-decimal representation of the
- OBJECT IDENTIFIER corresponding to the request. The
- requestValue is information in a form defined by that
- request, encapsulated inside an OCTET STRING.
- The server will respond to this with an LDAPMessage
- containing the ExtendedResponse which is a rights list.
+Internet-Draft Access Control Model 14 July 2000
- ldapGetEffectiveRightsResponse ::= [APPLICATION 24]
- SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] <OID to be assigned> OPTIONAL,
- effectiveRights [11] OCTET STRING OPTIONAL }
- where
- effectiveRights ::= SEQUENCE OF SEQUENCE {
- rightFamily LDAPOID,
- rightsList ENUMERATED,
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- },
- subjectDnType LDAPOID,
- subjectDN LDAPSTRING
- }
+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:
- If the server does not recognize the request name, it
- MUST return only the response fields from LDAPResult,
- containing the protocolError result code.
+ getEffectiveRightsRequest ::= SEQUENCE {
+ effectiveRightsRequest SEQUENCE OF SEQUENCE {
+ whichObject ENUMERATED {
+ LDAP_ENTRY (1),
+ LDAP_SUBTREE (2)
+ },
+ subject <see <subject > in BNF> | "*"
+ }
+ }
+The effectiveRightsRequest is a set of sequences that state
+the whichObject (entry or entry plus subtree) and specifics
+of the control request to be performed. A "*" in the subject
+field specifies that all DN types are to be used in
+returning the effective rights. This control is applied to
+the filter and scope set by the ldap_search operation, i.e.
+base, one-level, subtree. So the attributes/values returned
+are defined by the ldap_search operation.
+11.1.2 Response Control
- 11. Security Considerations
+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].
- This document proposes protocol elements for transmission
- of security policy information. Security considerations
- are discussed throughout this draft. Because subject
- security attribute information is used to evaluate
- decision requests, it is security-sensitive information
- and must be protected against unauthorized modification
+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)
+ }
+ }
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 36]
+\f
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+The effective rights returned are returned with each entry
+returned by the search result. The control response for
+ldap_search is:
+
+ PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE {
+ rights <see <rights> in BNF>,
+ whichObject ENUMERATED {
+ LDAP_ENTRY (1),
+ LDAP_SUBTREE (2)
+ },
+ subject < see <subject> in BNF >
+ }
+
+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.
+
+11.1.3 Client-Server Interaction
+
+The getEffectiveRightsRequest control requests the rights
+that MUST be in effect for requested directory
+entry/attribute based on the subject DN. The server that
+consumes the search operation looks up the rights for the
+returned directory information based on the subject DN and
+returns that rights information.
+
+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 such as cannot process specified family and the
+ client specified TRUE for the control's criticality
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 37]
+\f
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ 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 such as cannot process specified family and the
+ client specified FALSE for the control's criticality
+ field, then the server should process as 'no rights
+ returned for that family' 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 per the family 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.
+
+
+12. Access Control Extended Operation
+
+An extended operation, get effective rights, is defined to
+obtain the effective rights for a given directory entry for
+a given subject. This operation may help with the
+management of access control information independent of
+manipulating other directory information.
+
+
+
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 38]
+\f
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+12.1 LDAP Get Effective Rights Operation
+
+ldapGetEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE
+{
+ requestName [0] <OID to be assigned>,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ where
+
+ requestValue ::= SEQUENCE {
+ targetDN LDAPDN,
+ updates SEQUENCE OF SEQUENCE {
+ whichObject ENUMERATED {
+ LDAP_ENTRY (1),
+ LDAP_SUBTREE (2)
+ },
+ attr SEQUENCE {
+ attr <see <attr> in BNF >
+ },
+ subject < see <subject> in BNF > | "*"
+ }
+ }
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 33]
+The requestName is a dotted-decimal representation of the
+OBJECT IDENTIFIER corresponding to the request. The
+requestValue is information in a form defined by that
+request, encapsulated inside an OCTET STRING.
+The server will respond to this with an LDAPMessage
+containing the ExtendedResponse which is a rights list.
+ldapGetEffectiveRightsResponse ::= [APPLICATION 24] SEQUENCE
+{
+ COMPONENTS OF LDAPResult,
+ responseName [10] <OID to be assigned> OPTIONAL,
+ effectiveRights [11] OCTET STRING OPTIONAL }
+ where
+ effectiveRights ::= SEQUENCE OF SEQUENCE {
+ rights <see <rights> in BNF>,
+ whichObject ENUMERATED {
+ LDAP_ENTRY (1),
+ LDAP_SUBTREE (2)
+ },
+ subject < see <subject> in BNF >
+ }
+If the server does not recognize the request name, it MUST
+return only the response fields from LDAPResult, containing
- Internet-Draft Access Control Model 5 October 1999
+Stokes, et al Expires 14 January 2001 [Page 39]
+\f
- whenever it is stored or transmitted.
- 12. References
+Internet-Draft Access Control Model 14 July 2000
- [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight
- Directory Access Protocol (v3)", RFC 2251, December 1997.
- [ECMA] ECMA, "Security in Open Systems: A Security
- Framework" ECMA TR/46, July 1988
- [REQTS] Stokes, Byrne, Blakley, "Access Control
- Requirements for LDAP, INTERNET-DRAFT <draft-ietf-
- ldapext-acl-reqts-02.txt>, August 1998.
+the protocolError result code.
- [ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille,
- "Lightweight Directory Access Protocol (v3)": Attribute
- Syntax Definitions, RFC 2252, December 1997.
- [UTF] M. Wahl, S. Kille, "Lightweight Directory Access
- Protocol (v3)": A UTF-8 String Representation of
- Distinguished Names", RFC 2253, December 1997.
- [Bradner97] Bradner, Scott, "Key Words for use in RFCs to
- Indicate Requirement Levels", RFC 2119.
+13. Security Considerations
+This document proposes protocol elements for transmission of
+security policy information. Security considerations are
+discussed throughout this draft. 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.
- AUTHOR(S) ADDRESS
+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.
- Ellen Stokes Bob Blakley
- IBM Dascom
- 11400 Burnet Rd 5515 Balcones Drive
- Austin, TX 78758 Austin, TX 78731
- USA USA
- mail-to: stokes@austin.ibm.com mail-to: blakley@dascom.com
- phone: +1 512 838 3725 phone: +1 512 458 4037 ext 5012
- fax: +1 512 838 8597 fax: +1 512 458 237
- Debbie Byrne
- IBM
- 11400 Burnet Rd
- Austin, TX 78758
- USA
+14. References
+[LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory
+Access Protocol (v3)", RFC 2251, December 1997.
+[ECMA] ECMA, "Security in Open Systems: A Security
+Framework" ECMA TR/46, July 1988.
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 34]
+[REQTS] Stokes, Byrne, Blakley, "Access Control Requirements
+for LDAP", RFC 2820, May 2000.
+[ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight
+Directory Access Protocol (v3)": Attribute Syntax
+Definitions, RFC 2252, December 1997.
+[UTF] M. Wahl, S. Kille, "Lightweight Directory Access
+Protocol (v3)": A UTF-8 String Representation of
+Distinguished Names", RFC 2253, December 1997.
+[Bradner97] Bradner, Scott, "Key Words for use in RFCs to
+Indicate Requirement Levels", RFC 2119.
+[AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R.
+Morgan, "Authentication Methods for LDAP", RFC 2829, May
+2000.
+[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax
+Specifications: ABNF", RFC 2234, November 1997.
- Internet-Draft Access Control Model 5 October 1999
+Stokes, et al Expires 14 January 2001 [Page 40]
+\f
- mail-to: djbyrne@us.ibm.com
- phone: +1 512 838 1960
- fax: +1 512 838 8597
+Internet-Draft Access Control Model 14 July 2000
+ACKNOWLEDGEMENT
+This is to acknowledge the numerous companies and individuals who have
+contributed their valuable help and insights to the development of this
+specification.
+AUTHOR(S) ADDRESS
+ Ellen Stokes Bob Blakley
+ Tivoli Systems Tivoli Systems
+ 6300 Bridgepoint Parkway 6300 Bridgepoint Parkway
+ Austin, TX 78731 Austin, TX 78731
+ 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 1199 fax: +1 512 436 1199
+ Debbie Rinkevich Robert Byrne
+ IBM Sun Microsystems
+ 11400 Burnet Rd 29 Chemin du Vieux Chene
+ Austin, TX 78758 Meylan ZIRST 38240
+ USA France
+ mail-to: djbrink@us.ibm.com mail-to: rbyrne@france.sun.com
+ phone: +1 512 838 1960 phone: +33 (0)4 76 41 42 05
+ fax: +1 512 838 8597
+Stokes, et al Expires 14 January 2001 [Page 41]
+\f
+Internet-Draft Access Control Model 14 July 2000
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 35]
- Internet-Draft Access Control Model 5 October 1999
+Stokes, et al Expires 14 January 2001 [Page 42]
+\f
- Stokes, Byrne, Blakley Expires 5 April 2000 [Page 36]
+ CONTENTS
+ 1. Introduction....................................... 2
+ 2. The LDAPv3 Access Control Model.................... 2
- CONTENTS
+ 3. Access Control Mechanism Attributes................ 5
+ 3.1 Root DSE Attribute for Access Control
+ Mechanism.................................... 5
+ 3.2 Root DSE Attribute for Control of Disclosing
+ Errors....................................... 5
+ 3.3 Subentry Class Access Control Mechanism...... 6
+ 4. The Access Control Information Attribute
+ (ldapACI).......................................... 7
+ 4.1 The BNF...................................... 8
+ 4.1.1 ACI String Representation 8
+ 4.1.2 ACI Binary Representation 10
+ 4.2 The Components of ldapACI Attribute.......... 11
+ 4.2.1 Scope 11
+ 4.2.2 Access Rights and Permissions 11
+ 4.2.3 Attributes 14
+ 4.2.4 Subjects and Associated
+ Authentication 15
+ 4.3 Grant/Deny Evaluation Rules.................. 15
- 1. Introduction....................................... 2
+ 5. Required Permissions for each LDAP Operation....... 17
+ 5.1 Bind Operation............................... 18
+ 5.2 Search Operation............................. 18
+ 5.3 Modify Operation............................. 21
+ 5.4 Add Operation................................ 22
+ 5.5 Delete Operation............................. 23
+ 5.6 Modify DN Operation.......................... 23
+ 5.7 Compare Operation............................ 24
+ 5.8 Abandon Operation............................ 25
+ 5.9 Extended Operation........................... 25
- 2. Overview........................................... 2
+ 6. Required Permissions for Handling Aliases and
+ References......................................... 25
+ 6.1 ACI Distribution............................. 25
+ 6.2 Aliases...................................... 26
+ 6.3 Referrals.................................... 26
- 3. Terminology........................................ 3
+ 7. Controlling Access to Access Control
+ Information........................................ 27
- 4. The Model.......................................... 5
- 4.1 Access Control Information Model............. 6
- 4.2 Bind and Credentials......................... 8
+ 8. ACI Examples....................................... 27
+ 8.1 Attribute Definition......................... 27
+ 8.2 Modifying the ldapACI Values................. 28
+ 8.3 Evaluation................................... 30
- 5. Access Control Mechanism Attributes................ 8
- 5.1 Root DSE Attribute for Access Control
- Mechanism.................................... 8
- 5.2 Subschema Attribute for Access Control
- Mechanism.................................... 9
- 6. Access Control Information Attributes.............. 9
- 6.1 The BNF...................................... 10
- 6.2 Other Defined Parameters..................... 11
- 6.2.1 Rights Families and Rights 12
- 6.2.2 DN Types 14
- 6.3 Basic ACI Attribute (aCI).................... 14
- 6.3.1 LDAP Operations 16
- 6.4 ACI Examples................................. 16
- 6.4.1 Attribute Definition 16
- 6.4.2 Modifying the ACI Values 17
- 6.5 Vendor ACI Attribute (vendorAci)............. 19
- 6.6 Policy Owner Attribute (policyOwner)......... 19
- 7. Operational Semantics of Access Control
- Operations......................................... 20
- 7.1 Types of actions............................. 20
- 7.2 Semantics of Histories....................... 21
+ - i -
- 8. Access Control Parameters for LDAP Controls &
- Extended Operations................................ 23
- 9. Access Control Information (ACI) Controls.......... 24
- 9.1 getEffectiveRights Control................... 25
- 9.1.1 Request Control 25
- 9.1.2 Response Control 26
- 9.1.3 Client-Server Interaction 27
- - i -
+ 9. Operational Semantics of Access Control
+ Operations......................................... 31
+ 9.1 Types of actions............................. 32
+ 9.2 Semantics of Histories....................... 32
+10. Access Control Parameters for LDAP Controls &
+ Extended Operations................................ 35
+11. Access Control Information (ACI) Controls.......... 35
+ 11.1 getEffectiveRights Control................... 35
+ 11.1.1 Request Control 35
+ 11.1.2 Response Control 36
+ 11.1.3 Client-Server Interaction 37
+12. Access Control Extended Operation.................. 38
+ 12.1 LDAP Get Effective Rights Operation.......... 39
+13. Security Considerations............................ 40
- 9.2 specifyCredentials Control................... 28
- 9.2.1 Request Control 29
- 9.2.2 Response Control 29
- 9.2.3 Client-Server Interaction 30
+14. References......................................... 40
- 10. Access Control Extended Operation.................. 32
- 10.1 LDAP Get Effective Rights Operation.......... 32
- 11. Security Considerations............................ 33
- 12. References......................................... 34
+ - ii -
- - 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.
- Full Copyright Statement
- Copyright (C) The Internet Society (1999).á 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 -
+ - iii -
projects / openldap / blobdiff