Internet-Draft E. Stokes LDAP Extensions WG D. Byrne Intended Category: Standards Track IBM Expires: 10 September 2000 B. Blakley Dascom 10 March 2000 Access Control Model for LDAP STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the LDAPEXT working group discussion list: ietf-ldapext@netscape.com COPYRIGHT NOTICE Copyright (C) The Internet Society (1997). All Rights Reserved. ABSTRACT This document describes the access control model for the Lightweight Directory Application Protocol (LDAP) Stokes, Byrne, Blakley Expires 10 September 2000 [Page 1] Internet-Draft Access Control Model 10 March 2000 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. The keywords "MUST", "SHOULD", 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 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 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. Stokes, Byrne, Blakley Expires 10 September 2000 [Page 2] Internet-Draft Access Control Model 10 March 2000 The access control model defines - A wire protocol for interoperability: The existing LDAP protocol flows for add, delete, modify, and search are used to manipulate access control information. There is an additional LDAP control and extended protocol operation defined, getEffectiveRights, to further help management of access control information. - 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 in a given part of the namespace. 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. 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. Stokes, Byrne, Blakley Expires 10 September 2000 [Page 3] Internet-Draft Access Control Model 10 March 2000 3. Terminology An "access control list" contains the access control policy information controlling access to an object or 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. 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 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 "access decision function interface" is a programmatic interface through which applications can request an access decision. An "access identity" is an identity which is used by an access decision function to make an access decision. 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. A "credential" is a collection of subject security attributes. "effective rights" are the complete set of rights a subject is entitled to based on all access control lists Stokes, Byrne, Blakley Expires 10 September 2000 [Page 4] Internet-Draft Access Control Model 10 March 2000 which apply to a specific object and based on all of the subject's security attributes. "granted rights" are the complete set of rights an access control list entitles a subject to based on a specific subject security attribute. A "group" is a privilege attribute asserting a subject's membership in the collection of subjects whose name is that of the group. 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. "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. 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. A "role" is a privilege attribute asserting a subject's organizational position and entitlement to perform the operations appropriate to that organizational position. A "subject' is an entity which initiate actions in an information system. A "subject security attribute" is a defined property which is used by a security policy evaluation system to make policy decisions. Stokes, Byrne, Blakley Expires 10 September 2000 [Page 5] Internet-Draft Access Control Model 10 March 2000 4. The Model The access control mechanism described in this draft addresses these activities: - Definition of subject security attributes information - Definition of access control policy - Retrieval of subject security attributes - Retrieval of effective access rights - 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, Byrne, Blakley Expires 10 September 2000 [Page 6] Internet-Draft Access Control Model 10 March 2000 The diagram below illustrates the componentry of a LDAP system and the placement of the function specified in this draft. +-------------+ | Application |<--attrs to address ACI +-------------+ - ldapACI +--------+ - policyOwner | LDAP | | Client | +--------+ | | <-- LDAP control | - getEffectiveAccess | | <-- LDAP extended operation | - getEffectiveAccess v +-----------------------------+ | LDAP Server (e.g. SLAPD) | +-----------------------------+ . | . | . | . | v v +----------+ +-----------+ | Access | | |<-attrs to define | Control |<--| Datastore | access control mechanisms | Manager | | | - supportedACIMechanisms +----------+ +-----------+ - aCIMechanisms LDAP clients use the control and extended operation 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, Byrne, Blakley Expires 10 September 2000 [Page 7] Internet-Draft Access Control Model 10 March 2000 The access control administration mechanisms specified in this document are neutral with respect to policy inheritance mechanisms, explicit vs. implicit denial, and group nesting. 5. Access Control Mechanism Attributes There are several attributes defined associated with access control. Two attributes are defined to identify which access control mechanisms are supported by a given server and by a given subtree: supportedACIMechanisms and aCIMechanisms. 5.1 Root DSE Attribute for Access Control Mechanism 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. ( NAME 'supportedACIMechanisms' DESC list of access control mechanisms supported by this directory server SYNTAX LDAPOID USAGE dSAOperation ) The access control mechanism defined is: LDAPv3 Other vendor access control mechanisms can be defined (by OID) and are the responsibility of those vendors to provide the definition and OID. 5.2 Subschema Attribute for Access Control Mechanism A given naming context must provide information about which access control mechanisms are in effect for that portion of the namespace. The following attribute must be in each subschema entry associated with a naming Stokes, Byrne, Blakley Expires 10 September 2000 [Page 8] Internet-Draft Access Control Model 10 March 2000 context whose access control mechanism is different from adjacent naming contexts supported by that directory server. aCIMechanisms lists the values (list of OIDs) that defines the access control mechanism in effect for the scope of that subschema entry. More than one mechanism may be in effect for the scope of that subschema entry. ( NAME 'aCIMechanisms' DESC list of access control mechanisms supported in this subtree SYNTAX LDAPOID USAGE dSAOperation ) 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 server should be able to understand the attributes; 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 Stokes, Byrne, Blakley Expires 10 September 2000 [Page 9] Internet-Draft Access Control Model 10 March 2000 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. Two 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. These two attributes may be queried or set on all directory objects: ldapACI and policyOwner. Their BNF and definitions are defined below. 6.1 The BNF < ldapACI > ::= < acl entry syntax > < acl entry syntax > ::= + '#' + + '#' + < rights > + '#' + < dnType > + '#' + < subjectDn > < policyOwner > ::= < familyOid > + '#' + + '#' +< dnType > + '#' + < subjectDn > < subjectDn > ::= < printable string > | "public" | "this" < familyOid > ::= < oid > ::= "entry" | "subtree" < dnType > ::= "access-id" | "role" | "group" | "subtree" | "ipAddress" | "kerberosID" | < kerberosID > ::= < userID > + '@' + < realm > < userID > ::= < printableString > < realm > ::= < printableString > < rights > ::= "grant" + ';' + + ';'+ | "deny" + ';' + + ';'+ | "grant"+';'++';'+"deny"+';'++';'+ < permissions > ::= [ ] | [ Stokes, Byrne, Blakley Expires 10 September 2000 [Page 10] Internet-Draft Access Control Model 10 March 2000 + [ ',' + ] ]* < attr > ::= ["collection" + ':' + [ "[all]" | "[entry]" | ] ] | ["attribute" + ':' ] < permission > ::= "a" | "d" | "r" | "s" | "w" | "c" | "e" | "b" These are the permissions defined for the IETF LDAP family OID. "a" corresponds to add "d" corresponds to delete "r" corresponds to read "s" corresponds to search "w" corresponds to write "c" corresponds to compare "e" corresponds to editDN "b" corresponds to browseDN 6.2 Other Defined Parameters This section defines additional parameters that are used in the two attributes that address access control information. 6.2.1 Families and Rights The familyOID tells what permission set etc. will follow in the string. This allows a different permission set, scope etc., but with the same syntax. The following family is defined: IETF-LDAPv3 Other families can be defined (by OID). It is the responsibility of those parties to provide the definition and OID. 6.2.1.1 IETF-LDAPv3 Family Access rights can apply to an entire object or to Stokes, Byrne, Blakley Expires 10 September 2000 [Page 11] Internet-Draft Access Control Model 10 March 2000 attributes of the object. Each of the LDAP access rights are discrete. One permission does not imply another permission. The rights which apply to attributes and the entry parallel the type of ldap operations that can be performed. Rights which apply to attributes: r Read Read attribute values w Write Write attribute values s Search Search entries with specified attributes c Compare Compare attributes Rights that apply to an entire entry: a Add Add an entry below this entry d Delete Delete this entry e EditDN Edit an entry's DN b BrowseDN Browse an entry's DN When searching, the ldap search filter specifies the returned set of attributes. To do the search, browse (b) must be set for the entry (you can search only entries that you have permission to search so you can't discover things you don't have permission to) and search (s) must be set for all attributes used in the filter if you are testing for existence, otherwise search (s) and read (r) must be set for all attributes used in the filter because the filter specifies a test for other than existence. For a search to return attribute names only, search (s) must be set for the attribute. For a search to return attribute names and values, search (s) and read (r) must be set for the attribute. Search (s) implies knowledge of the attribute; read (r) implies knowledge of the value. 6.2.2 DN Types The following DN Types strings are defined and MUST be supported: - access-id Stokes, Byrne, Blakley Expires 10 September 2000 [Page 12] Internet-Draft Access Control Model 10 March 2000 - group - role The following DN Types strings are defined and SHOULD be supported: - ipAddress - kerberosID An access-id is a non-collection (non-group and non-role objects) DN that can be authenticated. groupOfNames and groupOfUniqueNames (or subclasses from those object classes) must be recognized as a collection object. This aids in interoperability during replication. Other parties can (and will) define other DN Types. It is the responsibility of those parties to provide the definition. 6.3 Basic ACI Attribute (ldapACI) ( NAME 'ldapACI' DESC 'ldap access control information' EQUALITY caseIgnoreMatch SYNTAX directoryString USAGE directoryOperation ) 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 ldapACI attribute is listed as other than the IETF-LDAPv3 family OID, the syntax is the same, but one or more of the scope, dnType, subjectDn or permissions may vary from the 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 Stokes, Byrne, Blakley Expires 10 September 2000 [Page 13] Internet-Draft Access Control Model 10 March 2000 granted or denied access. The set of permissions is fixed. Either or both of the actions "grant" | "deny" may be used when creating or updating ldapACI. describes either an attribute name or an attribute collection. The keyword attribute indicates that the following printable string refers to an attribute name. If the string refers to an attribute not defined in the given server's schema, the server SHOULD report an error. The keyword "collection" indicates that the string that follows describes a group of attributes. The method for grouping attributes is server specific. Another option for the collection printable string 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 a child object. The third option for a collection is "[all]" which means the permission set should apply to all attributes. Even if the server does not support attribute grouping, it MUST recognize the "[all]" and "[entry]" keywords. If the server receives an unrecognized attribute collection name, the server SHOULD return an error. If the server supports grouping, the grouping is server and implementation specific. 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]". All permissions (for grant and deny) for an attribute and a given DN MUST be contained within one ldapACI value, i.e. (in abbreviated form) ldapACI: ...grant attr1 DN1 ldapACI: ...deny attr1 DN1 must be ldapACI: ...grant ... deny... attr1 DN1 Using the defined BNF it is possible for the permission string to be empty. The ACI ldapACI: 1.2.3.4#subtree#grant;; attribute:attr1#group#cn=Dept XYZ,c=US ldapACI: 1.2.3.4#subtree#grant;r,s; Stokes, Byrne, Blakley Expires 10 September 2000 [Page 14] Internet-Draft Access Control Model 10 March 2000 collection:[all]#group#cn=Dept XYZ,c=US means that this group (Dept XYZ) is granted permission to read and search all attributes except attr1 because attr1 is more specific than "[all]". 6.3.1 LDAP Operations 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. 6.3.2 Grant/Deny Evaluation Rules More specific policies must override less specific ones (e.g. individual user entry in ACI takes precedence over group entry). Deny takes precedence over Grant. When there are conflicting ACI values, deny takes precedence over grant. Deny is the default when there is no access control information. Precendence of Scope Types (highest to lowest) - entry - subtree Stokes, Byrne, Blakley Expires 10 September 2000 [Page 15] Internet-Draft Access Control Model 10 March 2000 Precedence of Privilege Attribute dnTypes within a scope (highest to lowest): - ipAddress - access-id, kerberosID (both same precedence) - group - role - subtree Although other types can be defined given the BNF, use of the well-known types aids in interoperability and operational consistency. 6.4 Policy Owner Attribute (policyOwner) ( NAME 'policyOwner' DESC 'Policy Owner Access Control Information' EQUALITY caseIgnoreMatch SYNTAX directoryString USAGE directoryOperation ) 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. 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. 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 Stokes, Byrne, Blakley Expires 10 September 2000 [Page 16] Internet-Draft Access Control Model 10 March 2000 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. 6.5 ACI Examples The examples use a family OID = 1.2.3.4 6.5.1 Attribute Definition The following two examples show an administrative subdomain being established. The first example shows a single user being assigned the policyOwner for the entire domain. The second example shows a group of IDs assigned to the policy Owner. policyOwner: 1.2.3.4#subtree#access-id#cn=Hoyt policyOwner: 1.2.3.4#subtree#group#cn=System Owners,o=Company 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. ldapACI:1.2.3.4#subtree#grant;r,s,c; attribute:attr1#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 attr2 and attr3. The permission applies to the entire subtree below the node containing this ACI. ldapACI: 1.2.3.4#subtree#grant;a; collection:[entry]#role#cn=SysAdmins,o=Company ldapACI: 1.2.3.4#subtree#grant;r,s,c; attribute:attr2#role#cn=SysAdmins,o=Company Stokes, Byrne, Blakley Expires 10 September 2000 [Page 17] Internet-Draft Access Control Model 10 March 2000 ldapACI: 1.2.3.4#subtree#grant;r,s,c; attribute:attr3#role#cn=SysAdmins,o=Company 6.5.2 Modifying the ldapACI Values Modify-Replace works as defined in the ldap oepration 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: 1.2.3.4#subtree#deny;r,w; collection:[all]#group#cn=Dept ABC ldapACI: 1.2.3.4#subtree#grant;r; attribute:attr1#group#cn=Dept XYZ perform the following change: dn: cn=someEntry changetype: modify replace: ldapACI ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[all];#group#cn=Dept LMN The resulting ACI is: ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[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: 1.2.3.4#subtree#grant;r,w; collection:[all]#group#cn=Dept XYZ with a modification: Stokes, Byrne, Blakley Expires 10 September 2000 [Page 18] Internet-Draft Access Control Model 10 March 2000 dn: cn=someEntry changetype: modify add: ldapACI ldapACI: 1.2.3.4#subtree#grant;r; attribute:attr1#group#cn=Dept XYZ would yield an multi-valued aci of: ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[all]#group#cn=Dept XYZ ldapACI: 1.2.3.4#subtree#grant;r; attribute:attr1#group#cn=Dept XYZ To delete a particular ACI value, use the regular ldapmodify - delete syntax Given an ACI of: ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[all]#group#cn=Dept XYZ ldapACI: 1.2.3.4#subtree#grant;r; attribute:attr1#group#cn=Dept XYZ dn: cn = some Entry changetype: modify delete: ldapACI ldapACI: 1.2.3.4#subtree#grant;r; attribute:attr1#group#cn=Dept XYZ would yield a remaining ACI on the server of ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[all]#group#cn=Dept XYZ 6.5.3 Evaluation 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 7 for a discussion of the semantics of ldapACI entries when backing-store ACI administration is also used. Stokes, Byrne, Blakley Expires 10 September 2000 [Page 19] Internet-Draft Access Control Model 10 March 2000 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: 1.2.3.4#subtree#grant;r;attribute:attr1; #access-id#cn=jsmith,ou=ABC,o=XYZ,c=US ldapACI: 1.2.3.4#subtree#grant;w;attribute: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; access-id is higher precedence than group. Example #2 dn: o=XYZ, c=US ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr2; #group#cn=G1,ou=ABC,o=XYZ,c=US ldapACI: 1.2.3.4#subtree#grant;w;attribute: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 dnTypes (group) have same precedence. Example #3 dn: o=XYZ, c=US ldapACI: 1.2.3.4#subtree#grant;r,w;attribute:attr3; #group#cn=G1,ou=ABC,o=XYZ,c=US ldapACI: 1.2.3.4#subtree#deny;w;attribute: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). Example #4 dn: o=XYZ, c=US ldapACI: 1.2.3.4#subtree#grant;w;attribute:attr4; #access-id#cn=jsmith,ou=ABC,o=XYZ,c=US ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr4; #subtree#ou=ABC,ou=XYZ,c=US Stokes, Byrne, Blakley Expires 10 September 2000 [Page 20] Internet-Draft Access Control Model 10 March 2000 What rights does cn=jsmith have to attr4 of o=XYZ, c=US? Write (w); rights given to an access-id take precedence over those given to a subtree. 7. 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). 7.1 Types of actions We consider five types of actions: - 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...). Stokes, Byrne, Blakley Expires 10 September 2000 [Page 21] Internet-Draft Access Control Model 10 March 2000 - Other operations: anything else, including Datastore operations which do not change the access policy enforced by the server. 7.2 Semantics of Histories The semantics of histories are defined as follows: - LDAP Update (Replace), LDAP Query 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 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. - 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 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 Stokes, Byrne, Blakley Expires 10 September 2000 [Page 22] Internet-Draft Access Control Model 10 March 2000 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 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. - LDAP Update (Deny), Other, 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), 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 Stokes, Byrne, Blakley Expires 10 September 2000 [Page 23] Internet-Draft Access Control Model 10 March 2000 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. - LDAP Update (Replace), Datastore Policy Update, LDAP Query The result of the Query is not defined. - LDAP Update (Grant), Datastore Policy Update, LDAP Query The result of the Query is not defined. - LDAP Update (Deny), Datastore Policy Update, LDAP Query The result of the Query is not defined. - LDAP Update (Replace), Datastore Policy Update, LDAP Access Request The result of the Access Request is not defined. - 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 The result of the Access Request is not defined. Stokes, Byrne, Blakley Expires 10 September 2000 [Page 24] Internet-Draft Access Control Model 10 March 2000 8. Access Control Parameters for LDAP Controls & Extended Operations This section defines the parameters used in the access 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. 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). family specifies the family OID that will be retrieved for the get effective rights control or extended operation performed. A family has a defined set of rights, among other things. rights in the get effective rights control or extended operation response is of the form specified in the BNF for . dnType speficies the type of subject security attribute. Defined types are specified in the BNF. 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. The well-known subjectDNs strings are defined - public - meaning public access for all users - this - meaning the user whose name matches the entry being accessed - * - meaning everyone who has access to the entry Stokes, Byrne, Blakley Expires 10 September 2000 [Page 25] Internet-Draft Access Control Model 10 March 2000 9. 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 get/set while manipulating other directory information for that entry. The control is: - getEffectiveRights to obtain the effective rights for a given directory entry(s) for a given subject during a ldap_search operation 9.1 getEffectiveRights Control 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]. The controlType is set to . The criticality MAY be either TRUE or FALSE (where absent is also equivalent to FALSE) at the client's option. The controlValue is an OCTET STRING, whose value is the BER encoding of a value of the following SEQUENCE: getEffectiveRightsRequest ::= SEQUENCE { effectiveRightsRequest SEQUENCE OF SEQUENCE { family LDAPOID | "*", whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, dnType "access-id"|"group"|"role"| "ipAddress"|"kerberosID"| | "*", subjectDN LDAPString | "public" | "this" | "*" } } The effectiveRightsRequest is a set of sequences that state the whichObject (entry or entry plus subtree) and Stokes, Byrne, Blakley Expires 10 September 2000 [Page 26] Internet-Draft Access Control Model 10 March 2000 specifics of the control request to be performed. One or more family can be be obtained for a given subjectDN ad dnType. A "*" in the family field indicates that the rights for all families defined for the subjectDN / dnType are to be returned. A "*" in 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. So the attributes/values returned are defined by the ldap_search operation. 9.1.2 Response Control This control is included in the ldap_search_response message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. The controlType is set to . There is no need to set the criticality on the response. The controlValue is an OCTET STRING, whose value is the BER encoding of a value of the following SEQUENCE: getEffectiveRightsResponse ::= { result ENUMERATED { success (0), operationsError (1), unavailableCriticalExtension (12), noSuchAttribute (16), undefinedAttributeType (17), invalidAttributeSyntax (21), insufficientRights (50), unavailable (52), unwillingToPerform (53), other (80) } } The effective rights returned are returned with each entry returned by the search result. The control response for ldap_search is: PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE { family LDAPOID, rights in BNF>, whichObject ENUMERATED { Stokes, Byrne, Blakley Expires 10 September 2000 [Page 27] Internet-Draft Access Control Model 10 March 2000 LDAP_ENTRY (1), LDAP_SUBTREE (2) }, dnType "access-id"|"group"| "role"|"ipAddress"| "kerberosID"| | "*", subjectDN LDAPString | "public" | "this" | "*" } Although this extends the search operation, there are no incompatibilities between versions. LDAPv2 cannot send a control, hence the above structure cannot be returned to a LDAPv2 client. A LDAPv3 client cannot send this request to a LDAPv2 server. A LDAPv3 server not supporting this control cannot return the additional data. 9.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 Stokes, Byrne, Blakley Expires 10 September 2000 [Page 28] Internet-Draft Access Control Model 10 March 2000 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 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. Stokes, Byrne, Blakley Expires 10 September 2000 [Page 29] Internet-Draft Access Control Model 10 March 2000 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. 10. 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. 10.1 LDAP Get Effective Rights Operation ldapGetEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] , requestValue [1] OCTET STRING OPTIONAL } where requestValue ::= SEQUENCE { targetDN LDAPDN, updates SEQUENCE OF SEQUENCE { family LDAPOID | "*", whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, attr SEQUENCE { attr in BNF > }, dnType "access-id"|"group"| "role"|"ipAddress"| "kerberosID"| | "*", subjectDN LDAPString | "public" | "this" | "*" } } Stokes, Byrne, Blakley Expires 10 September 2000 [Page 30] Internet-Draft Access Control Model 10 March 2000 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] OPTIONAL, effectiveRights [11] OCTET STRING OPTIONAL } where effectiveRights ::= SEQUENCE OF SEQUENCE { family LDAPOID, rights in BNF>, whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, dnType "access-id"|"group"|"role"| "ipAddress"|"kerberosID"| , subjectDN LDAPString | "public" | "this" } If the server does not recognize the request name, it MUST return only the response fields from LDAPResult, containing the protocolError result code. 11. 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. Stokes, Byrne, Blakley Expires 10 September 2000 [Page 31] Internet-Draft Access Control Model 10 March 2000 12. 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 [REQTS] Stokes, Byrne, Blakley, "Access Control Requirements for LDAP", INTERNET-DRAFT , February 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. AUTHOR(S) ADDRESS 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 mail-to: djbyrne@us.ibm.com phone: +1 512 838 1960 fax: +1 512 838 8597 Stokes, Byrne, Blakley Expires 10 September 2000 [Page 32] Internet-Draft Access Control Model 10 March 2000 Stokes, Byrne, Blakley Expires 10 September 2000 [Page 33] CONTENTS 1. Introduction....................................... 2 2. Overview........................................... 2 3. Terminology........................................ 4 4. The Model.......................................... 6 4.1 Access Control Information Model............. 6 5. Access Control Mechanism Attributes................ 8 5.1 Root DSE Attribute for Access Control Mechanism.................................... 8 5.2 Subschema Attribute for Access Control Mechanism.................................... 8 6. Access Control Information Attributes.............. 9 6.1 The BNF...................................... 10 6.2 Other Defined Parameters..................... 11 6.2.1 Families and Rights 11 6.2.2 DN Types 12 6.3 Basic ACI Attribute (ldapACI)................ 13 6.3.1 LDAP Operations 15 6.3.2 Grant/Deny Evaluation Rules 15 6.4 Policy Owner Attribute (policyOwner)......... 16 6.5 ACI Examples................................. 17 6.5.1 Attribute Definition 17 6.5.2 Modifying the ldapACI Values 18 6.5.3 Evaluation 19 7. Operational Semantics of Access Control Operations......................................... 21 7.1 Types of actions............................. 21 7.2 Semantics of Histories....................... 22 8. Access Control Parameters for LDAP Controls & Extended Operations................................ 25 9. Access Control Information (ACI) Controls.......... 26 9.1 getEffectiveRights Control................... 26 9.1.1 Request Control 26 9.1.2 Response Control 27 9.1.3 Client-Server Interaction 28 - i - 10. Access Control Extended Operation.................. 30 10.1 LDAP Get Effective Rights Operation.......... 30 11. Security Considerations............................ 31 12. References......................................... 32 - ii - 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 -