INTERNET-DRAFT S. Legg draft-legg-ldap-acm-bac-00.txt Adacel Technologies Intended Category: Standards Track February 22, 2002 Basic and Simplified Access Control in LDAP Copyright (C) The Internet Society (2002). All Rights Reserved. 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. Distribution of this document is unlimited. Comments should be sent to the LDUP working group mailing list or to the author. This Internet-Draft expires on 22 August 2002. 1. Abstract An access control scheme describes the means by which access to directory information and potentially to access rights themselves may be controlled. This document adapts the X.500 directory Basic Access Control and Simplied Access Control schemes for use by the Lightweight Directory Access Protocol. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Legg Expires 22 August 2002 [Page 1] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Table of Contents 1. Abstract .................................................... 1 2. Table of Contents ........................................... 2 3. Introduction ................................................ 3 4. Basic Access Control ........................................ 4 4.1 Permissions ............................................. 5 4.1.1 Read ............................................... 5 4.1.2 Compare ............................................ 6 4.1.3 Browse ............................................. 6 4.1.4 ReturnDN ........................................... 6 4.1.5 FilterMatch ........................................ 6 4.1.6 Modify ............................................. 6 4.1.7 Add ................................................ 7 4.1.8 Remove ............................................. 7 4.1.9 DiscloseOnError .................................... 7 4.1.10 Rename ............................................ 7 4.1.11 Export ............................................ 8 4.1.12 Import ............................................ 8 4.1.13 Invoke ............................................ 8 4.2 Representation of Access Control Information ............ 8 4.2.1 Identification Tag ................................. 11 4.2.2 Precedence ......................................... 11 4.2.3 Authentication Level ............................... 12 4.2.4 itemFirst and userFirst Components ................. 13 4.2.5 Determining Group Membership ....................... 16 4.3 ACI Operational Attributes .............................. 17 4.3.1 Prescriptive ACI ................................... 17 4.3.2 Entry ACI .......................................... 18 4.3.3 Subentry ACI ....................................... 18 4.3.4 Protecting the ACI ................................. 18 4.4 Access Control Decision Points for LDAP Operations ...... 19 4.4.1 Common Elements of Procedure ....................... 19 4.4.1.1 Alias Dereferencing ........................... 19 4.4.1.2 Return of Names in Errors ..................... 20 4.4.1.3 Non-disclosure of the Existence of an Entry ... 20 4.4.2 Compare Operation Decision Points .................. 21 4.4.3 Search Operation Decision Points ................... 21 4.4.4 Add Operation Decision Points ...................... 24 4.4.5 Delete Operation Decision Points ................... 24 4.4.6 Modify Operation Decision Points ................... 25 4.4.7 Modify DN Operation Decision Points ................ 26 4.5 Access Control Decision Function ........................ 27 4.5.1 Inputs ............................................. 27 4.5.2 Tuples ............................................. 27 Legg Expires 22 August 2002 [Page 2] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 4.5.3 Discarding Irrelevant Tuples ....................... 28 4.5.4 Highest Precedence and Specificity ................. 28 5. Simplified Access Control ................................... 29 6. Security Considerations ..................................... 30 7. Acknowledgements ............................................ 30 8. Normative References ........................................ 30 9. Informative References ...................................... 31 10. Intellectual Property Notice ............................... 31 11. Copyright Notice ........................................... 32 12. Author's Address ........................................... 32 Appendix A. Native LDAP Encoding for the ACI Item Syntax ....... 33 3. Introduction An access control scheme describes the means by which access to directory information and potentially to access rights themselves may be controlled. Control of access to information means the prevention of unauthorized detection, disclosure, or modification of that information. The definition of an access control scheme in the context of an LDAP directory includes methods to specify Access Control Information (ACI), and to enforce access rights defined by that ACI. This document adapts the X.500 Basic Access Control and Simplied Access Control schemes [X501] for use by the Lightweight Directory Access Protocol (LDAP) [RFC2251]. Both schemes conform to, and make use of, the access control administrative framework described in [ADMIN]. Section 4 describes the Basic Access Control scheme and defines how it applies to LDAP operations. Simplified Access Control is a functional subset of the Basic Access Control scheme. This subset is described in Section 5. As a matter of security policy, an implementation supporting Basic Access Control or Simplified Access Control is permitted to grant or deny any form of access to particular attributes (e.g. password attributes) irrespective of access controls which may otherwise apply. However, since such security policy has no standardized representation, it cannot be propagated in replicated information. Schema definitions are provided using LDAP description formats [RFC2252]. Note that the LDAP descriptions have been rendered with additional white-space and line breaks for the sake of readability. This document is derived from, and duplicates substantial portions Legg Expires 22 August 2002 [Page 3] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 of, Section 8 of [X501], and selected extracts from [X511]. 4. Basic Access Control This section describes the functionality of the Basic Access Control scheme. When Basic Access Control is used, the accessControlScheme operational attribute [ADMIN] SHALL have the value basic-access-control (2.5.28.1). This LDAP profile for Basic Access Control defines, for every LDAP operation, one or more points at which access control decisions take place. An access control decision will involve a requestor, protected items and permissions. A requestor is the user requesting the operation. Basic Access Control requires a user's authorization identity to be represented as a distinguished name (with an optional unique identifier). The mapping of the authentication identity to an authorization identity, and the mapping of the authorization identity to a distinguished name and optional unique identifier, are outside the scope of this document. A protected item is the element of directory information being accessed. The protected items are entries, attributes, attribute values and distinguished names. Access to each protected item can be separately controlled through ACI. A permission is a particular right necessary to complete a portion of the operation. The Access Control Information, which is used to make access control decisions, associates protected items and user classes with permissions. ACI is represented in the directory as values of operational attributes with the ACI Item syntax [RFC2252]. Each such value is referred to as an ACI item. The scope of access controls can be a single entry or a collection of entries that are logically related by being within the scope of an access control subentry of an administrative point (see [ADMIN]). The Access Control Decision Function (ACDF) (Section 4.5) is used to decide whether a particular requestor has a particular access right by virtue of applicable ACI items. Access to DSEs and operational attributes is controlled in the same Legg Expires 22 August 2002 [Page 4] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 way as for entries and user attributes. For query purposes, collective attributes [COLLECT] that are associated with an entry are protected precisely as if they were attributes actually stored in that entry. For the purposes of modification, collective attributes are associated with the subentry that holds them, not with entries within the scope of the subentry. Modify-related access controls are therefore not relevant to collective attributes, except when they apply to the collective attribute and its values within the subentry. 4.1 Permissions Access is controlled by granting or denying permissions. Access is allowed only when there is an explicitly provided grant present in the ACI used to make the access control decision. The only default access decision provided in the model is to deny access in the absence of explicit ACI that grants access. All other factors being equal, a denial specified in ACI always overrides a grant. Certain combinations of grants or denials are illogical, but it is the responsibility of directory clients, rather than the directory server, to ensure that such combinations are absent. The decision whether or not to permit access to an entry or its contents is strictly determined by the position of the entry in the Directory Information Tree (DIT), in terms of its distinguished name, and is independent of how the directory server locates that entry. The following sections introduce the permissions by indicating the intent associated with the granting of each. The actual influence of a particular granted permission on access control decisions are, however, determined by the ACDF and the access control decision points for each LDAP operation, described in detail in Section 4.4. 4.1.1 Read If granted for an entry, Read permits the entry to be accessed using LDAP Compare and baseObject Search operations, but does not imply access to all the attributes and values. If granted for an attribute type, Read permits the attribute type to be returned as entry information in a Search result. Read or Browse permission for the entry is a prerequisite. Legg Expires 22 August 2002 [Page 5] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 If granted for an attribute value, Read permits the attribute value to be returned as entry information in a Search result. Read or Browse permission for the entry and Read permission for the attribute type are prerequisites. 4.1.2 Compare If granted for an attribute type, Compare permits the attribute type to be tested by the assertion in an LDAP Compare operation. Read permission for the entry is a prerequisite. If granted for an attribute value, Compare permits the value to be tested by the assertion in an LDAP Compare operation. Read permission for the entry and Compare permission for the attribute type are prerequisites. 4.1.3 Browse If granted for an entry, Browse permits the entry to be accessed by the LDAP Search operation, including baseObject searches, but does not imply access to all the attributes and values. 4.1.4 ReturnDN If granted for an entry, ReturnDN allows the distinguished name of the entry to be disclosed in a search result. 4.1.5 FilterMatch If granted for an attribute type, Filtermatch permits the attribute type to satisfy a Filter item. If granted for an attribute value, Filtermatch permits the attribute value to satisfy a Filter item. FilterMatch permission for the attribute type is a prerequisite. 4.1.6 Modify If granted for an entry, Modify permits the information contained within an entry to be modified by the LDAP Modify operation, subject to controls on the attribute types and values. Legg Expires 22 August 2002 [Page 6] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 4.1.7 Add If granted for an entry, Add permits creation of an entry in the DIT, subject to being able to add all specified attributes and attribute values. Add permission granted for an entry is ineffective if Add permission is not also granted for at least the mandatory attributes and their values. There is no specific "add subordinate permission". Permission to add an entry is controlled using prescriptive ACI. If granted for an attribute type, Add permits adding a new attribute, subject to being able to add all specified attribute values. Add or Modify permission for the entry is a prerequisite. If granted for an attribute value, Add permits adding that value to an existing attribute. Add or Modify permission for the entry is a prerequisite. 4.1.8 Remove If granted for an entry, Remove permits the entry to be removed from the DIT regardless of controls on attributes or attribute values within the entry. If granted for an attribute, Remove permits removing an attribute, subject to being able to remove any explicitly specified attribute values. Remove permission for values not explicitly specified is not required. If granted for an attribute value, Remove permits the attribute value to be removed from an existing attribute. 4.1.9 DiscloseOnError If granted for an entry, DiscloseOnError permits the name of an entry to be disclosed in an error result. If granted for an attribute, DiscloseOnError permits the presence of the attribute to be disclosed by an error. If granted for an attribute value, DiscloseOnError permits the presence of the attribute value to be disclosed by an error. 4.1.10 Rename If granted for an entry, Rename permits an entry to be renamed with a Legg Expires 22 August 2002 [Page 7] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 new RDN. No permissions are required for the attributes and values altered by the operation, even if they are added or removed as a result of the changes to the RDN. 4.1.11 Export If granted for an entry, Export permits the entry and its subordinates, if any, to be removed from the current location and placed in a new location, subject to the granting of Import permission at the destination. If the last RDN is changed, Rename permission at the current location is also required 4.1.12 Import If granted for an entry, Import permits an entry and its subordinates, if any, to be placed at the location to which the permission applies, subject to the granting of Export permission at the source location. 4.1.13 Invoke Invoke, if granted for an operational attribute, or value thereof, permits the directory server to carry out some function associated with the operational attribute on behalf of the user. The specific function carried out by invocation depends on the attribute. No other permissions are required by user for the operational attribute, or on the entry/subentry that holds it, in order for it to be "invoked". 4.2 Representation of Access Control Information Access Control Information is represented as a set of ACI items, where each ACI item grants or denies permissions in regard to certain specified users and protected items. An ACI item is represented as a value of an operational attribute with the ACI Item syntax (1.3.6.1.4.1.1466.115.121.1.1) [RFC2252]. This document updates [RFC2252] by specifying a human-readable native LDAP encoding for ACI items. The native LDAP encoding of values of the ACI Item syntax is defined by the Generic String Encoding Rules described in Section 8 of [CMR]. Appendix A provides an equivalent Legg Expires 22 August 2002 [Page 8] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 ABNF for this syntax. For convenience in specifying access control policies, the ACI Item syntax provides the means to identify collections of related items, such as attributes in an entry or all attribute values of a given attribute, and to specify a common protection for them. The ACI Item syntax corresponds to the ACIItem ASN.1 type defined in [X501]. It is reproduced here for convenience: ACIItem ::= SEQUENCE { identificationTag DirectoryString { ub-tag }, precedence Precedence, authenticationLevel AuthenticationLevel, itemOrUserFirst CHOICE { itemFirst [0] SEQUENCE { protectedItems ProtectedItems, itemPermissions SET OF ItemPermission }, userFirst [1] SEQUENCE { userClasses UserClasses, userPermissions SET OF UserPermission } } } Precedence ::= INTEGER (0..255) ProtectedItems ::= SEQUENCE { entry [0] NULL OPTIONAL, allUserAttributeTypes [1] NULL OPTIONAL, attributeType [2] SET SIZE (1..MAX) OF AttributeType OPTIONAL, allAttributeValues [3] SET SIZE (1..MAX) OF AttributeType OPTIONAL, allUserAttributeTypesAndValues [4] NULL OPTIONAL, attributeValue [5] SET SIZE (1..MAX) OF AttributeTypeAndValue OPTIONAL, selfValue [6] SET SIZE (1..MAX) OF AttributeType OPTIONAL, rangeOfValues [7] Filter OPTIONAL, maxValueCount [8] SET SIZE (1..MAX) OF MaxValueCount OPTIONAL, maxImmSub [9] INTEGER OPTIONAL, restrictedBy [10] SET SIZE (1..MAX) OF RestrictedValue OPTIONAL, contexts [11] SET SIZE (1..MAX) OF ContextAssertion OPTIONAL, classes [12] Refinement OPTIONAL } MaxValueCount ::= SEQUENCE { type AttributeType, Legg Expires 22 August 2002 [Page 9] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 maxCount INTEGER } RestrictedValue ::= SEQUENCE { type AttributeType, valuesIn AttributeType } UserClasses ::= SEQUENCE { allUsers [0] NULL OPTIONAL, thisEntry [1] NULL OPTIONAL, name [2] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL, userGroup [3] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL, -- dn component shall be the name of an -- entry of GroupOfUniqueNames subtree [4] SET SIZE (1..MAX) OF SubtreeSpecification OPTIONAL } NameAndOptionalUID ::= SEQUENCE { dn DistinguishedName, uid UniqueIdentifier OPTIONAL } UniqueIdentifier ::= BIT STRING ItemPermission ::= SEQUENCE { precedence Precedence OPTIONAL, -- defaults to precedence in ACIItem userClasses UserClasses, grantsAndDenials GrantsAndDenials } UserPermission ::= SEQUENCE { precedence Precedence OPTIONAL, -- defaults to precedence in ACIItem protectedItems ProtectedItems, grantsAndDenials GrantsAndDenials } AuthenticationLevel ::= CHOICE { basicLevels SEQUENCE { level ENUMERATED { none(0), simple(1), strong(2) }, localQualifier INTEGER OPTIONAL, signed BOOLEAN DEFAULT FALSE }, other EXTERNAL } GrantsAndDenials ::= BIT STRING { -- permissions that may be used in conjunction -- with any component of ProtectedItems grantAdd (0), denyAdd (1), grantDiscloseOnError (2), denyDiscloseOnError (3), Legg Expires 22 August 2002 [Page 10] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 grantRead (4), denyRead (5), grantRemove (6), denyRemove (7), -- permissions that may be used only in conjunction -- with the entry component grantBrowse (8), denyBrowse (9), grantExport (10), denyExport (11), grantImport (12), denyImport (13), grantModify (14), denyModify (15), grantRename (16), denyRename (17), grantReturnDN (18), denyReturnDN (19), -- permissions that may be used in conjunction -- with any component, except entry, of ProtectedItems grantCompare (20), denyCompare (21), grantFilterMatch (22), denyFilterMatch (23), grantInvoke (24), denyInvoke (25) } AttributeTypeAndValue ::= SEQUENCE { type ATTRIBUTE.&id ({SupportedAttributes}), value ATTRIBUTE.&Type ({SupportedAttributes}{@type}) } The SubtreeSpecification and Refinement ASN.1 types are defined in [X501], and separately described in [SUBENTRY]. The following sections describe the components of ACIItem. 4.2.1 Identification Tag identificationTag is used to identify a particular ACI item. This is used to discriminate among individual ACI items for the purposes of protection and administration. 4.2.2 Precedence Precedence is used to control the relative order in which ACI items are considered during the course of making an access control decision Legg Expires 22 August 2002 [Page 11] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 using the ACDF. ACI items having higher precedence values prevail over others with lower precedence values, other factors being equal. Precedence values are integers and are compared as such. 4.2.3 Authentication Level AuthenticationLevel defines the minimum requestor authentication level required for this ACI item. It has two forms: 1) basicLevels: which indicates the level of authentication, optionally qualified by positive or negative integer localQualifier. 2) other: an externally defined measure. When basicLevels is used, an AuthenticationLevel consisting of a level and optional localQualifier SHALL be assigned to the requestor by the directory server according to local policy. For a requestor's authentication level to meet or exceed the minimum requirement, the requestor's level must meet or exceed that specified in the ACI item, and in addition the requestor's localQualifier must be arithmetically greater than or equal to that of the ACI item. Strong authentication of the requestor is considered to exceed a requirement for simple or no authentication, and simple authentication exceeds a requirement for no authentication. For access control purposes, the "simple" authentication level requires at least a password; the case of identification only, with no password supplied, is considered "none". If a localQualifier is not specified in the ACI item, then the requestor need not have a corresponding value (if such a value is present it is ignored). The signed component of basicLevels is ignored for LDAP. When other is used, an appropriate AuthenticationLevel shall be assigned to the requestor by the directory server according to local policy. The form of this AuthenticationLevel and the method by which it is compared with the AuthenticationLevel in the ACI is a local matter. An authentication level associated with an explicit grant indicates the minimum level to which a requestor shall be authenticated in order to be granted access. An authentication level associated with an explicit deny indicates the minimum level to which a requestor shall be authenticated in order not to be denied access. For example, an ACI item that denies access to a particular user class and requires strong authentication Legg Expires 22 August 2002 [Page 12] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 will deny access to all requestors who cannot prove, by means of a strongly authenticated identity, that they are not in that user class. The directory server may base authentication level on factors other than values received in protocol exchanges. 4.2.4 itemFirst and userFirst Components Each ACI item contains a choice of itemFirst or userFirst. The choice allows grouping of permissions depending on whether they are most conveniently grouped by user classes or by protected items. The itemFirst and userFirst components are equivalent in the sense that they capture the same access control information; however, they organize that information differently. The choice between them is based on administrative convenience. The subcomponents of itemFirst and userFirst are described below. a) ProtectedItems defines the items to which the specified access controls apply. It is defined as a set selected from the following: - entry means the entry contents as a whole. It does not necessarily include the information in these entries. This element SHALL be ignored if the classes component is present, since this latter element selects protected entries on the basis of their object class. - allUserAttributeTypes means all user attribute type information associated with the entry, but not values associated with those attributes. - allUserAttributeTypesAndValues means all user attribute information associated with the entry, including all values of all user attributes. The allUserAttributeTypes and allUserAttributeTypesAndValues components do not include operational attributes, which MUST be specified on a per attribute basis, using attributeType, allAttributeValues or attributeValue. - attributeType means attribute type information pertaining to specific attributes but not values associated with the type. - allAttributeValues means all attribute value information pertaining to specific attributes. Legg Expires 22 August 2002 [Page 13] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 - attributeValue means specific values of specific attribute types. - selfValue means the attribute values of the specified attribute types that match the distinguished name (and unique identifier) of the requestor. It can only apply in the specific case where the attribute specified is of DN syntax (1.3.6.1.4.1.1466.115.121.1.12) or Name And Optional UID syntax (1.3.6.1.4.1.1466.115.121.1.34). - rangeOfValues means any attribute value which matches the specified filter, i.e. for which the specified filter evaluated on that attribute value would return TRUE. The filter is not evaluated on any entries in the DIB, rather it is evaluated using the semantics defined in 7.8 of [X511], operating on a fictitious entry that contains only the single attribute value which is the protected item. Note that the filter is an X.500 search Filter. It has a different syntax from the LDAP search Filter, but the same semantics. The following items provide constraints that may disable the granting of certain permissions to protected items in the same value of ProtectedItems: - maxValueCount restricts the maximum number of attribute values allowed for a specified attribute type. It is examined if the protected item is an attribute value of the specified type and the permission sought is Add. Values of that attribute in the entry are counted, without regard to attribute options and access control, as though the operation which is attempting to add the values is successful. If the number of values in the attribute exceeds maxCount, the ACI item is treated as not granting Add permission. - maxImmSub restricts the maximum number of immediate subordinates of the superior entry to an entry being added or imported. It is examined if the protected item is an entry, the permission sought is Add or Import, and the immediate superior entry is in the same server as the entry being added or imported. Immediate subordinates of the superior entry are counted, without regard to access control, as though the entry addition or importing is successful. If the number of subordinates exceeds maxImmSub, the ACI item is treated as not granting Add or Import permission. - restrictedBy restricts values added to the attribute type to being values that are already present in the same entry as values of the attribute identified by the valuesIn component. Legg Expires 22 August 2002 [Page 14] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 It is examined if the protected item is an attribute value of the specified type and the permission sought is Add. Values of the valuesIn attribute are checked, without regard to attribute options and access control, as though the operation which adds the values is successful. If the value to be added is not present in valuesIn the ACI item is treated as not granting Add permission. - contexts is not used in this version of the LDAP profile for Basic Access Control. - classes means the contents of entries that have object class values that satisfy the predicate defined by Refinement (see [SUBENTRY]). b) UserClasses defines a set of zero or more users the permissions apply to. The set of users is selected from the following: - allUsers means every directory user (with possible requirements for AuthenticationLevel). - thisEntry means the user with the same distinguished name as the entry being accessed. - name is the set of users with the specified distinguished names (each with an optional unique identifier). - userGroup is the set of users who are members of the groups (i.e. groupOfNames or groupOfUniqueNames entries [RFC2256]) identified by the specified distinguished names (each with an optional unique identifier). Members of a group of unique names are treated as individual user distinguished names, and not as the names of other groups of unique names. How group membership is determined is described in 4.2.5. - subtree is the set of users whose distinguished names fall within the scope of the unrefined subtrees (specificationFilter components SHOULD NOT be used - they are ignored if present). c) SubtreeSpecification is used to specify a subtree relative to the root DSE, and is not constrained by administrative areas. The specificationFilter component SHOULD NOT be used. It is ignored if present. A subtree refinement is not allowed because membership in a subtree whose specification includes only base and/or a ChopSpecification can be evaluated in isolation, whereas membership in a subtree definition using specificationFilter can Legg Expires 22 August 2002 [Page 15] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 only be evaluated by obtaining information from the user's entry, which is potentially in another directory server. Basic Access Control is designed to avoid remote operations in the course of making an access control decision. d) ItemPermission contains a collection of users and their permissions with respect to ProtectedItems within an itemFirst specification. The permissions are specified in grantsAndDenials as discussed in item f). Each of the permissions specified in grantsAndDenials is considered to have the precedence level specified in precedence for the purpose of the ACDF. If precedence is omitted within ItemPermission, then precedence is taken from the precedence specified for ACIItem. e) UserPermission contains a collection of protected items and the associated permissions with respect to userClasses within a userFirst specification. The associated permissions are specified in grantsAndDenials as discussed in item f). Each of the permissions specified in grantsAndDenials is considered to have the precedence level specified in precedence for the purpose of the ACDF. If precedence is omitted within UserPermission, the precedence is taken from the precedence specified for ACIItem. f) GrantsAndDenials specify the access rights that are granted or denied by the ACI item. g) UniqueIdentifier may be used by the authentication mechanism to distinguish between instances of distinguished name reuse. If this component is present, then for a requestor's name to match the UserClasses of an ACIItem that grants permissions, in addition to the requirement that the requestor's distinguished name match the specified distinguished name, the authentication of the requestor shall yield an associated unique identifier, and that value shall match for equality with the specified value. 4.2.5 Determining Group Membership Determining whether a given requestor is a group member requires checking two criteria. The determination may also be constrained if the group definition is not known locally. The criteria for membership and the treatment of non-local groups are discussed below. a) A directory server is NOT REQUIRED to perform a remote operation to determine whether the requestor belongs to a particular group for the purposes of Basic Access Control. If membership in the group cannot be evaluated, the server shall assume that the requestor does not belong to the group if the ACI item grants the Legg Expires 22 August 2002 [Page 16] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 permission sought, and does belong to the group if it denies the permission sought. Access control administrators should beware of basing access controls on membership of non-locally available groups or groups which are available only through replication (and which may, therefore, be out of date). b) In order to determine whether the requestor is a member of a userGroup user class, the following criteria apply: - The entry named by the userGroup specification is an instance of the object class groupOfNames or groupOfUniqueNames. - The name of the requestor is a value of the member or uniqueMember attribute of that entry. Values of the member or uniqueMember attribute that do not match the name of the requestor are ignored, even if they represent the names of groups of which the originator could be found to be a member. Hence, nested groups are not supported when evaluating access controls. 4.3 ACI Operational Attributes ACI is stored as values of operational attributes of entries and subentries. The operational attributes are multi-valued, which allows ACI to be represented as a set of ACI items. 4.3.1 Prescriptive ACI The prescriptiveACI attribute is defined as an operational attribute of an access control subentry. It contains prescriptive ACI applicable to entries within that subentry's scope. The LDAP description [RFC2252] for the prescriptiveACI operational attribute is: ( 2.5.24.4 NAME 'prescriptiveACI' EQUALITY directoryStringFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.1 USAGE directoryOperation ) The directoryStringFirstComponentMatch matching rule is described in [SCHEMA]. Legg Expires 22 August 2002 [Page 17] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 Prescriptive ACI within the subentries of a particular administrative point never applies to the same or any other subentry of that administrative point, but can be applicable to the subentries of subordinate administrative points. Note that prescriptiveACI attributes are not collective attributes. Although the values of a prescriptiveACI attribute contribute to access control decisions for each entry within the scope of the subentry that holds the attribute, the prescriptiveACI attribute does not appear as part of those entries. 4.3.2 Entry ACI The entryACI attribute is defined as an operational attribute of an entry or subentry (not just access control subentries). It contains entry ACI applicable to the entry or subentry in which it appears, and that (sub)entry's contents. The LDAP description [RFC2252] for the entryACI operational attribute is: ( 2.5.24.5 NAME 'entryACI' EQUALITY directoryStringFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.1 USAGE directoryOperation ) 4.3.3 Subentry ACI The subentryACI attribute is defined as an operational attribute of administrative entries [ADMIN] (for any aspect of administration). It contains subentry ACI that applies to each of the subentries of the administrative entry in which it appears. Only administrative entries are permitted to contain a subentryACI attribute. The LDAP description [RFC2252] for the subentryACI operational attribute is: ( 2.5.24.6 NAME 'subentryACI' EQUALITY directoryStringFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.1 USAGE directoryOperation ) 4.3.4 Protecting the ACI ACI operational attributes are subject to the same protection Legg Expires 22 August 2002 [Page 18] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 mechanisms as other attributes. The identificationTag provides an identifier for each ACI item. This tag can be used to remove a specific ACI item value, or to protect it by prescriptive ACI, entry ACI or subentry ACI. Directory rules ensure that only one ACI item per access control operational attribute possesses any specific identificationTag value. The creation of subentries for an administrative entry may be controlled by means of the subentryACI operational attribute in the administrative entry. The right to create prescriptive access controls may also be governed directly by security policy; this provision is required to create access controls in new autonomous administrative areas [ADMIN]. 4.4 Access Control Decision Points for LDAP Operations Each LDAP operation involves making a series of access control decisions on the various protected items that the operation accesses. For some operations (e.g. the Modify operation), each such access control decision must grant access for the operation to succeed; if access is denied to any protected item, the whole operation fails. For other operations (e.g. the Search operation), protected items to which access is denied are simply omitted from the operation result and processing continues. If the requested access is denied, further access control decisions may be needed to determine if the user has DiscloseOnError permissions to the protected item. Only if DiscloseOnError permission is granted may the server respond with an error that reveals the existence of the protected item. In all other cases, the server MUST act so as to conceal the existence of the protected item. The permissions required to access each protected item, are specified for each operation in the following sections. The algorithm by which a permission is determined to be granted or not granted is specified in Section 4.5. 4.4.1 Common Elements of Procedure This section defines the elements of procedure that are common to all LDAP operations when Basic Access Control is in effect. 4.4.1.1 Alias Dereferencing Legg Expires 22 August 2002 [Page 19] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 If, in the process of locating a target object entry (nominated in an LDAP request), alias dereferencing is required, no specific permissions are necessary for alias dereferencing to take place. However, if alias dereferencing would result in a referral being returned, the following sequence of access controls applies. 1) Read permission is required to the alias entry. If permission is not granted, the operation fails in accordance to the procedure described in 4.4.1.3. 2) Read permission is required to the aliasedEntryName attribute and to the single value that it contains. If permission is not granted, the operation fails and the resultCode aliasDereferencingProblem SHALL be returned. The matchedDN field of the LDAPResult SHALL contain the name of the alias entry. In addition to the access controls described above, security policy may prevent the disclosure of knowledge of other servers which would otherwise be conveyed in a referral. If such a policy is in effect the resultCode insufficientAccessRights SHALL be returned. 4.4.1.2 Return of Names in Errors Certain LDAP result codes, i.e. noSuchObject, aliasProblem, invalidDNSyntax and aliasDereferencingProblem, provide the name of an entry in the matchedDN field of an LDAPResult. The DN of an entry SHALL only be provided in the matchedDN field if DiscloseOnError permission is granted to that entry, otherwise, the matchedDN field of the LDAPResult SHALL either contain the name of the next superior entry to which DiscloseOnError permission is granted, or, if DiscloseOnError permission is not granted to any superior entry, the name of the root DSE (i.e. a zero-length LDAPDN). 4.4.1.3 Non-disclosure of the Existence of an Entry If, while performing an LDAP operation, the necessary entry level permission is not granted to the specified target object entry - e.g. the entry to be modified - the operation fails; if DiscloseOnError permission is granted to the target entry, the resultCode insufficientAccessRights SHALL be returned, otherwise, the resultCode noSuchObject SHALL be returned. The matchedDN field of the LDAPResult SHALL either contain the name of the next superior entry to which DiscloseOnError permission is granted, or, if DiscloseOnError permission is not granted to any superior entry, the name of the root DSE (i.e. a zero-length LDAPDN). Legg Expires 22 August 2002 [Page 20] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 Additionally, whenever the server detects an operational error (including a referral resultCode), it shall ensure that in returning that error it does not compromise the existence of the named target entry and any of its superiors. For example, before returning a resultCode of timeLimitExceeded or notAllowedOnNonLeaf, the server verifies that DiscloseOnError permission is granted to the target entry. If it is not, the procedure described in the paragraph above SHALL be followed. 4.4.2 Compare Operation Decision Points The following sequence of access controls applies for an entry being compared. 1) Read permission for the entry to be compared is required. If permission is not granted, the operation fails in accordance with 4.4.1.3. 2) Compare permission for the attribute to be compared is required. If permission is not granted, the operation fails: if DiscloseOnError permission is granted to the attribute being compared, a resultCode of insufficientAccessRight SHALL be returned, otherwise, the resultCode noSuchAttribute SHALL be returned. 3) If there exists a value within the attribute being compared that matches the purported argument and for which Compare permission is granted, the operation returns the resultCode compareTrue, otherwise the operation returns the resultCode compareFalse. 4.4.3 Search Operation Decision Points The following sequence of access controls applies for a portion of the DIT being searched. 1) No specific permission is required to the entry identified by the baseObject argument in order to initiate a search. However, if the baseObject is within the scope of the SearchArgument (i.e. when the subset argument specifies baseObject or wholeSubtree) the access controls specified in 2) through 5) will apply. 2) Browse or Read permission is required for the single entry within the scope of a baseObject search. An entry for which neither of these permissions is granted is ignored. This differs from the X.500 DAP Search operation where the Browse Legg Expires 22 August 2002 [Page 21] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 permission alone is required. An entry with Read permission but not Browse permission cannot be searched but can still be examined with an X.500 DAP Read operation. LDAP relies on baseObject search operations to provide the functionality of the DAP Read operation. Accepting Read permission for the target entry in a baseObject search gives an LDAP baseObject search the same access rights to the entry as the DAP Read operation. 3) Browse permission is required for an entry within the scope of a singleLevel or wholeSubtree search to be a candidate for consideration. Entries for which this permission is not granted are ignored. 4) The filter argument is applied to each entry left to be considered after taking 2) and 3) into account, in accordance with the following: a) For a present Filter item, if there exists an attribute value such that the attribute type of the value (possibly a subtype of the attribute type in the FilterItem) satisfies the Filter item and FilterMatch permission is granted for the value and for the attribute type then the FilterItem evaluates to TRUE, otherwise, it evaluates to FALSE. A search with baseObject scope is always assumed to have FilterMatch permission granted for a present match of the objectClass attribute. This differs from the X.500 DAP Search operation where no such permission is automatically assumed. This difference exists so that an LDAP baseObject search with a filter testing for the presence of the objectClass attribute will have the same access rights to the target entry as the DAP Read operation. b) For an equalityMatch, substrings, greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch Filter item, if there exists an attribute value such that the value satisfies the Filter item and FilterMatch permission is granted for the value and for its attribute type (possibly a subtype of the attribute type in the FilterItem) then the FilterItem evaluates to TRUE, otherwise, it evaluates to FALSE. Once the access controls defined in 2) through 4) have been applied, an entry is either selected or discarded. 5) For each selected entry the information returned is as follows: a) ReturnDN permission for an entry is required in order to return its distinguished name in a SearchResultEntry response. If Legg Expires 22 August 2002 [Page 22] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 this permission is not granted, the server SHALL either, return the name of a valid alias to the entry, or, omit the entry from the search result. If the base entry of the search was located using an alias, then that alias is known to be a valid alias. Otherwise, how it is ensured that the alias is valid is outside the scope of this specification. Where a server has a choice of alias names available to it for return, it is RECOMMENDED that where possible it choose the same alias name for repeated requests by the same client, in order to provide a consistent service. b) If the typesOnly field of the SearchRequest is TRUE then Read permission is required for each attribute type that is to be returned. If permission is not granted, the attribute type is omitted from the attribute list in the SearchResultEntry. If as a consequence of applying these controls no attribute type information is selected, the SearchResultEntry is returned but no attribute type information is conveyed with it (i.e. the attribute list is empty). c) If the typesOnly field of the SearchRequest is FALSE then Read permission is required for each attribute type and for each attribute value that is to be returned. If permission to an attribute type is not granted, the attribute is omitted from SearchResultEntry. If permission to an attribute value is not granted, the value is omitted from its corresponding attribute. If as a consequence of applying these controls no attribute information is selected, the SearchResultEntry is returned but no attribute information is conveyed with it (i.e. the attribute list is empty). 6) If as a consequence of applying the above controls to the entire scoped subtree the search result contains no entries (excluding any SearchResultReferences) and if DiscloseOnError permission is not granted to the entry identified by the baseObject argument, the operation fails and the resultCode noSuchObject SHALL be returned. The matchedDN field of the LDAPResult SHALL either contain the name of the next superior entry to which DiscloseOnError permission is granted, or the name of the root DSE (i.e. a zero-length LDAPDN). Otherwise, the operation succeeds but no subordinate information is conveyed with it. Security policy may prevent the disclosure of knowledge of other servers which would otherwise be conveyed as SearchResultReferences. If such a policy is in effect SearchResultReferences are omitted from Legg Expires 22 August 2002 [Page 23] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 the search result. No specific permissions are necessary to allow alias dereferencing to take place in the course of a search operation. However, for each alias entry encountered, if alias dereferencing would result in a SearchResultReference being returned, the following access controls apply: Read permission is required to the alias entry, the aliasedEntryName attribute and to the single value that it contains. If any of these permissions is not granted, the SearchResultReference SHALL be omitted from the search result. 4.4.4 Add Operation Decision Points The following sequence of access controls apply for an entry being added. 1) No specific permission is required for the immediate superior of the entry identified by the entry field of the AddRequest. 2) If an entry already exists with a distinguished name equal to the entry field the operation fails; if DiscloseOnError or Add permission is granted to the existing entry, the resultCode entryAlreadyExists SHALL be returned, otherwise, the procedure described in 4.4.1.3 is followed with respect to the entry being added. 3) Add permission is required for the new entry being added. If this permission is not granted, the operation fails; the procedure described in 4.4.1.3 is followed with respect to the entry being added. The Add permission is provided as prescriptive ACI when attempting to add an entry and as prescriptive ACI or subentry ACI when attempting to add a subentry. Any values of the entryACI attribute in the entry being added SHALL be ignored. 4) Add permission is required for each attribute type and for each value that is to be added. If any permission is absent, the operation fails and the resultCode insufficientAccessRights SHALL be returned. 4.4.5 Delete Operation Decision Points The following sequence of access controls apply for an entry being removed. Legg Expires 22 August 2002 [Page 24] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 1) Remove permission is required for the entry being removed. If this permission is not granted, the operation fails in accordance with 4.4.1.3. 2) No specific permissions are required for any of the attributes and attribute values present within the entry being removed. 4.4.6 Modify Operation Decision Points The following sequence of access controls apply for an entry being modified. 1) Modify permission is required for the entry being modified. If this permission is not granted, the operation fails in accordance with 4.4.1.3. 2) For each of the specified modification arguments applied in sequence, the following permissions are required: a) Add permission is required for each of the attribute values specified in an add modification. If the attribute does not currently exist then Add permission for the attribute type is also required. If these permissions are not granted, or any of the attribute values already exist, the operation fails; if an attribute value already exists and DiscloseOnError or Add is granted to that attribute value, the resultCode attributeOrValueExists SHALL be returned, otherwise, the resultCode insufficientAccessRights SHALL be returned. b) Remove permission is required for the attribute type specified in a delete modification with no listed attribute values. If this permission is not granted, the operation fails; if DiscloseOnError permission is granted to the attribute being removed and the attribute exists, the resultCode insufficientAccessRights SHALL be returned, otherwise, the resultCode noSuchAttribute SHALL be returned. No specific permissions are required for any of the attribute values present within the attribute being removed. c) Remove permission is required for each of the values in a delete modification with listed attribute values. If all current values of the attribute are specified to be removed (which causes the attribute itself to be removed), then Remove permission for the attribute type is also required. If these permissions are not granted, the operation fails; if DiscloseOnError permission is granted to any of the attribute Legg Expires 22 August 2002 [Page 25] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 values being removed, the resultCode insufficientAccessRights SHALL be returned, otherwise, the resultCode noSuchAttribute SHALL be returned. d) Remove and Add permission is required for the attribute type, and Add permission is required for each of the specified attribute values, in a replace modification. If these permissions are not granted the operation fails and the resultCode insufficientAccessRights SHALL be returned. No specific permissions are required to remove any existing attribute values of the attribute being replaced. 4.4.7 Modify DN Operation Decision Points The following sequence of access controls apply for an entry having its DN modified. 1) If the effect of the operation is to change the RDN of the entry then Rename permission (determined with respect to its original name) is required for the entry. If this permission is not granted, the operation fails; the procedure described in 4.4.1.3 is followed with respect to the entry being renamed (considered with its original name). No additional permissions are required even if, as a result of modifying the RDN of the entry, a new distinguished value needs to be added, or an old one removed. No specific permissions are required for the subordinates of the renamed entry. 2) If the effect of the operation is to move an entry to a new superior in the DIT then Export permission (determined with respect to its original name) and Import permission (determined with respect to its new name) are required for the entry. If either of these permissions is not granted, the operation fails; the procedure described in 4.4.1.3 is followed with respect to the entry being moved (considered with its original name). The Import permission is provided as prescriptive ACI when attempting to move an entry and as prescriptive ACI or subentry ACI when attempting to move a subentry. Any values of the entryACI attribute in the entry or subentry being moved SHALL be ignored. No specific permissions are required for the subordinates of the moved entry. Legg Expires 22 August 2002 [Page 26] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 Note that a single Modify DN Operation may simultaneously rename and move an entry. 4.5 Access Control Decision Function This section describes how ACI items are processed in order to decide whether to grant or deny a particular requestor a specified permission to a given protected item. Section 4.5.1 describes the inputs to the ACDF. Sections 4.5.2 through 4.5.4 describe the steps in the ACDF. The output is a decision to grant or deny access to the protected item. 4.5.1 Inputs For each invocation of the ACDF, the inputs are: a) the requestor's Distinguished Name, unique identifier, and authentication level, or as many of these as are available; b) the protected item (an entry, an attribute, or an attribute value) being considered at the current decision point for which the ACDF was invoked; c) the requested permission specified for the current decision point; d) the ACI items applicable to the entry containing (or which is) the protected item. In addition, if the ACI items include any of the protected item constraints described in 4.2.1.4, the whole entry and the number of immediate subordinates of its superior entry may also be required as inputs. 4.5.2 Tuples For each ACI item, expand the item into a set of tuples, one tuple for each element of the itemPermissions and userPermissions sets, containing the following elements: ( userClasses, authenticationLevel, protectedItems, grantsAndDenials, precedence ) Collect all tuples from all ACI items into a single set. Legg Expires 22 August 2002 [Page 27] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 For any tuple whose grantsAndDenials specify both grants and denials, replace the tuple with two tuples - one specifying only grants and the other specifying only denials. 4.5.3 Discarding Irrelevant Tuples Perform the following steps to discard all irrelevant tuples: 1) Discard all tuples that do not include the requestor in the tuple's userClasses as follows: a) For tuples that grant access, discard all tuples that do not include the requestor's identity in the tuples's userClasses element, taking into account UniqueIdentifier elements if relevant. Where a tuple's userClasses specifies a UniqueIdentifier, a matching value shall be present in the requestor's identity if the tuple is not to be discarded. Discard tuples that specify an authentication level higher than that associated with the requestor. b) For tuples that deny access, retain all tuples that include the requestor in the tuple's userClasses element, taking into account uniqueIdentifier elements if relevant. Also retain all tuples that deny access and which specify an authentication level higher than that associated with the requestor. This reflects the fact that the requestor has not adequately proved non-membership in the user class for which the denial is specified. All other tuples that deny access are discarded. 2) Discard all tuples that do not include the protected item in protectedItems. 3) Examine all tuples that include the maxValueCount, maxImmSub or restrictedBy. Discard all such tuples which grant access and which do not satisfy any of these constraints. 4) Discard all tuples that do not include the requested permission as one of the set bits in grantsAndDenials. The order in which tuples are discarded does not change the output of the ACDF. 4.5.4 Highest Precedence and Specificity Perform the following steps to select those tuples of highest precedence and specificity: Legg Expires 22 August 2002 [Page 28] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 1) Discard all tuples having a precedence less than the highest precedence among the remaining tuples. 2) If more than one tuple remains, choose the tuples with the most specific user class. If there are any tuples matching the requestor with UserClasses element name or thisEntry, discard all other tuples. Otherwise if there are any tuples matching UserGroup, discard all other tuples. Otherwise if there are any tuples matching subtree, discard all other tuples. 3) If more than one tuple remains, choose the tuples with the most specific protected item. If the protected item is an attribute and there are tuples that specify the attribute type explicitly, discard all other tuples. If the protected item is an attribute value, and there are tuples that specify the attribute value explicitly, discard all other tuples. A protected item which is a rangeOfValues is to be treated as specifying an attribute value explicitly. Grant access if and only if one or more tuples remain and all grant access. Otherwise deny access. 5. Simplified Access Control This section describes the functionality of the Simplified Access Control scheme. It provides a subset of the functionality found in Basic Access Control. When Simplified Access Control is used, the accessControlScheme operational attribute [ADMIN] SHALL have the value simplified-access-control (2.5.28.2). The functionality of Simplified Access Control is the same as Basic Access Control except that: 1) Access control decisions shall be made only on the basis of values of prescriptiveACI and subentryACI operational attributes. Values of the entryACI attribute, if present, SHALL NOT be used to make access control decisions. 2) Access Control Inner Areas are not used. Values of prescriptiveACI attributes appearing in subentries of ACIPs SHALL NOT be used to make access control decisions. All other provisions SHALL be as defined for Basic Access Control. Legg Expires 22 August 2002 [Page 29] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 6. Security Considerations Access control administrators should beware of basing access controls on membership of non-locally available groups or groups which are available only through replication (and which may, therefore, be out of date). A particular DSA might not have the ACI governing any data that it caches. Administrators should be aware that a directory server with the capability of caching may pose a significant security risk to other directory servers, in that it may reveal information to unauthorized users. 7. Acknowledgements This document is derived from, and duplicates substantial portions of, Section 8 of [X501], and selected extracts from [X511]. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [ADMIN] Legg, S., "Access Control Administration in LDAP", draft-legg-ldap-acm-admin-xx.txt, a work in progress, February 2002. [CMR] Legg, S., "LDAP & X.500 Component Matching Rules", draft-legg-ldapext-component-matching-xx.txt, a work in progress, January 2002. [COLLECT] Zeilenga, K., "Collective Attributes in LDAP", draft-zeilenga-ldap-collective-xx.txt, a work in progress, January 2002. [SCHEMA] Zeilenga, K., "LDAPv3: A Collection of User Schema", Legg Expires 22 August 2002 [Page 30] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 draft-zeilenga-ldap-user-schema-xx.txt, a work in progress, January 2002. [X680] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998 Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation 9. Informative References [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [GCE] Legg, S., "Common Elements of GSER Encodings", draft-legg-ldap-gser-abnf-xx.txt, a work in progress, January 2002. [X501] ITU-T Recommendation X.501 (02/2001), Information technology - Open Systems Interconnection - The Directory: Models [X511] ITU-T Recommendation X.511 (02/2001), Information technology - Open Systems Interconnection - The Directory: Abstract service definition 10. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. [RFC2028] Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Legg Expires 22 August 2002 [Page 31] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 11. Copyright Notice Copyright (C) The Internet Society (2002). 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. 12. Author's Address Steven Legg Adacel Technologies Ltd. 405-409 Ferntree Gully Road Mount Waverley, Victoria 3149 AUSTRALIA Phone: +61 3 9451 2107 Fax: +61 3 9541 2121 EMail: steven.legg@adacel.com.au Legg Expires 22 August 2002 [Page 32] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 Appendix A. Native LDAP Encoding for the ACI Item Syntax This appendix is non-normative. The native LDAP (i.e. string) encoding for the ACI Item syntax is specified by the Generic String Encoding Rules in Section 8 of [CMR]. The ABNF [RFC2234] in this appendix for this syntax is provided only as a convenience and is equivalent to the encoding specified by the application of [CMR]. Since the ACI Item ASN.1 type may be extended in future editions of [X501], the provided ABNF should be regarded as a snapshot in time. The native LDAP encoding for any extension to the ACI Item ASN.1 type can be determined from [CMR]. In the event that there is a discrepancy between this ABNF and the encoding determined by [CMR], [CMR] is to be taken as definitive. ACIItem = "{" sp aci-identificationTag "," sp aci-precedence "," sp aci-authenticationLevel "," sp aci-itemOrUserFirst sp "}" aci-identificationTag = id-identificationTag msp DirectoryString aci-precedence = id-precedence msp Precedence aci-authenticationLevel = id-authenticationLevel msp AuthenticationLevel aci-itemOrUserFirst = id-itemOrUserFirst msp ItemOrUserFirst id-identificationTag = %x69.64.65.6E.74.69.66.69.63.61.74.69.6F %x6E.54.61.67 ; "identificationTag" id-precedence = %x70.72.65.63.65.64.65.6E.63.65 ; "precedence" id-authenticationLevel = %x61.75.74.68.65.6E.74.69.63.61.74.69.6F %x6E.4C.65.76.65.6C ; "authenticationLevel" id-itemOrUserFirst = %x69.74.65.6D.4F.72.55.73.65.72.46.69.72 %x73.74 ; "itemOrUserFirst" Precedence = INTEGER-0-MAX ; MUST be less than 256 AuthenticationLevel = al-basicLevels / al-other al-basicLevels = id-basicLevels ":" BasicLevels al-other = id-other ":" EXTERNAL id-basicLevels = %x62.61.73.69.63.4C.65.76.65.6C.73 ; "basicLevels" id-other = %x6F.74.68.65.72 ; "other" Legg Expires 22 August 2002 [Page 33] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 BasicLevels = "{" sp bl-level [ "," sp bl-localQualifier ] [ "," sp bl-signed ] sp "}" bl-level = id-level msp Level bl-localQualifier = id-localQualifier msp INTEGER bl-signed = id-signed msp BOOLEAN Level = id-none / id-simple / id-strong id-level = %x6C.65.76.65.6C ; "level" id-localQualifier = %x6C.6F.63.61.6C.51.75.61.6C.69.66.69.65.72 ; "localQualifier" id-signed = %x73.69.67.6E.65.64 ; "signed" id-none = %x6E.6F.6E.65 ; "none" id-simple = %x73.69.6D.70.6C.65 ; "simple" id-strong = %x73.74.72.6F.6E.67 ; "strong" ItemOrUserFirst = ( id-itemFirst ":" ItemFirst ) / ( id-userFirst ":" UserFirst ) id-itemFirst = %x69.74.65.6D.46.69.72.73.74 ; "itemFirst" id-userFirst = %x75.73.65.72.46.69.72.73.74 ; "userFirst" ItemFirst = "{" sp if-protectedItems "," sp if-itemPermissions sp "}" if-protectedItems = id-protectedItems msp ProtectedItems if-itemPermissions = id-itemPermissions msp ItemPermissions id-protectedItems = %x70.72.6F.74.65.63.74.65.64.49.74.65.6D.73 ; "protectedItems" id-itemPermissions = %x69.74.65.6D.50.65.72.6D.69.73.73.69.6F.6E %x73 ; "itemPermissions" UserFirst = "{" sp uf-userClasses "," sp uf-userPermissions sp "}" uf-userClasses = id-userClasses msp UserClasses uf-userPermissions = id-userPermissions msp UserPermissions id-userClasses = %x75.73.65.72.43.6C.61.73.73.65.73 ; "userClasses" id-userPermissions = %x75.73.65.72.50.65.72.6D.69.73.73.69.6F.6E %x73 ; "userPermissions" ItemPermissions = "{" [ sp ItemPermission *( "," sp ItemPermission ) ] sp "}" ItemPermission = "{" [ sp ip-precedence "," ] sp ip-userClasses "," sp ip-grantsAndDenials sp "}" Legg Expires 22 August 2002 [Page 34] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 ip-precedence = id-precedence msp Precedence ip-userClasses = id-userClasses msp UserClasses ip-grantsAndDenials = id-grantsAndDenials msp GrantsAndDenials id-grantsAndDenials = %x67.72.61.6E.74.73.41.6E.64.44.65.6E.69.61 %x6C.73 ; "grantsAndDenials" UserClasses = "{" [ sp uc-allUsers ] [ sep sp uc-thisEntry ] [ sep sp uc-name ] [ sep sp uc-userGroup ] [ sep sp uc-subtree ] sp "}" uc-allUsers = id-allUsers msp NULL uc-thisEntry = id-thisEntry msp NULL uc-name = id-name msp NameAndOptionalUIDs uc-userGroup = id-userGroup msp NameAndOptionalUIDs uc-subtree = id-subtree msp SubtreeSpecifications id-allUsers = %x61.6C.6C.55.73.65.72.73 ; "allUsers" id-thisEntry = %x74.68.69.73.45.6E.74.72.79 ; "thisEntry" id-name = %x6E.61.6D.65 ; "name" id-userGroup = %x75.73.65.72.47.72.6F.75.70 ; "userGroup" id-subtree = %x73.75.62.74.72.65.65 ; "subtree" NameAndOptionalUIDs = "{" sp NameAndOptionalUID *( "," sp NameAndOptionalUID ) sp "}" NameAndOptionalUID = "{" sp nu-dn [ "," sp nu-uid ] sp "}" nu-dn = id-dn msp DistinguishedName nu-uid = id-uid msp UniqueIdentifier UniqueIdentifier = BIT-STRING id-dn = %x64.6E ; "dn" id-uid = %x75.69.64 ; "uid" SubtreeSpecifications = "{" sp SubtreeSpecification *( "," sp SubtreeSpecification ) sp "}" UserPermissions = "{" [ sp UserPermission *( "," sp UserPermission ) ] sp "}" UserPermission = "{" [ sp up-precedence "," ] sp up-protectedItems "," sp up-grantsAndDenials sp "}" up-precedence = id-precedence msp Precedence up-protectedItems = id-protectedItems msp ProtectedItems up-grantsAndDenials = id-grantsAndDenials msp GrantsAndDenials ProtectedItems = "{" [ sp pi-entry ] Legg Expires 22 August 2002 [Page 35] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 [ sep sp pi-allUserAttributeTypes ] [ sep sp pi-attributeType ] [ sep sp pi-allAttributeValues ] [ sep sp pi-allUserTypesAndValues ] [ sep sp pi-attributeValue ] [ sep sp pi-selfValue ] [ sep sp pi-rangeOfValues ] [ sep sp pi-maxValueCount ] [ sep sp pi-maxImmSub ] [ sep sp pi-restrictedBy ] ; contexts omitted [ sep sp pi-classes ] sp "}" pi-entry = id-entry msp NULL pi-allUserAttributeTypes = id-allUserAttributeTypes msp NULL pi-attributeType = id-attributeType msp AttributeTypes pi-allAttributeValues = id-allAttributeValues msp AttributeTypes pi-allUserTypesAndValues = id-allUserAttributeTypesAndValues msp NULL pi-attributeValue = id-attributeValue msp AttributeTypeAndValues pi-selfValue = id-selfValue msp AttributeTypes pi-rangeOfValues = id-rangeOfValues msp Filter pi-maxValueCount = id-maxValueCount msp MaxValueCounts pi-maxImmSub = id-maxImmSub msp INTEGER pi-restrictedBy = id-restrictedBy msp RestrictedValues pi-classes = id-classes msp Refinement id-entry = %x65.6E.74.72.79 ; "entry" id-allUserAttributeTypes = %x61.6C.6C.55.73.65.72.41.74.74.72.69 %x62.75.74.65.54.79.70.65.73 ; "allUserAttributeTypes" id-attributeType = %x61.74.74.72.69.62.75.74.65.54.79.70 %x65 ; "attributeType" id-allAttributeValues = %x61.6C.6C.41.74.74.72.69.62.75.74.65 %x56.61.6C.75.65.73 ; "allAttributeValues" id-attributeValue = %x61.74.74.72.69.62.75.74.65.56.61.6C %x75.65 ; "attributeValue" id-selfValue = %x73.65.6C.66.56.61.6C.75.65 ; "selfValue" id-rangeOfValues = %x72.61.6E.67.65.4F.66.56.61.6C.75.65 %x73 ; "rangeOfValues" id-maxValueCount = %x6D.61.78.56.61.6C.75.65.43.6F.75.6E %x74 ; "maxValueCount" id-maxImmSub = %x6D.61.78.49.6D.6D.53.75.62 ; "maxImmSub" Legg Expires 22 August 2002 [Page 36] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 id-restrictedBy = %x72.65.73.74.72.69.63.74.65.64.42.79 ; "restrictedBy" id-classes = %x63.6C.61.73.73.65.73 ; "classes" id-allUserAttributeTypesAndValues = %x61.6C.6C.55.73.65.72.41.74 %x74.72.69.62.75.74.65.54.79.70.65.73 %x41.6E.64.56.61.6C.75.65.73 ; "allUserAttributeTypesAndValues" AttributeTypes = "{" sp AttributeType *( "," sp AttributeType ) sp "}" AttributeTypeAndValues = "{" sp AttributeTypeAndValue *( "," sp AttributeTypeAndValue ) sp "}" AttributeTypeAndValue = "{" sp atav-type "," sp atav-value sp "}" atav-type = id-type msp AttributeType atav-value = id-value msp Value id-type = %x74.79.70.65 ; "type" id-value = %x76.61.6C.75.65 ; "value" MaxValueCounts = "{" sp MaxValueCount *( "," sp MaxValueCount ) sp "}" MaxValueCount = "{" sp mvc-type "," sp mvc-maxCount sp "}" mvc-type = id-type msp AttributeType mvc-maxCount = id-maxCount msp INTEGER id-maxCount = %x6D.61.78.43.6F.75.6E.74 ; "maxCount" RestrictedValues = "{" sp RestrictedValue *( "," sp RestrictedValue ) sp "}" RestrictedValue = "{" sp rv-type "," sp rv-valuesin sp "}" rv-type = id-type msp AttributeType rv-valuesin = id-valuesin msp AttributeType id-valuesin = %x76.61.6C.75.65.73.69.6E ; "valuesin" GrantsAndDenials = "{" [ sp grantOrDeny *( "," sp grantOrDeny ) ] sp "}" grantOrDeny = id-grantAdd / id-denyAdd / id-grantDiscloseOnError / id-denyDiscloseOnError Legg Expires 22 August 2002 [Page 37] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 / id-grantRead / id-denyRead / id-grantRemove / id-denyRemove / id-grantBrowse / id-denyBrowse / id-grantExport / id-denyExport / id-grantImport / id-denyImport / id-grantModify / id-denyModify / id-grantRename / id-denyRename / id-grantReturnDN / id-denyReturnDN / id-grantCompare / id-denyCompare / id-grantFilterMatch / id-denyFilterMatch ; grantInvoke omitted ; denyInvoke omitted id-grantAdd = %x67.72.61.6E.74.41.64.64 ; "grantAdd" id-denyAdd = %x64.65.6E.79.41.64.64 ; "denyAdd" id-grantBrowse = %x67.72.61.6E.74.42.72.6F.77.73.65 ; "grantBrowse" id-denyBrowse = %x64.65.6E.79.42.72.6F.77.73.65 ; "denyBrowse" id-grantCompare = %x67.72.61.6E.74.43.6F.6D.70.61.72.65 ; "grantCompare" id-denyCompare = %x64.65.6E.79.43.6F.6D.70.61.72.65 ; "denyCompare" id-grantDiscloseOnError = %x67.72.61.6E.74.44.69.73.63.6C.6F.73.65 %x4F.6E.45.72.72.6F.72 ; "grantDiscloseOnError" id-denyDiscloseOnError = %x64.65.6E.79.44.69.73.63.6C.6F.73.65.4F %x6E.45.72.72.6F.72 ; "denyDiscloseOnError" id-grantExport = %x67.72.61.6E.74.45.78.70.6F.72.74 ; "grantExport" id-denyExport = %x64.65.6E.79.45.78.70.6F.72.74 ; "denyExport" id-grantFilterMatch = %x67.72.61.6E.74.46.69.6C.74.65.72.4D.61.74 %x63.68 ; "grantFilterMatch" id-denyFilterMatch = %x64.65.6E.79.46.69.6C.74.65.72.4D.61.74.63 %x68 ; "denyFilterMatch" Legg Expires 22 August 2002 [Page 38] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 id-grantImport = %x67.72.61.6E.74.49.6D.70.6F.72.74 ; "grantImport" id-denyImport = %x64.65.6E.79.49.6D.70.6F.72.74 ; "denyImport" id-grantModify = %x67.72.61.6E.74.4D.6F.64.69.66.79 ; "grantModify" id-denyModify = %x64.65.6E.79.4D.6F.64.69.66.79 ; "denyModify" id-grantRead = %x67.72.61.6E.74.52.65.61.64 ; "grantRead" id-denyRead = %x64.65.6E.79.52.65.61.64 ; "denyRead" id-grantRemove = %x67.72.61.6E.74.52.65.6D.6F.76.65 ; "grantRemove" id-denyRemove = %x64.65.6E.79.52.65.6D.6F.76.65 ; "denyRemove" id-grantRename = %x67.72.61.6E.74.52.65.6E.61.6D.65 ; "grantRename" id-denyRename = %x64.65.6E.79.52.65.6E.61.6D.65 ; "denyRename" id-grantReturnDN = %x67.72.61.6E.74.52.65.74.75.72.6E.44.4E ; "grantReturnDN" id-denyReturnDN = %x64.65.6E.79.52.65.74.75.72.6E.44.4E ; "denyReturnDN" The , , , , , , , , , , , and rules are described in [GCE]. The and rules are described in [SUBENTRY]. The rule is described in [CMR]. Filter = filter-item / filter-and / filter-or / filter-not filter-item = id-item ":" FilterItem filter-and = id-and ":" SetOfFilter filter-or = id-or ":" SetOfFilter filter-not = id-not ":" Filter id-and = %x61.6E.64 ; "and" id-item = %x69.74.65.6D ; "item" id-not = %x6E.6F.74 ; "not" id-or = %x6F.72 ; "or" SetOfFilter = "{" [ sp Filter *( "," sp Filter ) ] sp "}" FilterItem = fi-equality / fi-substrings / fi-greaterOrEqual / fi-lessOrEqual Legg Expires 22 August 2002 [Page 39] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 / fi-present / fi-approximateMatch / fi-extensibleMatch ; contextPresent omitted fi-equality = id-equality ":" AttributeValueAssertion fi-substrings = id-substrings ":" SubstringsAssertion fi-greaterOrEqual = id-greaterOrEqual ":" AttributeValueAssertion fi-lessOrEqual = id-lessOrEqual ":" AttributeValueAssertion fi-present = id-present ":" AttributeType fi-approximateMatch = id-approximateMatch ":" AttributeValueAssertion fi-extensibleMatch = id-extensibleMatch ":" MatchingRuleAssertion id-equality = %x65.71.75.61.6C.69.74.79 ; "equality" id-substrings = %x73.75.62.73.74.72.69.6E.67.73 ; "substrings" id-greaterOrEqual = %x67.72.65.61.74.65.72.4F.72.45.71.75.61.6C ; "greaterOrEqual" id-lessOrEqual = %x6C.65.73.73.4F.72.45.71.75.61.6C ; "lessOrEqual" id-present = %x70.72.65.73.65.6E.74 ; "present" id-approximateMatch = %x61.70.70.72.6F.78.69.6D.61.74.65.4D.61.74 %x63.68 ; "approximateMatch" id-extensibleMatch = %x65.78.74.65.6E.73.69.62.6C.65.4D.61.74.63 %x68 ; "extensibleMatch" AttributeValueAssertion = "{" sp ava-type "," sp ava-assertion ; assertedContexts omitted sp "}" ava-type = id-type msp AttributeType ava-assertion = id-assertion msp Value id-assertion = %x61.73.73.65.72.74.69.6F.6E ; "assertion" SubstringsAssertion = "{" sp sa-type "," sp sa-strings sp "}" sa-type = id-type msp AttributeType sa-strings = id-strings msp Substrings id-strings = %x73.74.72.69.6E.67.73 ; "strings" Substrings = "{" [ sp Substring *( "," sp Substring ) ] sp "}" Substring = ss-initial / ss-any / ss-final Legg Expires 22 August 2002 [Page 40] INTERNET-DRAFT Basic & Simplified Access Control February 22, 2002 ; control omitted ss-initial = id-initial ":" Value ss-any = id-any ":" Value ss-final = id-final ":" Value id-initial = %x69.6E.69.74.69.61.6C ; "initial" id-any = %x61.6E.79 ; "any" id-final = %x66.69.6E.61.6C ; "final" MatchingRuleAssertion = "{" sp mra-matchingRule [ "," sp mra-type ] "," sp mra-matchValue [ "," sp mra-dnAttributes ] sp "}" mra-matchingRule = id-matchingRule msp MatchingRuleIds mra-type = id-type msp AttributeType mra-matchValue = id-matchValue msp Value mra-dnAttributes = id-dnAttributes msp BOOLEAN id-matchingRule = %x6D.61.74.63.68.69.6E.67.52.75.6C.65 ; "matchingRule" id-matchValue = %x6D.61.74.63.68.56.61.6C.75.65 ; "matchValue" id-dnAttributes = %x64.6E.41.74.74.72.69.62.75.74.65.73 ; "dnAttributes" MatchingRuleIds = "{" sp MatchingRuleId *( "," sp MatchingRuleId ) sp "}" MatchingRuleId = OBJECT-IDENTIFIER Legg Expires 22 August 2002 [Page 41]