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
                     <draft-ietf-ldapext-acl-model-00.txt>
          
          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
             <SubjectSecurityAttributeList> are given in section 4.2.
          
              <subjectCredential> ::= "("
                <credentialVersion>
                [ <subjectSecurityAttributeList> ] -- name used in
             AttributeType
                ")"
          
                <credentialVersion> ::= 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.
          
                   <subjectSecurityAttributeList> ::= "("
                     <subjectSecurityAttributeList> '$'
             <subjectSecurityAttribute>
                   | <subjectSecurityAttribute>
                     ")"
          
             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.
          
              <ssubjectSecurityAttribute> ::= "("
                <subjectSecurityAttributeTypeDefiningAuthority> '#'
                <subjectSecurityAttributeTypeName> '#'
                <subjectSecurityAttributeValueAssertingAuthority> '#'
                <subjectSecurityAttributeValue>
                ")"
          
              <subjectSecurityAttributeTypeDefiningAuthority> ::= <DN>
          
              <subjectSecurityAttributeTypeName> ::= <printableString>
          
              <subjectSecurityAttributeValueAssertingAuthority> ::=
             <DN>
          
              <subjectSecurityAttributeValue> ::= <DN>
          
          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:<normal>:<r><s><c>
          
             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
          
              <aclOwner> ::= "("         <subjectSecurityAttribute>
                     ")"
          
              <aclEntry> ::= "("
               <subjectSecurityAttribute> "#"
               <accessList> [ "#" <accessList> ]         ")"
          
          
          
          
          Blakley, Byrne, Stokes                             [Page 16]


          Internet-Draft           ACL Model             27 March 1998
          
          
          
              <accessList> ::= <objectAccessClass>
             <attributeAccessClass>
          
              <objectAccessClass> ::= "8:"
             <objectAccessClassPermissions>
          
              <objectAccessClassPermissions> ::= <add> | <delete>
          
              <add> ::= 1
          
              <delete> ::= 2
          
              <attributeAccessClass> ::= <class> ":" <permissions>
          
              <class> ::= <normal> | <sensitive> | <critical>
          
              <normal> ::= 1
          
              <sensitive> ::= 2
          
              <critical> ::= 4
          
              <object> ::= 8
          
              <permissions> ::= <manage> | <use> | <read> | <write>
                     | <search> | <compare>
          
              <manage> ::= 4
          
              <use> ::= 8
          
              <read> ::= 16
          
              <write> ::= 32
          
              <search> ::= 64
          
              <compare ::= 128
          
          
          4.4  An_ACL_Example
          
              o=IBM,c=US#access-id#o=IBM,c=US#cn=personA,
              ou=deptXYZ,o=IBM,c=US#<object>:<a><d>:<normal>:<r><w><s><c>#
              <sensitive>:<r><w><s><c>#<critical>:<r><s><c>
          
          
          
          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 ::= <subjectSecurityAttribute>
          
              aclEntry ::= <subjectSecurityAttribute> '#' [obj-
             granted-rights ] '#' + [class-granted-rights]*
          
              obj-granted-rights ::= "8" + ':' + object-rights
          
              class-granted-rights ::= "1" | "2" | "4" + ':' + class-
             rights
          
              object-rights ::= LISTOF <a><d>
          
              class-rights  ::= LISTOF <r><w><s><c>
          
              * 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 <draft-ietf-
             ldapext-acl-reqts-00.txt>, 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 -