Internet-Draft B. Blakley LDAP Extensions WG D. Byrne Intended Category: Standards Track E. Stokes Expires: 27 September 1998 IBM 27 March 1998 Access Control Model for LDAP STATUS OF THIS MEMO This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 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 ABSTRACT This document describes the access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. It includes a description of the 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. Blakley, Byrne, Stokes [Page 1] Internet-Draft ACL Model 27 March 1998 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 directory attribute formats, encodings, and protocol elements for storage and transmission of this access control policy data in an LDAP environment. 2.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 Blakley, Byrne, Stokes [Page 2] Internet-Draft ACL Model 27 March 1998 - 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 2.2 Access Control Information Model In support of the lifecycle activities described in the previous section, This proposal defines two types of access control information. 1. Subject Security Attribute Information (ssai) Subject security attribute information enumerates the security-relevant characteristics which entitle subjects to rights in a system. Subject security attribute information is associated with subjects. Each subject must have an LDAP directory entry, and a subject's security attribute information is stored as attributes of its directory entry. 2. Access Control Policy Information (acpi) Access control policy information defines the rules which govern access to objects in a system. Access control policy information is associated with objects. Objects are LDAP directory entries. Access control policy information is stored in attributes of the directory entries to which it applies. 2.3 Access Control System Structure The following diagram depicts the functional components of the LDAP access control system, and illustrates the use of access control information to implement the access control lifecycle activities described above. Blakley, Byrne, Stokes [Page 3] Internet-Draft ACL Model 27 March 1998 +---------+ | admin | | console | +---------+ | 1. set privileges, policy (ssai, acpi) | +--------+ +--------------+ | client | | LDAP | | |- 5. access ->| server |- 9. replicate +--------+ request +--------------+ (acpi, ^ (ssai) | ^ | ssai) | | | 7. check | | | | access | | | | (ssai) v 3. logon | | | +------+ (ssai) 2. store | v | LDAP | | privileges, | +--(adfi)--+ | srvr | +--------+ policy | | access | +------+ | auth'n | (ssai, acpi) | | decision | | server | | | | function | +--------+ | 6. get +----------+ ^ | privs ^ | | (ssai) | | | | | | | | 8. get | | | policy | | | (acpi) | v | | | +----------------+ +-- 4. get -------| LDAP | privileges | repository | (ssai) +----------------+ To enable the system to enforce access control, a security administrator must assign security attributes to the system's subjects and state the policy rules which will govern access to the system's objects. The administrator does this through the user interface of a security administration tool, which then encodes the resulting policy information and sends it to an LDAP Blakley, Byrne, Stokes [Page 4] Internet-Draft ACL Model 27 March 1998 server for storage. Sending subject security attribute information (ssai) from the administrative console to the LDAP server requires definition of an encoding and protocol elements for ssai. Sending access control policy information (acpi) from the administrative console to the LDAP server requires definition of an encoding and protocol elements for acpi. (This is represented by the arrow labelled 1. in the diagram). The LDAP server must store the information it receives from the administrator in the directory's data respository. This requires definition of directory schema elements for ssai and acpi. (This is represented by the arrow labelled 2. in the diagram). When a subject starts to use an LDAP directory, the directory needs to determine what subject security attributes that subject is entitled to. This will normally involve authenticating the subject and returning an authenticated credential, containing one or more subject security attributes, to the LDAP client code. The authentication service which validates the user's logon needs to be able to retrieve ssai from the directory, and create a credential which can be consumed by the LDAP server or servers the subject needs to access (This is represented by the arrows labelled 3. and 4. in the diagram). When a subject issues a request to access a directory entry, the subject's LDAP client runtime needs to transmit the subject's credential to the LDAP server so that the server can use the subject security attribute information in the credential as input to the access decision it will have to make (This is represented by the arrow labelled 5. in the diagram). An LDAP server which receives a directory entry access request may choose to retrieve additional subject security attribute information (beyond that provided in the credential the client sent with the request) from the subject's directory entry. This might happen in two Blakley, Byrne, Stokes [Page 5] Internet-Draft ACL Model 27 March 1998 cases: when the directory server being accessed does not trust the authentication system which validated the subject's logon to vouch for subject security attributes, or when the directory server being accessed grants subject security attributes in addition to those stored in the directory server which authenticates subjects. (This is represented by the arrow labelled 6. in the diagram). An LDAP server which receives a directory entry access request needs to make an access decision to decide whether to accept or reject the request. To do this, the directory server needs to pass the subject's ssai, the object's DN, and the operation being invoked to an access decision function through an access decision function interface (adfi). The access decision function needs to retrieve the acpi for the specified object, and check to see whether the required rights needed to invoke the requested operation are in the granted rights of the acpi entries matching security attributes in the subject's ssai. In order to do this, it needs to retrieve the acpi for the target object from the directory (This is represented by the arrows labelled 7. and 8. in the diagram). When an LDAP server replicates data to another LDAP server, it needs to replicate the security policy attributes along with the other attributes of each directory entry. This requires transferring both ssai and acpi for each entry. (This is represented by the arrow labelled 9. in the diagram). 2.4 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. No subject security attribute appears in more than one access control list entry in the same access control list. 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. Blakley, Byrne, Stokes [Page 6] Internet-Draft ACL Model 27 March 1998 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 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. Blakley, Byrne, Stokes [Page 7] Internet-Draft ACL Model 27 March 1998 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 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. Blakley, Byrne, Stokes [Page 8] Internet-Draft ACL Model 27 March 1998 3. Subject Security Attribute Information This section defines the data structures used to describe subject security attribute information in support of LDAP Access Control. 3.1 Terminology A "security attribute" is a defined property which is used by a security policy evaluation system to make policy decisions. A "subject" is an entity which intiates actions in an information system. A "subject security attribute" is a defined property of a subject which is relevant to security. 3.2 Subject Security Attribute Properties Subject security attributes need to have a variety of properties: - Defining Authority Access control policies must sometimes distinguish between security attributes which share the same type-name but which have been defined by different organizations and which have different interpretations. for example, the Israeli MOSSAD and the United States CIA might both define an attribute type called CLEARANCE. The US CIA might then define a policy which says that subjects with CLEARANCE="SECRET" may access information classified as SECRET if their CLEARANCE attribute was defined by the US CIA, but may access only information classified as CONFIDENTIAL if their CLEARANCE attribute was defined by the Israeli MOSSAD. In order to allow access control subsystems to distinguish between attributes with the same type-name but different defining authorities, the defining authorities of security attribute types must be explicitly identified. Blakley, Byrne, Stokes [Page 9] Internet-Draft ACL Model 27 March 1998 - Type There are many different kinds of subject security attributes, including identities, groups, roles, and clearances. The namespaces (or identifier spaces) of different types of security attributes are not always disjoint; for example, a bank might have a ROLE attribute with the value "TELLER" and an employee named Edward Teller whose ACCESS_IDENTITY attribute also has the value "TELLER". For this reason, the types of security attributes must be explicitly identified. - Asserting Authority When making access control decisions, it is important for the access control subsystem to know the identity of the authority which has assigned an attribute to the requesting subject. For example, an access control subsystem will probably grant a request to access IBM resources initiated by a subject whose ROLE attribute has the value "CEO", asserted by "IBM". On the other hand, the same access control subsystem is unlikely to grant a request initiated by a subject whose ROLE attribute has the value "CEO", asserted by "JOE SMITH". In order to allow access control subsystems to determine whether they trust the authority asserting security attribute values, the asserting authorities of security attribute values must be explicitly identified. - Value Each security attribute may take on a variety of values; the set of legal values of a security attribute is determined by its type and its defining authority. 3.3 Examples of Subject Security Attributes Examples of subject security attributes might include: Blakley, Byrne, Stokes [Page 10] Internet-Draft ACL Model 27 March 1998 - Access identity (the unique name by which the subject is known to the access control policy evaluation subsystem of an information system). Values might include "Bob Blakley" or "server357". - Group membership (the name of a group to which the subject belongs). Values might include "Task Force Members", "Department UVZS", or "Dilbert Fans". - Role membership (the name of a role which the subject is entitled to assume for the purpose of doing work in an information system). Values might include "Vice President", "Teller", "Registered Nurse", or "Primary Care Physician". - Clearance (the name of a security clearance level). Values might include "SECRET", "TOP SECRET", or "UNCLASSIFIED". 3.4 Subject Security Attribute Information Structures 3.4.1 Credentials Subject credentials are described by values for security attributes, which are written in the subjectSecurityAttributeList syntax. While lines have been folded for readability, credential values transferred in protocols and stored in repositories will not contain newlines. The subjectCredential is encoded according to the following BNF; the productions for are given in section 4.2. ::= "(" [ ] -- name used in AttributeType ")" ::= INTEGER The value of credentialVersion in credentials conforming to this draft will be "1". Blakley, Byrne, Stokes [Page 11] Internet-Draft ACL Model 27 March 1998 Note that no provision is made for identifying the authority which issued and/or vouches for a subjectCredential structure, or for allowing that authority to sign the structure. It is viewed that this will normally be provided by protocols incorporating the subjectCredential structure. 3.4.2 Subject Security Attributes A credential is a list of subject security attributes, delimited by '$' characters. ::= "(" '$' | ")" Subject security attributes describe security-relevant attributes of subjects. As described in section 3.2, a subject security attribute structure contains the following: - a defining authority Defining authorities own subject security attribute type namespaces. Each defining authority defines a set of security attribute types, each of which has a type-name which is unique with respect to the defining authority. - a type-name or privilege Each security attribute has a type, named by a printable string. The combination of a defining authority and a type-name must uniquely determine the type information which will be used to interpret the value of the subject security attribute. - an asserting authority An asserting authority assigns a value of the appropriate type to a subject security attribute. Blakley, Byrne, Stokes [Page 12] Internet-Draft ACL Model 27 March 1998 - a value Each subject security attribute has a value, of the type named by subjectSecurityAttributeTypeName, and asserted by the authority named by subjectSecurityAttributeValueAssertingAuthority. Values are distinguished names. Values cannot be interpreted without the type information supplied by subjectSecurityAttributeTypeDefiningAuthority and subjectSecurityAttributeTypeName. ::= "(" '#' '#' '#' ")" ::= ::= ::= ::= 3.4.3 Encoding Encoding is that defined in RFC 2252. 3.4.4 Subject Security Attributes Two types of subject security attributes are defined: identities and privileges. The identities attribute contains the identities associated with the subject represented by the directory entry and may not have corresponding directory entries. Examples are user and audit_id. The privileges attribute contains the set of privilege attributes associated with the subject represented by the directory entry and will have corresponding directory entries. Examples are group and role. Blakley, Byrne, Stokes [Page 13] Internet-Draft ACL Model 27 March 1998 4. Access Control Information 4.1 Composition of Access Control Information Access to LDAP directory objects and attributes is defined by Access Control Lists (ACLs). Each object in the directory contains a special set of attribute:value pairs that describe who is allowed to access information within that object. There are two types of attributes, Access Control List (ACL) information and Owner information. 4.1.1 aclEntry Attribute The aclEntry is a multi-valued attribute that contains information pertaining to the access allowed to the entry object and each of its attributes. An aclEntry lists the following types of information: - Who has rights to the entity object (scope of the protection). - What classes of attributes the user has access to (attribute access classes). - What rights the user or group has (permission). 4.1.2 aclOwner Attribute Each object has an associated aclOwner attribute. The aclOwner attribute might be a user or a group, similar to what is allowed within the aclEntry. However, the aclOwner subject has certain privileges over the object. ACL owners are in essence the administrators for particular objects. They have full access on that particular object, similar to the administrator DN. Notice that the administrator has full permission on any object in the database. ACL owners are not constrained by permissions given in the aclEntry; they have complete access to any object attribute. ACL owners (and the administrator) are the only people who are allowed to change the access-related Blakley, Byrne, Stokes [Page 14] Internet-Draft ACL Model 27 March 1998 attributes. 4.1.3 Attribute Classes Attributes requiring similar permission for access are grouped together in classes. The four standard attribute classes are: - 1 (Normal) - 2 (Sensitive) - 4 (Critical) - 8 (Object) The attribute classes 16, 32, 64, and 128 are reserved for implementation defined classes which should not be presumed to be interoperable. Each of these attribute classes is discrete. Access to information in one class does not give access to information in any other class. The default attribute class for an attribute is Normal. The Object attribute class applies to the entire object instead of the attributes within the object. 4.1.4 Access Permissions Access permissions can apply to an entire object or to attributes of the object. Each of the LDAP access permissions are discrete. One permission does not imply another permission. Permissions that apply to an entire object (access class = 8-object) are: 1 Add Add an object below this object 2 Delete Delete this object Permissions which apply to attribute access classes (1- normal, 2-sensitive, 4-critical) are: 4 Manage Perform a privileged operation; used to Blakley, Byrne, Stokes [Page 15] Internet-Draft ACL Model 27 March 1998 restrict access to operations which read or write especially sensitive data 8 Use Execute; useful in controlloing access to the objects referred to by directory entries than in controlling access to the directory entries themselves 16 Read Read attribute values 32 Write Write attribute values 64 Search Search entries with specified attributes 128 Compare Compare attributes The evaluation algorithm looks for an indentity first. If the user's access id is in an ACL entry for the object, that entry determines access. If the user's access id is not in any ACL entry, the evaluation algorithm finds all privilege attribute entries applicable to the user and grants the user the union of all the rights granted by those entries. 4.2 Default ACL If no access control information is specified for a directory, there is a default acl that will apply to the entire directory. Notice that the default attribute definitions include a default assignment of attributes to access classes. aclOwner: IETF#access-id#IETF#cn=admin,c=US aclEntry: cn=IETF,c- US#group#cn=IETF,c=US#cn=Everybody:: The default ACL group contains everybody; it grants permission to read, search, and compare all attributes within the normal class. 4.3 Access Control Information Structures ::= "(" ")" ::= "(" "#" [ "#" ] ")" Blakley, Byrne, Stokes [Page 16] Internet-Draft ACL Model 27 March 1998 ::= ::= "8:" ::= | ::= 1 ::= 2 ::= ":" ::= | | ::= 1 ::= 2 ::= 4 ::= 8 ::= | | | | | ::= 4 ::= 8 ::= 16 ::= 32 ::= 64 :::# :#: Blakley, Byrne, Stokes [Page 17] Internet-Draft ACL Model 27 March 1998 In this example, the user corresponding to access-id "cn=personA, ou=deptXYZ, o=IBM, c=US" has permission to add objects below this object, delete this object, read, write, search, and compare both normal and sensitive attributes, and to read, search and compare critical attributes. 4.5 LDIF Syntax for Access Control Information The LDIF syntax of the ACL attribute values is: aclOwner ::= aclEntry ::= '#' [obj- granted-rights ] '#' + [class-granted-rights]* obj-granted-rights ::= "8" + ':' + object-rights class-granted-rights ::= "1" | "2" | "4" + ':' + class- rights object-rights ::= LISTOF class-rights ::= LISTOF * one or more 5. ACL Schema 5.1 Attributes 5.1.1 Identities Security Attribute (1.3.18.0.2.4.101 NAME 'identities' DESC identities associated with subject represented by directory entry EQUALITY subjectSecurityAttributeMatch SUBSTR caseIgnoreSubstringMatch SYNTAX 1.3.18.0.2.8.1 ) Blakley, Byrne, Stokes [Page 18] Internet-Draft ACL Model 27 March 1998 5.1.2 Privileges Security Attribute (1.3.18.0.2.4.108 NAME 'privileges' DESC privileges associated with subject represented by directory entry EQUALITY subjectSecurityAttributeMatch SUBSTR caseIgnoreSubstringMatch SYNTAX 1.3.18.0.2.8.1 ) 5.1.3 Defining Authority (1.3.18.0.2.4.102 NAME 'definingAuthority' DESC Authority defining the privilege attribute EQUALITY distinguishedNameMatch SUBSTR caseIgnoreSubstringMatch SYNTAX DN ) 5.1.4 Security Attribute Type (1.3.18.0.2.4.103 NAME 'securityAttributeType' DESC Type of attribute EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch SYNTAX printableString ) 5.1.5 Asserting Authority (1.3.18.0.2.4.104 NAME 'assertAuthority' DESC Authority assigning value to privilege attribute EQUALITY distinguishedNameMatch SUBSTR caseIgnoreSubstringMatch SYNTAX DN ) Blakley, Byrne, Stokes [Page 19] Internet-Draft ACL Model 27 March 1998 5.1.6 Security Attribute Value (1.3.18.0.2.4.105 NAME 'securityAttributeValue' DESC Value of security attribute type SYNTAX DN ) 5.1.7 ACL Owner (1.3.18.0.2.4.106 NAME 'aclOwner' DESC Owner of the access control list associated with object entry EQUALITY distinguishedNameMatch SUBSTR caseIgnoreSubstringMatch SYNTAX DN ) 5.1.8 ACL Entry (1.3.18.0.2.4.107 NAME 'aclEntry' DESC Access control list information SUBSTR caseIgnoreSubstringMatch SYNTAX directoryString --see BNF for aclEntry ) 5.2 Object Classes 5.2.1 Security Object (1.3.18.0.2.6.23 NAME 'subjectSecurityObject' DESC security object class for subject security attributes SUP 'top' AUXILIARY MUST ( definingAuthority $ privilegeAttribute $ assertAuthority $ attributeValue ) ) Blakley, Byrne, Stokes [Page 20] Internet-Draft ACL Model 27 March 1998 5.3 Matching Rules 5.3.1 Subject Security Attribute Match (1.3.18.0.2.10.1 NAME 'subjectSecurityAttributeMatch' DESC matching rule for security-relevant attributes of subjects SYNTAX 1.3.18.0.2.8.1 ) 5.4 Syntax (1.3.18.0.2.8.1 DESC security-relevant attributes of subjects syntax (see BNF for securityAttribute) ) 6. ACL Credential Controls The ACL credential controls provide a method to flow a subject's credentials associated with a bind. These credentials allow the ACL manager to determine whether that subject's credentials allow access to an object and/or its associated attributes when evaluated against the aclEntry for that object and its attributes. 6.1 Request Control This control is included in the bindRequest message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. The controlType is set to 1.3.18.0.2.12.1. 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: subjectCredentialRequest ::= SEQUENCE { credentialVersion INTEGER, subjectSecurityAttributeList OCTET STRING OPTIONAL } Blakley, Byrne, Stokes [Page 21] Internet-Draft ACL Model 27 March 1998 The subjectSecurityAttributeList is the list of privileges to remove (assert least privilege) from the subjectSecurityAttribute attribute associated with the object of the bind. If subjectSecurityAttributeList is not present, then the subjectSecurityAttribute attribute associated with the object of the bind is used as-is. 6.2 Response Control This control is included in the bindResult message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. The controlType is set to 1.3.18.0.2.12.2. 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: subjectCredentialResponse ::= SEQUENCE { subjectCredentialResult ENUMERATED { success (0), operationsError (1), unavailableCriticalExtension (12), noSuchAttribute (16), undefinedAttributeType (17), invalidAttributeSyntax (21), unavailable (52), unwillingToPerform (53), other (80) } } 6.3 Client-Server Interaction The subjectCredentialRequest control specifies the privileges that MUST be in effect for the scope of the bind. The server that consumes the bind operation looks up the subjectSecurityAttribute attribute associated with the bind object, removes any subjectSecurityAttribute attributes passed in the subjectSecurityAttributeList from the set of that bind object's privileges, and stores the result as state information associated with the scope of that bind. Blakley, Byrne, Stokes [Page 22] Internet-Draft ACL Model 27 March 1998 The application client may change the privileges associated with the scope of the bind by issuing another bindRequest. There are six possible scenarios that may occur as a result of the credential control being included on the bind request: 1. If the server does not support this credential 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 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 credential control and the client specified FALSE for the control's criticality field, then the server MUST ignore the credential control and process the credential request as if it were not present. This behavior is specified in section 4.1.12 of [LDAPv3]. 3. If the server supports this credential control but for some reason such as cannot process specified version of credential and the client specified TRUE for the control's criticality field, then the server SHOULD do the following: return unavailableCriticalExtension as a return code in the bindResult message and include the subjectCredentialResponse control in the bindResult message. 4. If the server supports this credential control but for some reason such as cannot process specified version of credential and the client specified FALSE for the control's criticality field, then the server should process as 'no privileges' and include the subjectCredentialResponse control in the bindResult message. 5. If the server supports this credential control and can set the privileges per the Blakley, Byrne, Stokes [Page 23] Internet-Draft ACL Model 27 March 1998 subjectSecurityAttributeList information, then it should include the subjectCredentialResponse control in the bindResult message with a subjectCredentialResult of success. 6. If the credential request failed for any reason, then the server SHOULD omit the subjectCredentialResponse control from the bindResult message. The client application is assured that the correct privileges are set for the scope of the bind operation if and only if the result code in the subjectCredentialResponse control is success. If the server omits the subjectCredentialResponse control from the bindResult message, the client SHOULD assume that the credential control was ignored by the server. The subjectCredentialResponse control, if included by the server in the bindResponse message, should have the subjectCredentialResult set to either success if the privileges were set in accordance with the privileges specified in the subjectCredentialRequest control or set to the appropriate error code as to why the privileges could not be set. The server may not be able to remove a privilege because it may not exist in that bind object's subjectSecurityAttribute attribute; in this case, the remove request for that privilege is ignored with error. 7. ACL Extended Operations Basic operations on ACLs such as add, delete, and modify can be done using the currently defined set of LDAP operations. The extension mechanism as defined in the LDAP protocol specification [LDAPv3] is used to allow the additional ACL operations to be defined in the LDAP protocol. These operations are (1) get required rights, and (2) get effective rights. These extended operations provide queries associated with ACL operations that are not possible using the currently defined set of LDAP operations. Blakley, Byrne, Stokes [Page 24] Internet-Draft ACL Model 27 March 1998 7.1 Get Required Rights Operation getRequiredRightsRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] 1.3.18.0.2.14.1, requestValue [1] OCTET STRING } where requestValue ::= SEQUENCE { dn LDAPDN, operation ENUMERATED { LDAP_ACL_ADD (1), LDAP_ACL_DELETE (2), LDAP_ACL_MODIFY (4), LDAP_ACL_COMPARE (8), LDAP_ACL_SEARCHATTRSONLY (16), LDAP_ACL_SEARCHATTRSVALS (32), LDAP_ACL_MODDN (64) } } 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. getRequiredRightsResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] 1.3.18.0.2.14.2 OPTIONAL, rightsList [11] OCTET STRING OPTIONAL } where rightsList ::= SEQUENCE OF SEQUENCE { whichObject ENUMERATED { LDAP_PARENT (1), LDAP_SELF (2), LDAP_NEWPARENT (4) }, attributeClass ENUMERATED { LDAP_NORMAL (1), LDAP_SENSITIVE (2), Blakley, Byrne, Stokes [Page 25] Internet-Draft ACL Model 27 March 1998 LDAP_CRITICAL (4), LDAP_OBJECT (8) }, permission ENUMERATED { ACL_ADD (1), ACL_DEL (2), ACL_MANAGE (4), ACL_USE (8), ACL_READ (16), ACL_SEARCH (32), ACL_WRITE (64), ACL_COMPARE (128), } } If the server does not recognize the request name, it MUST return only the response fields from LDAPResult, containing the protocolError result code. 7.2 Get Effective Rights Operation getEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] 1.3.18.0.2.14.3, requestValue [1] OCTET STRING OPTIONAL } 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. getEffectiveRightsResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] 1.3.18.0.2.14.4 OPTIONAL, rightsList [11] OCTET STRING OPTIONAL } where rightsList ::= SEQUENCE OF SEQUENCE { whichObject ENUMERATED { LDAP_PARENT (1), LDAP_SELF (2), Blakley, Byrne, Stokes [Page 26] Internet-Draft ACL Model 27 March 1998 LDAP_NEWPARENT (4) }, attributeClass ENUMERATED { LDAP_NORMAL (1), LDAP_SENSITIVE (2), LDAP_CRITICAL (4), LDAP_OBJECT (8) }, permission ENUMERATED { ACL_ADD (1), ACL_DEL (2), ACL_MANAGE (4), ACL_USE (8), ACL_READ (16), ACL_SEARCH (32), ACL_WRITE (64), ACL_COMPARE (128), } } If the server does not recognize the request name, it MUST return only the response fields from LDAPResult, containing the protocolError result code. 8. Security Considerations This draft proposes a data structure for representing 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. 9. 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 Blakley, Byrne, Stokes [Page 27] Internet-Draft ACL Model 27 March 1998 [REQTS] Stokes, Byrne, Blakley, "Access Control Requirements for LDAP, INTERNET-DRAFT , February 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 Bob Blakley Ellen Stokes IBM IBM 11400 Burnet Rd 11400 Burnet Rd Austin, TX 78758 Austin, TX 78758 USA USA mail-to: blakley@us.ibm.com mail-to: stokes@austin.ibm.com phone: +1 512 838 8133 phone: +1 512 838 3725 fax: +1 512 838 0156 fax: +1 512 838 0156 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 0156 Blakley, Byrne, Stokes [Page 28] Internet-Draft ACL Model 27 March 1998 Blakley, Byrne, Stokes [Page 29] CONTENTS 1. Introduction........................................ 2 2. Overview............................................ 2 2.1 Access Control Activity Lifecycle.............. 2 2.2 Access Control Information Model............... 3 2.3 Access Control System Structure................ 3 2.4 Terminology.................................... 6 3. Subject Security Attribute Information.............. 9 3.1 Terminology.................................... 9 3.2 Subject Security Attribute Properties.......... 9 3.3 Examples of Subject Security Attributes........ 10 3.4 Subject Security Attribute Information Structures..................................... 11 3.4.1 Credentials 11 3.4.2 Subject Security Attributes 12 3.4.3 Encoding 13 3.4.4 Subject Security Attributes 13 4. Access Control Information.......................... 14 4.1 Composition of Access Control Information...... 14 4.1.1 aclEntry Attribute 14 4.1.2 aclOwner Attribute 14 4.1.3 Attribute Classes 15 4.1.4 Access Permissions 15 4.2 Default ACL.................................... 16 4.3 Access Control Information Structures.......... 16 4.4 An ACL Example................................. 17 4.5 LDIF Syntax for Access Control Information..... 18 5. ACL Schema.......................................... 18 5.1 Attributes..................................... 18 5.1.1 Identities Security Attribute 18 5.1.2 Privileges Security Attribute 19 5.1.3 Defining Authority 19 5.1.4 Security Attribute Type 19 5.1.5 Asserting Authority 19 5.1.6 Security Attribute Value 20 5.1.7 ACL Owner 20 5.1.8 ACL Entry 20 5.2 Object Classes................................. 20 5.2.1 Security Object 20 - i - 5.3 Matching Rules................................. 21 5.3.1 Subject Security Attribute Match 21 5.4 Syntax......................................... 21 6. ACL Credential Controls............................. 21 6.1 Request Control................................ 21 6.2 Response Control............................... 22 6.3 Client-Server Interaction...................... 22 7. ACL Extended Operations............................. 24 7.1 Get Required Rights Operation.................. 25 7.2 Get Effective Rights Operation................. 26 8. Security Considerations............................. 27 9. References.......................................... 27 - ii -