Internet-Draft E. Stokes LDAP Extensions WG D. Byrne Intended Category: Standards Track B. Blakley Expires: 25 December 1999 IBM 25 June 1999 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) directory service. It includes a description of the Stokes, Byrne, Blakley Expires 25 December 1999 [Page 1] Internet-Draft Access Control Model 25 June 1999 model, the LDAP controls, and the extended operations to the LDAP protocol. A separate document defines the corresponding application programming interfaces (APIs). RFC2219 [Bradner97] terminology is used. 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 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). A separate document defines the corresponding application programming interfaces (APIs). 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. This proposal defines the protocol elements for transmission of this access control policy data in an LDAP environment and an attribute that defines the access control mechanism in effect for a given part of the LDAP namespace. The instantiation of an access control model Stokes, Byrne, Blakley Expires 25 December 1999 [Page 2] Internet-Draft Access Control Model 25 June 1999 at the directory server is not defined in this document. By defining only what flows on the wire allows existing access control mechanisms to be used at the directory server. 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. The access control model defines - A wire protocol for interoperability: The existing LDAP protocol flows for add, delete, modify, etc are used to manipulate access control information. There are additional LDAP controls and extended protocol operations defined to further help management of access control information: getEffectiveRights and specifyCredentials. - A set of access control information (ACI) attributes for application portability: These attributes are used as input to the LDAP APIs so access control information can be addressed uniformly independent of how that information is addressed and stored at the server. These same attributes appear in LDIF output for interchange of access control information. - A set of attributes to identity the access control mechanisms supported by a server. Encoding of access control information on the wire is per the LDAPv3 specifications. Stokes, Byrne, Blakley Expires 25 December 1999 [Page 3] Internet-Draft Access Control Model 25 June 1999 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 policy information" (acpi) for an object or a collection of objects defines which subject security attributes entitle a subject to which granted rights. The access control policy information for an object is 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 policy 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 25 December 1999 [Page 4] Internet-Draft Access Control Model 25 June 1999 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. An "object" is the target of operations in an information system. An "operation" is the result of executing the code accessed through a named entry point in an information system. An "operation name" is the name of the entry point through which an operation is invoked in an information system. 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 policy 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 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 5] Internet-Draft Access Control Model 25 June 1999 organizational position and entitlement to perform the operations appropriate to that organizational position. A "subject" is an entity which intiates 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. 4. The Model 4.1 Access Control Activity Lifecycle The access control proposal described in this draft addresses four activities: - Creation of subject security attribute information and access control policy information - Retrieval of subject security attribute information at the time an access request is made - Evaluation of access requests against policy, resulting in an access decision - Replication of access control policy information from one server to another 4.2 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 25 December 1999 [Page 6] Internet-Draft Access Control Model 25 June 1999 The diagram below illustrates the componentry of an LDAP system and the placement of the function specified in this draft. +-------------+ | Application | +-------------+ +--------+ | LDAP | | Client | +--------+ | | | <-- LDAP Extended Access Control Controls | or Extended Access Control Operations v +-----------------------------+ | LDAP Server (e.g. SLAPD) | +-----------------------------+ . | . | . | . | v v +----------+ +-----------+ | Access | | | | Control |<.....| Datastore | | Manager | | | +----------+ +-----------+ LDAP clients use the controls and extended operations specified in this document to administer access control policy enforced by LDAP servers. Servers may store access control information in any way they choose. In particular, servers may use the access control mechanisms of their datastores to store and enforce LDAP access control, or they may implement access control managers external to their datastores. Datastores and external access control managers may implement any access control rule syntax and semantics they choose, as long as the semantics is compatible with that defined in the section titled "Operational Semantics of Access Control Operations" (found after the control and extended Stokes, Byrne, Blakley Expires 25 December 1999 [Page 7] Internet-Draft Access Control Model 25 June 1999 operation definition). The access control administration mechanisms specified in this document are neutral with respect to policy inheritance mechanisms, explicit vs. implicit denial, and group nesting. 4.3 Bind and Credentials A bind authenticates a principal to the directory. A principal is represented by a DN. A principal has a set of credentials that are used for determining whether access to resources specified in ldap operations. These credentials may be pushed to the server by the client or may be pulled by the server from the directory data. Credentials may be local with respect to the server. If not local (owned by another server or administrative scope), then the server may decide to define a trust model that states how to evaluate the trust of a credential at bind time. The definition of such a trust model is outside the scope of this document. 5. Access Control Information Schema 5.1 Attributes 5.1.1 Root DSE Attribute for Access Control Mechanism The following attribute may be included in the Root DSE. ( NAME 'supportedACIMechanisms' DESC list of access control mechanisms supported by this directory server SYNTAX LDAPOID ) Two access control mechanisms are defined by this document: LDAPv3 X500 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 8] Internet-Draft Access Control Model 25 June 1999 Other vendor access control mechanisms can be defined (by OID) and are the responsibility of those vendors to provide the definition and OID. 5.1.2 Subschema Attribute for Access Control Mechanism A given naming context must provide information about which access control mechanism is in effect for that portion of the namespace. The following attribute must be in each subschema entry associated with a naming context whose access control mechanism is different from adjacent naming contexts supported by that directory server. - aCIMechanism lists the value (an OID) that defines the access control mechanism in effect for the scope of that subschema entry 5.2 Other Defined Parameters/OIDs 5.2.1 Rights Families and Rights The following rights families are defined: LDAPv3 X500 Other parties can (and will) define other rights families. It is the responsibility of those parties to provide the definition and OID. 5.2.1.1 LDAPv3 Rights Family Access rights can apply to an entire object or to attributes of the object. Each of the LDAP access rights are discrete. One permission does not imply another permission. The rights may be ORed together to provide the desired rights list. Rights which apply to attributes are: 1 Read Read attribute values 2 Write Write attribute values 4 Search Search entries with specified attributes 8 Compare Compare attributes Stokes, Byrne, Blakley Expires 25 December 1999 [Page 9] Internet-Draft Access Control Model 25 June 1999 Rights that apply to an entire object are: 16 Add Add an object below this object 32 Delete Delete this object 64 EditDN Edit an object's DN Rights that apply to the object to which the directory object points are: 128 Manage Perform a privileged operation; used to restrict access to operations which read or write especially sensitive data 256 Use Execute; useful in controlling access to the objects referred to by directory entries than in controlling access to the directory entries themselves 512 Get Get retrieves the attribute values 1024 Set Set writes the attribute values 5.2.1.2 The X.500 Rights Family 5.2.2 DN Types The following DN Types are defined: - access-id, OID= - group, OID= - role, OID= access-id, group, and role MUST be supported. An acess- id is a non-collection (non-group and non-role objects) DN that can be authenticated. Other parties can (and will) define other DN Types. It is the responsibility of those parties to provide the definition and OID. Stokes, Byrne, Blakley Expires 25 December 1999 [Page 10] Internet-Draft Access Control Model 25 June 1999 6. 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 which is get/set is for the target directory entry (ENTRY) or the target directory entry and its subtree (SUBTREE). rightsFamily specifies the family of rights that will be get/set for the control or extended operation performed. A rights family has a defined set of rights. rightsList in the SearchResultEntry is of the form specified in the LDIF BNF for . dnType speficies the type of subject security attribute. Defined types are access-id, group, and role. subjectDN is a LDAP string that defines the subject or value of the dnType. The subjectDN may be a DN or another string such as IPAddress (dotted-decimal string representation) on which access control is get/set. If the subject is an entry in the directory, then the syntax of the LDAP string is DN. We define two well-known subjectDNs, the strings - public - meaning public access for all users - this - meaning the user whose name matches the entry being accessed Four operations are defined: - ACI_GRANT grants the rights specified in the rightsList for the given subject. If an access control list does not exist for the specified entry/attribute, then the access control list is Stokes, Byrne, Blakley Expires 25 December 1999 [Page 11] Internet-Draft Access Control Model 25 June 1999 created with the granted rights for the given subject. If the access control list already exists for the specified entry/attribute, then the access control list is modified to grant the rights for the given subject. - ACI_DENY denies the rights specified in the rightsList for the given subject. No implementation is implied for this operation. For example, denial of rights may be implemented as explicit denial (negative rights) on the access control list or removal of rights from the access control list. - ACI_REPLACE replaces the entire access control list for the specified entry/attribute. If an access control list does not exist for the specified entry/attribute, then the access control list is created with the granted rights for the given subject. - ACI_DELETE deletes the entire access control list for the specified entry/attribute. attrs specifies the list of attributes against which the operation is performed. attrs can be defined using a LDAP filter expression. 7. Access Control Information (ACI) Controls The access control information controls provide a way to manipulate access control information in conjunction with an LDAP operation such as ldap_add, ldap_modify, or ldap_search. Three LDAP controls are defined for transmission of access control information. These controls allow access control information to be get/set while manipulating other directory information. The controls are: - getEffectiveRights to obtain the effective rights for a given directory entry(s) for a given subject during a ldap_search operation - specifyCredentials to specify a set of credentials for the bind identity (DN) during a ldap_bind Stokes, Byrne, Blakley Expires 25 December 1999 [Page 12] Internet-Draft Access Control Model 25 June 1999 operation 7.1 getEffectiveRights Control 7.1.1 Request Control This control is 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 { targetDN LDAPDN, effectiveRightsRequest SEQUENCE OF SEQUENCE { rightsFamily LDAPOID | "*", whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, dnType LDAPOID | "*", subjectDN LDAPString, } } The targetDN specifies the initial directory entry in DN syntax on which the getEffectiveRights control is performed. request is a set of sequences that state the whichObject (entry or entry plus subtree) and specifics of the control request to be performed. One or more rightsFamily can be be obtained for a given subjectDN ad dnType. A "*" in the rightsFamily field indicates that the rights for all rights families defined for the subjectDN / dnType are to be returned. This control is applied to the scope set by the ldap_search operation, i.e. base, one-level, subtree. 7.1.2 Response Control This control is included in the ldap_search_response Stokes, Byrne, Blakley Expires 25 December 1999 [Page 13] Internet-Draft Access Control Model 25 June 1999 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). 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), 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 { rightFamily LDAPOID, rightsList ENUMERATED, whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) } } Although this extends the search operation, there are no incompatibilities between versions. LDAPv2 cannot send a control, hence the above structure cannot be returned to a LDAPv2 client. A LDAPv3 client cannot send this request to a LDAPv2 server. A LDAPv3 server not supporting this control cannot return the additional data. Stokes, Byrne, Blakley Expires 25 December 1999 [Page 14] Internet-Draft Access Control Model 25 June 1999 7.1.3 Client-Server Interaction The getEffectiveRightsRequest control requests the rights that MUST be in effect for requested directory entry/attribute based on the subject DN. The server that consumes the search operation looks up the rights for the returned directory information based on the subject DN and returns that rights information. There are six possible scenarios that may occur as a result of the getEffectiveRights control being included on the search request: 1. If the server does not support this control and the client specified TRUE for the control's criticality field, then the server MUST return unavailableCriticalExtension as a return code in the searchResponse message and not send back any other results. This behavior is specified in section 4.1.12 of [LDAPv3]. 2. If the server does not support this control and the client specified FALSE for the control's criticality field, then the server MUST ignore the control and process the request as if it were not present. This behavior is specified in section 4.1.12 of [LDAPv3]. 3. If the server supports this control but for some reason such as cannot process specified rightsFamily and the client specified TRUE for the control's criticality field, then the server SHOULD do the following: return unavailableCriticalExtension as a return code in the searchResult message. 4. If the server supports this control but for some reason such as cannot process specified rightsFamily and the client specified FALSE for the control's criticality field, then the server should process as 'no rights returned for that family' and include the result Unavailable in the getEffectiveRightsResponse control in the searchResult message. Stokes, Byrne, Blakley Expires 25 December 1999 [Page 15] Internet-Draft Access Control Model 25 June 1999 5. If the server supports this control and can return the rights per the rightsFamily information, then it should include the getEffectiveRightsResponse control in the searchResult message with a result of success. 6. If the search request failed for any other reason, then the server SHOULD omit the getEffectiveRightsResponse control from the searchResult message. The client application is assured that the correct rights are returned for scope of the search operation if and only if the getEffectiveRightsResponse control returns the rights. If the server omits the getEffectiveRightsResponse control from the searchResult message, the client SHOULD assume that the control was ignored by the server. The getEffectiveRightsResponse control, if included by the server in the searchResponse message, should have the getEffectiveRightsResult set to either success if the rights are returned or set to the appropriate error code as to why the rights could not be returned. The server may not be able to return a right because it may not exist in that directory object's attribute; in this case, the rights request is ignored with success. 7.2 specifyCredentials Control 7.2.1 Request Control This control is included in the ldap_bind message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. The controlType is set to . The criticality MAY be either TRUE or FALSE (where absent is also equivalent to FALSE) at the client's option. The controlValue is an OCTET STRING, whose value is the BER encoding of a value of the following SEQUENCE: specifyCredentialRequest ::= SEQUENCE { Stokes, Byrne, Blakley Expires 25 December 1999 [Page 16] Internet-Draft Access Control Model 25 June 1999 credential LDAPString } } The credential specifies the credential (e.g. groups, roles, etc) that the client is requesting be associated with the bind DN for access control determination in subsequent ldap operations. This provides a 'push' model for credentials where the client attempts to 'push' the credential to the server. The server may process at bind time as follows: - server may unconditionally ignore - server may unconditionally accept - server may define trust model and evaluate of the trust of each credential If this control is not used, it is assumed that the server determines (pulls) the credentials associated with the bind DN when needed in subsequent ldap operations to provide access control. 7.2.2 Response Control This control is included in the ldap_bind message as part of the controls field of the LDAPMessage, as defined in 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). The controlValue is an OCTET STRING, whose value is the BER encoding of a value of the following SEQUENCE: specifyCredentialsResponse ::= { result ENUMERATED { success (0), operationsError (1), unavailableCriticalExtension (12), unavailable (52), unwillingToPerform (53), other (80) } Stokes, Byrne, Blakley Expires 25 December 1999 [Page 17] Internet-Draft Access Control Model 25 June 1999 } No data is returned; just the result is returned. Although this extends the bind operation, there are no incompatibilities between versions. LDAPv2 cannot send a control. A LDAPv3 client cannot send this request to a LDAPv2 server. A LDAPv3 server not supporting this control cannot return the additional data. 7.2.3 Client-Server Interaction The specifyCredentialsRequest control specifies the credentials that the client wants the server to use for access control in subsequent ldap operations. The server that consumes the bind operation may unconditionally accept, ignore, or evaluate the trust of the specified credentials at bind time and returns only a success or failure response (no data returned). There are six possible scenarios that may occur as a result of the specifyCredential control being included on the bind request: 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 bindResponse message. This behavior is specified in section 4.1.12 of [LDAPv3]. 2. If the server does not support this control and the client specified FALSE for the control's criticality field, then the server MUST ignore the control and process the request as if it were not present. This behavior is specified in section 4.1.12 of [LDAPv3]. 3. If the server supports this control but for some reason such as cannot process specified credential (e.g. server decided to evaluate the trust of that credential and the result is the server not trusting all the credentials or unconditionally ignores the credential) and the client specified Stokes, Byrne, Blakley Expires 25 December 1999 [Page 18] Internet-Draft Access Control Model 25 June 1999 TRUE for the control's criticality field, then the server SHOULD do the following: return unavailableCriticalExtension as a return code in the bindResult message and omit the specifyCredentialResponse control in the bindResult message. 4. If the server supports this control but for some reason such as cannot process specified credential (e.g. server decided to evaluate the trust of that credential and the result is the server not trusting all the credentials or unconditionally ignores the credential) and the client specified FALSE for the control's criticality field, then the server should process as 'credential ignored' and include the result Unavailable in the specifyCredentialResponse control in the bindResult message. 5. If the server supports this control and evaulates the trust of that credential and the result is the server trusting all the credentials, then it should include the specifyCredentialResponse control in the bindResult message with a result of success. 6. If the bind request failed for any other reason, then the server SHOULD omit the specifyCredentialResponse control from the bindResult message. The client application is assured that the correct credentials are used by the server when specified by the client for subsequent ldap operations if and only if the specifyCredentialResponse is successful. If the server omits the specifyCredentialResponse control from the bindResponse message, the client SHOULD assume that the control was ignored by the server. The specifyCredentialResponse control, if included by the server in the bindResponse message, should have the bindResult set to either success if the credentials were accepted by the server or set to the appropriate error code as to why the credentials were not accepted. Stokes, Byrne, Blakley Expires 25 December 1999 [Page 19] Internet-Draft Access Control Model 25 June 1999 8. Access Control Extended Operations Two extended operations (analogous to the controls) are defined for transmission of access control information. These operations help with the management of access control information independent of manipulating other directory information. The extended operations are: - LDAP Get Effective Rights to obtain the effective rights for a given directory entry for a given subject 8.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 { rightsFamily LDAPOID | "*", whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, dnType LDAPOID | "*", subjectDN LDAPString, } } 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. ldpGetEffectiveRightsResponse ::= [APPLICATION 24] SEQUENCE { Stokes, Byrne, Blakley Expires 25 December 1999 [Page 20] Internet-Draft Access Control Model 25 June 1999 COMPONENTS OF LDAPResult, responseName [10] OPTIONAL, effectiveRights [11] OCTET STRING OPTIONAL } where effectiveRights ::= SEQUENCE OF SEQUENCE { rightFamily LDAPOID, rightsList ENUMERATED, whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, subjectDnType LDAPOID, subjectDN LDAPSTRING } If the server does not recognize the request name, it MUST return only the response fields from LDAPResult, containing the protocolError result code. 9. Access Control Information Attributes/LDIF 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 not defined here. What 'deny' means on server1 might be different than on server2. Additionally, while the server must recognize and act on the attribute when received over the wire, there are no requirements for the server to actually implement this attribute. The attribute definition maintains an assumption that the receiving server supports inheritance within the security Stokes, Byrne, Blakley Expires 25 December 1999 [Page 21] Internet-Draft Access Control Model 25 June 1999 model. If the server does not support inheritance, the receiving server must expand any inherited information based on the scope flag. 9.1 ACI Attributes There are three attributes which may be queried or set on all directory objects: aci, vendorAci and policyOwner. The syntax of these attributes is defined below. 9.1.1 The BNF < aci > ::= < acl syntax > < vendorAci > ::= + '#' + < printable string > < acl syntax > ::= + '#' + + '#' + < rights > + '#' + < dnType > + '#' + < subjectDn > < policyOwner > ::= < familyOid > + '#' + + '#' +< dnType > + '#' + < subjectDn > < subjectDn > ::= < printable string > < familyOid > ::= < oid > ::= "entry" | "subtree" | < level > ::= numericstring < dnType > ::= "access-id" | "role" | "group" < rights > ::= [ ] | [ < right > + [ '$' + ] * ] < right > ::= + ';' + + ';' + < action > ::= "grant" | "deny" < permissions > ::= [ ] | [ < permission > + [ ',' + ] * ] Stokes, Byrne, Blakley Expires 25 December 1999 [Page 22] Internet-Draft Access Control Model 25 June 1999 < attrs > ::= [ < attributeString> + [ ',' + < attributeString > ] * ] < attributeString > ::= "[all]" | "[entry]" | < permission > ::= "a" | "d" | "r" | "s" | "w" | "c" | "g" | "s" | "m" | "u" | "e" These are the permissions defined for the IETF family OID. "a" corresponds to add "d" corresponds to delete "r" corresponds to read "w" corresponds to write "c" corresponds to compare "g" corresponds to get "s" corresponds to set "m" corresponds to manage "u" corresponds to use "e" corresponds to editDn 9.1.2 VendorACI ( vendorAciOID NAME 'vendorACI' DESC 'Vendor specific Access control information' EQUALITY caseIgnoreMatch SYNTAX directoryString ) The Vendor specific ACI information is listed in its own attribute. This may be used by vendors to provide vendor specific access control related information which can not be expressed in defined ACISyntax. Within the vendorACI, the oid determines the format or the printable string to follow. 9.1.3 Policy Owner ( policySyntaxOID DESC 'PolicyOwner Syntax' ) ( policyOwnerOID NAME 'policyOwner' DESC 'Policy Owner Access Control Information' EQUALITY caseIgnoreMatch SYNTAX policySyntaxOID ) 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 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 23] Internet-Draft Access Control Model 25 June 1999 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 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. 9.1.4 ACI ( aciSyntaxOID DESC 'ACI Syntax' ) ( aciOID NAME 'aci' DESC 'Access control information' EQUALITY caseIgnoreMatch SYNTAX aciSyntaxOID ) Within the access control syntax, the family OID describes the permissions, dnType, subjectDn and scope that will be found in the following string. If the OID within the ACI attribute is listed as other than the IETF family oid, the syntax is the same as listed below, but one or more of the scope, dnType, subjectDn or permissions may vary from the IETF defined syntax. Within the access control syntax, there is a string which describes the rights. This is a composite of the permissions and resources to which the user is being granted or denied access. The set of permissions is fixed. Either of the actions "grant" | "deny" may be used when creating or updating ACI. The attributeString is an attribute Name (defined to be a printable string). If the string refers to an attribute not defined in the given server's schema, the server SHOULD report an error. Another option for the attributeString is Stokes, Byrne, Blakley Expires 25 December 1999 [Page 24] Internet-Draft Access Control Model 25 June 1999 "[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 attributeString is "[all]" which means the permission set should apply to all attributes. 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]". If two ACIs contain identical familyOID, scope, DnTypes and DNs, the permission given DN is specified in two distinct acis on any given entry, the rights lists can be combined into one list. For example, aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ is the equivalent of aci: 1.2.3.4#subtree#grant;r,w;[all]; r,attribute1#group#cn=Dept XYZ Using the defined BNF it is possible for the permission string to be empty. The ACI aci: 1.2.3.4#subtree#grant;;attribute1$grant;r,s; [all]#group#cn=Dept XYZ,c=US means that this group is granted permission to read and search all attributes except attribute1. Similarly, the ACI aci: 1.2.3.4#subtree##group#cn=Dept XYZ, c=US simply means that no permissions have been defined for this group. It is up to the server implementation as to whether the group does or does not receive permission to attributes on an entry with an empty rights list. Multiple attributeStrings can be listed after any given permission set; for instance, "r,w ; attribute1, attribute2". This means that if the server supports a Stokes, Byrne, Blakley Expires 25 December 1999 [Page 25] Internet-Draft Access Control Model 25 June 1999 attribute aggregation mechanism, attribute1 and attribute2 should be considered to be part of the same group. If the server does not support a grouping mechanism, the permission set applies independently to attribute1 and attribute2. For servers that do not support attribute grouping, "grant ; r,w ; attribute1, attribute2" results in the same operations as "grant ; r,w; attribute1$grant; r,w; attribute2" 9.1.5 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: aci In this case, the entry would then inherit its ACI from some other node in the tree depending on the server inheritance model. Deleting the last ACI value from an entry is not the same as deleting the ACI from the entry. It is possible for an entry to contain an ACI with no values. In this case, nothing is returned to the client when querying the aci. It is server dependent whether access is granted or denied in the absence of any ACI information. Deleting an ACI value which does not exist will result in an unchanged ACI and a return code specifying that the attribute value does not exist. 9.2 Examples 9.2.1 Attribute Definition Pretend IETFFamilyOID = 1.2.3.4 The following two examples show an administrative subdomain being established. The first example shows a single user being assigned the policyOwner for the entire Stokes, Byrne, Blakley Expires 25 December 1999 [Page 26] Internet-Draft Access Control Model 25 June 1999 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 an aci attribute where a group "cn=Dept XYZ, c=US" is being given permissions to read, search and compare attribute1. The permission should apply to the entire subtree below the node containing this ACI. aci:1.2.3.4#subtree#grant;r,s,c; attribute1#group#cn=Dept XYZ,c=US The next example shows an ACI attribute where a role "cn=SysAdmins,o=Company" is being given permissions to add objects below this node, and read, search and compare attributes 2 and 3. The permission should apply to the entire subtree below the node containing this ACI. aci: 1.2.3.4#subtree#grant;a;[entry]$grant; r,s,c;attribute2, attribute3#role# cn=SysAdmins,o=Company 9.2.2 Modifying the ACI Values Replace works similarly to all other attributes. If the attribute value does not exist, create the value. If the attribute does exist, replace the value. If the ACI value is replaced, all ACI values are replaced. A given aci for an entry: aci: 1.2.3.4#subtree#deny;r,w;[all]$grant;r,s,c; attribute2#group#cn=Dept ABC aci: 1.2.3.4#subtree#grant;r;[all]$grant;r,s,c; attribute1#group#cn=Dept XYZ perform the following change: Stokes, Byrne, Blakley Expires 25 December 1999 [Page 27] Internet-Draft Access Control Model 25 June 1999 dn: cn=someEntry changetype: modify replace: aci aci: 1.2.3.4#subtree#grant;r,w;[all];#group#cn=Dept LMN The resulting acl is: aci: 1.2.3.4#subtree#grant;r,w;[all];#group#cn=Dept LMN ( aci values for Dept XYZ and ABC are lost through the replace ) During an ldapmodify-add, if the ACI does not exist, the create the ACI with the specific aci value(s). If the ACI does exist, then add the specified values to the given ACI. For example a given ACI: aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ with a modification: dn: cn=someEntry changetype: modify add: aci aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ would yield an multi-valued aci of: aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ To delete a particular aci value, use the regular ldapmodify - delete syntax Given an ACI of: aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ dn: cn = some Entry changetype: modify delete: aci aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ would yield a remaining ACI on the server of Stokes, Byrne, Blakley Expires 25 December 1999 [Page 28] Internet-Draft Access Control Model 25 June 1999 aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ 10. Security Considerations This draft 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. 11. 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 , August 1998. [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 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 29] Internet-Draft Access Control Model 25 June 1999 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 25 December 1999 [Page 30] Internet-Draft Access Control Model 25 June 1999 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 31] CONTENTS 1. Introduction....................................... 2 2. Overview........................................... 2 3. Terminology........................................ 4 4. The Model.......................................... 6 4.1 Access Control Activity Lifecycle............. 6 4.2 Access Control Information Model.............. 6 4.3 Bind and Credentials.......................... 8 5. Access Control Information Schema.................. 8 5.1 Attributes.................................... 8 5.1.1 Root DSE Attribute for Access Control Mechanism 8 5.1.2 Subschema Attribute for Access Control Mechanism 9 5.2 Other Defined Parameters/OIDs................. 9 5.2.1 Rights Families and Rights 9 5.2.2 DN Types 10 6. Access Control Parameters for LDAP Controls & Extended Operations................................ 11 7. Access Control Information (ACI) Controls.......... 12 7.1 getEffectiveRights Control.................... 13 7.1.1 Request Control 13 7.1.2 Response Control 13 7.1.3 Client-Server Interaction 15 7.2 specifyCredentials Control.................... 16 7.2.1 Request Control 16 7.2.2 Response Control 17 7.2.3 Client-Server Interaction 18 8. Access Control Extended Operations................. 20 8.1 LDAP Get Effective Rights Operation........... 20 10. Security Considerations............................ 29 11. References......................................... 29 - i - 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. - ii -