[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
LDAP ACL model document
To the drafts editor: please publish the attached draft.
To the ldapext group: please find attached draft of the
ldap ACL document.
Thanks.
Ellen
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 learn the current status of any Internet-Draft, please
check the 1id-abstracts.txt listing contained in the
Internet-Drafts Shadow Directories on ds.internic.net,
nic.nordu.net, ftp.isi.edu, or munnari.oz.au.
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. _I_n_t_r_o_d_u_c_t_i_o_n
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. _O_v_e_r_v_i_e_w
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 _A_c_c_e_s_s__C_o_n_t_r_o_l__A_c_t_i_v_i_t_y__L_i_f_e_c_y_c_l_e
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 _A_c_c_e_s_s__C_o_n_t_r_o_l__I_n_f_o_r_m_a_t_i_o_n__M_o_d_e_l
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 _A_c_c_e_s_s__C_o_n_t_r_o_l__S_y_s_t_e_m__S_t_r_u_c_t_u_r_e
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 _T_e_r_m_i_n_o_l_o_g_y
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. _S_u_b_j_e_c_t__S_e_c_u_r_i_t_y__A_t_t_r_i_b_u_t_e__I_n_f_o_r_m_a_t_i_o_n
This section defines the data structures used to describe
subject security attribute information in support of LDAP
Access Control.
3.1 _T_e_r_m_i_n_o_l_o_g_y
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 _S_u_b_j_e_c_t__S_e_c_u_r_i_t_y__A_t_t_r_i_b_u_t_e__P_r_o_p_e_r_t_i_e_s
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 _E_x_a_m_p_l_e_s__o_f__S_u_b_j_e_c_t__S_e_c_u_r_i_t_y__A_t_t_r_i_b_u_t_e_s
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 _S_u_b_j_e_c_t__S_e_c_u_r_i_t_y__A_t_t_r_i_b_u_t_e__I_n_f_o_r_m_a_t_i_o_n__S_t_r_u_c_t_u_r_e_s
3.4.1 _C_r_e_d_e_n_t_i_a_l_s
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 _S_u_b_j_e_c_t__S_e_c_u_r_i_t_y__A_t_t_r_i_b_u_t_e_s
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 _E_n_c_o_d_i_n_g
Encoding is that defined in RFC 2252.
3.4.4 _S_u_b_j_e_c_t__S_e_c_u_r_i_t_y__A_t_t_r_i_b_u_t_e_s
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. _A_c_c_e_s_s__C_o_n_t_r_o_l__I_n_f_o_r_m_a_t_i_o_n
4.1 _C_o_m_p_o_s_i_t_i_o_n__o_f__A_c_c_e_s_s__C_o_n_t_r_o_l__I_n_f_o_r_m_a_t_i_o_n
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 _a_c_l_E_n_t_r_y__A_t_t_r_i_b_u_t_e
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 _a_c_l_O_w_n_e_r__A_t_t_r_i_b_u_t_e
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 _A_t_t_r_i_b_u_t_e__C_l_a_s_s_e_s
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 _A_c_c_e_s_s__P_e_r_m_i_s_s_i_o_n_s
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 _D_e_f_a_u_l_t__A_C_L
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 _A_c_c_e_s_s__C_o_n_t_r_o_l__I_n_f_o_r_m_a_t_i_o_n__S_t_r_u_c_t_u_r_e_s
<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 _A_n__A_C_L__E_x_a_m_p_l_e
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 _L_D_I_F__S_y_n_t_a_x__f_o_r__A_c_c_e_s_s__C_o_n_t_r_o_l__I_n_f_o_r_m_a_t_i_o_n
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. _A_C_L__S_c_h_e_m_a
5.1 _A_t_t_r_i_b_u_t_e_s
5.1.1 _I_d_e_n_t_i_t_i_e_s__S_e_c_u_r_i_t_y__A_t_t_r_i_b_u_t_e
(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 _P_r_i_v_i_l_e_g_e_s__S_e_c_u_r_i_t_y__A_t_t_r_i_b_u_t_e
(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 _D_e_f_i_n_i_n_g__A_u_t_h_o_r_i_t_y
(1.3.18.0.2.4.102
NAME 'definingAuthority'
DESC Authority defining the privilege
attribute
EQUALITY distinguishedNameMatch
SUBSTR caseIgnoreSubstringMatch
SYNTAX DN
)
5.1.4 _S_e_c_u_r_i_t_y__A_t_t_r_i_b_u_t_e__T_y_p_e
(1.3.18.0.2.4.103
NAME 'securityAttributeType'
DESC Type of attribute
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringMatch
SYNTAX printableString
)
5.1.5 _A_s_s_e_r_t_i_n_g__A_u_t_h_o_r_i_t_y
(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 _S_e_c_u_r_i_t_y__A_t_t_r_i_b_u_t_e__V_a_l_u_e
(1.3.18.0.2.4.105
NAME 'securityAttributeValue'
DESC Value of security attribute type
SYNTAX DN
)
5.1.7 _A_C_L__O_w_n_e_r
(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 _A_C_L__E_n_t_r_y
(1.3.18.0.2.4.107
NAME 'aclEntry'
DESC Access control list information
SUBSTR caseIgnoreSubstringMatch
SYNTAX directoryString --see BNF for aclEntry
)
5.2 _O_b_j_e_c_t__C_l_a_s_s_e_s
5.2.1 _S_e_c_u_r_i_t_y__O_b_j_e_c_t
(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 _M_a_t_c_h_i_n_g__R_u_l_e_s
5.3.1 _S_u_b_j_e_c_t__S_e_c_u_r_i_t_y__A_t_t_r_i_b_u_t_e__M_a_t_c_h
(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 _S_y_n_t_a_x
(1.3.18.0.2.8.1
DESC security-relevant attributes of subjects
syntax (see BNF for securityAttribute)
)
6. _A_C_L__C_r_e_d_e_n_t_i_a_l__C_o_n_t_r_o_l_s
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 _R_e_q_u_e_s_t__C_o_n_t_r_o_l
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 _R_e_s_p_o_n_s_e__C_o_n_t_r_o_l
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 _C_l_i_e_n_t_-_S_e_r_v_e_r__I_n_t_e_r_a_c_t_i_o_n
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. _A_C_L__E_x_t_e_n_d_e_d__O_p_e_r_a_t_i_o_n_s
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 _G_e_t__R_e_q_u_i_r_e_d__R_i_g_h_t_s__O_p_e_r_a_t_i_o_n
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 _G_e_t__E_f_f_e_c_t_i_v_e__R_i_g_h_t_s__O_p_e_r_a_t_i_o_n
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. _S_e_c_u_r_i_t_y__C_o_n_s_i_d_e_r_a_t_i_o_n_s
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. _R_e_f_e_r_e_n_c_e_s
[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 -