2 Internet-Draft E. Stokes
3 LDAP Extensions WG D. Byrne
4 Intended Category: Informational IBM
5 Expires: 25 December 1999 B. Blakley
11 Access Control Requirements for LDAP
12 <draft-ietf-ldapext-acl-reqts-02.txt>
16 This document is an Internet-Draft and is in full
17 conformance with all provisions of Section 10 of RFC2026.
19 Internet-Drafts are working documents of the Internet
20 Engineering Task Force (IETF), its areas, and its working
21 groups. Note that other groups may also distribute
22 working documents as Internet-Drafts. Internet-Drafts are
23 draft documents valid for a maximum of six months and may
24 be updated, replaced, or obsoleted by other documents at
25 any time. It is inappropriate to use Internet- Drafts as
26 reference material or to cite them other than as "work in
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt
32 The list of Internet-Draft Shadow Directories can be
33 accessed at http://www.ietf.org/shadow.html.
35 Comments and suggestions on this document are encouraged.
36 Comments on this document should be sent to the LDAPEXT
37 working group discussion list:
39 ietf-ldapext@netscape.com
42 Copyright (C) The Internet Society (1997). All Rights
50 Stokes, etal Expires 25 December 1999 [Page 1]
56 Internet-Draft ACI Requirements 25 June 1999
62 This document describes the fundamental requirements of
63 an access control list (ACL) model for the Lightweight
64 Directory Application Protocol (LDAP) directory service.
65 It is intended to be a gathering place for access control
66 requirements needed to provide authorized access to and
67 interoperability between directories. The RFC 2119
68 terminology is used in this document.
74 The ability to securely access (replicate and distribute)
75 directory information throughout the network is necessary
76 for successful deployment. LDAP's acceptance as an
77 access protocol for directory information is driving the
78 need to provide an access control model definition for
79 LDAP directory content among servers within an enterprise
80 and the Internet. Currently LDAP does not define an
81 access control model, but is needed to ensure consistent
82 secure access across heterogeneous LDAP implementations.
83 The requirements for access control are critical to the
84 successful deployment and acceptance of LDAP in the
87 The RFC 2119 terminology is used in this document.
92 The major objective is to provide a simple, but secure,
93 highly efficient access control model for LDAP while also
94 providing the appropriate flexibility to meet the needs
95 of both the Internet and enterprise environments and
98 This generally leads to several general requirements that
104 This section is divided into several areas of
108 Stokes, etal Expires 25 December 1999 [Page 2]
114 Internet-Draft ACI Requirements 25 June 1999
118 requirements: general, semantics/policy, usability, and
119 nested groups (an unresolved issue). The requirements
120 are not in any priority order. Examples and explanatory
121 text is provided where deemed necessary. Usability is
122 perhaps the one set of requirements that is generally
123 overlooked, but must be addressed to provide a secure
124 system. Usability is a security issue, not just a nice
125 design goal and requirement. If it is impossible to set
126 and manage a policy for a secure situation that a human
127 can understand, then what was set up will probably be
128 non-secure. We all need to think of usability as a
129 functional security requirement.
133 G1. Model SHOULD be general enough to support
134 extensibility to add desirable features in the future.
136 G2. When in doubt, safer is better, especially when
137 establishing defaults.
139 G3. ACL administration SHOULD be part of the LDAP
140 protocol. Access control information MUST be an LDAP
143 G4. Object reuse protection SHOULD be provided and MUST
144 NOT inhibit implementation of object reuse. The directory
145 SHOULD support policy controlling the re-creation of
146 deleted DNs, particularly in cases where they are re-
147 created for the purpose of assigning them to a subject
148 other than the owner of the deleted DN.
150 3.2 Semantics / Policy
152 S1. Omitted as redundant; see U8.
154 S2. More specific policies must override less specific
155 ones (e.g. individual user entry in ACL SHOULD take
156 precedence over group entry) for the evaluation of an
159 S3. Multiple policies of equal specificity SHOULD be
160 combined in some easily-understood way (e.g. union or
161 intersection). This is best understood by example.
162 Suppose user A belongs to 3 groups and those 3 groups are
166 Stokes, etal Expires 25 December 1999 [Page 3]
172 Internet-Draft ACI Requirements 25 June 1999
176 listed on the ACL. Also suppose that the permissions for
177 each of those groups are not identical. Each group is of
178 equal specificity (e.g. each group is listed on the ACL)
179 and the policy for granting user A access (given the
180 example) SHOULD be combined in some easily understood
181 way, such as by intersection or union. For example, an
182 intersection policy here may yield a more limited access
183 for user A than a union policy.
185 S4. Newly created directory entries SHOULD be subject to
186 a secure default policy.
188 S5. Access policy SHOULD NOT be expressed in terms of
189 attributes which the directory administrator or his
190 organization cannot administer (e.g. groups whose
191 membership is administered by another organization).
193 S6. Access policy SHOULD NOT be expressed in terms of
194 attributes which are easily forged (e.g. IP addresses).
195 There may be valid reasons for enabling access based on
196 attributes that are easily forged and the
197 behavior/implications of doing that should be documented.
199 S7. Humans (including administrators) SHOULD NOT be
200 required to manage access policy on the basis of
201 attributes which are not "human-readable" (e.g. IP
204 S8. It MUST be possible to deny a subject the right to
205 invoke a directory operation. The system SHOULD NOT
206 require a specific implementation of denial (e.g.
207 explicit denial, implicit denial).
209 S9. The system MUST be able (semantically) to support
210 either default-grant or default-deny semantics (not
213 S10. The system MUST be able to support either union
214 semantics or intersection semantics for aggregate
215 subjects (not simultaneously).
217 S11. Absence of policy SHOULD be interpretable as grant
218 or deny. Deny takes precedence over grant among entries
219 of equal specificity.
224 Stokes, etal Expires 25 December 1999 [Page 4]
230 Internet-Draft ACI Requirements 25 June 1999
234 S12. ACL policy resolution MUST NOT depend on the order
235 of entries in the ACL.
237 S13. Rights management MUST have no side effects.
238 Granting a subject one right to an object MUST NOT
239 implicitly grant the same or any other subject a
240 different right to the same object. Granting a privilege
241 attribute to one subject MUST NOT implicitly grant the
242 same privilege attribute to any other subject. Granting
243 a privilege attribute to one subject MUST NOT implicitly
244 grant a different privilege attribute to the same or any
245 other subject. Definition: An ACL's "scope" is defined
246 as the set of directory objects governed by the policy it
247 defines; this set of objects is a sub-tree of the
248 directory. Changing the policy asserted by an ACL (by
249 changing one or more of its entries) MUST NOT implicitly
250 change the policy governed by an ACL in a different
253 S14. It SHOULD be possible to apply a single policy to
254 multiple directory entries, even if those entries are in
255 different subtrees. Applying a single policy to multiple
256 directory entries SHOULD NOT require creation and storage
257 of multiple copies of the policy data. The system SHOULD
258 NOT require a specific implementation (e.g. nested
259 groups, named ACLs) of support for policy sharing.
261 3.3 Usability (Manageability)
263 U1. When in doubt, simpler is better, both at the
264 interface and in the implementation.
266 U2. Subjects MUST be drawn from the "natural" LDAP
267 namespace; they should be DNs.
269 U3. It SHOULD NOT be possible via ACL administration to
270 lock all users, including all administrators, out of the
273 U4. Administrators SHOULD NOT be required to evaluate
274 arbitrary Boolean predicates in order to create or
277 U5. Administrators SHOULD be able to administer access
278 to directories and their attributes based on their
282 Stokes, etal Expires 25 December 1999 [Page 5]
288 Internet-Draft ACI Requirements 25 June 1999
292 sensitivity, without having to understand the semantics
293 of individual schema elements and their attributes (see
296 U6. Management of access to resources in an entire
297 subtree SHOULD require only one ACL (at the subtree
298 root). Note that this makes access control based
299 explicitly on attribute types very hard, unless you
300 constrain the types of entries in subtrees. For example,
301 another attribute is added to an entry. That attribute
302 may fall outside the grouping covered by the ACL and
303 hence require additional administration where the desired
304 affect is indeed a different ACL. Access control
305 information specified in one administrative area MUST NOT
306 have jurisdiction in another area. You SHOULD NOT be
307 able to control access to the aliased entry in the alias.
308 You SHOULD be able to control access to the alias name.
310 U7. Override of subtree policy MUST be supported on a
311 per-directory-entry basis.
313 U8. Control of access to individual directory entry
314 attributes (not just the whole directory entry) MUST be
317 U9. Administrator MUST be able to coarsen access policy
318 granularity by grouping attributes with similar access
321 U10. Control of access on a per-user granularity MUST be
324 U11. Administrator MUST be able to aggregate users (for
325 example, by assigning them to groups or roles) to
326 simplify administration.
328 U12. It MUST be possible to review "effective access" of
329 any user, group, or role to any entry's attributes. This
330 aids the administrator in setting the correct policy.
332 U13. A single administrator SHOULD be able to define
333 policy for the entire directory tree. An administrator
334 MUST be able to delegate policy administration for
335 specific subtrees to other users. This allows for the
336 partitioning of the entire directory tree for policy
340 Stokes, etal Expires 25 December 1999 [Page 6]
346 Internet-Draft ACI Requirements 25 June 1999
350 administration, but still allows a single policy to be
351 defined for the entire tree independent of partitioning.
352 (Partition in this context means scope of
353 administration). An administrator MUST be able to create
354 new partitions at any point in the directory tree, and
355 MUST be able to merge a superior and subordinate
356 partition. An administrator MUST be able to configure
357 whether delegated access control information from
358 superior partitions is to be accepted or not.
360 U14. It MUST be possible to authorize users to traverse
361 directory structure even if they are not authorized to
362 examine or modify some traversed entries; it MUST also be
363 possible to prohibit this. The tree structure MUST be
364 able to be protected from view if so desired by the
367 U15. It MUST be possible to create publicly readable
368 entries, which may be read even by unauthenticated
371 U16. The model for combining multiple access control
372 list entries referring to a single individual MUST be
375 U17. Administrator MUST be able to determine where
376 inherited policy information comes from, that is, where
377 ACLs are located and which ACLs were applied. Where
378 inheritance of ACLs is applied, it must be able to be
379 shown how/where that new ACL is derived from.
381 U18. It SHOULD be possible for the administrator to
382 configure the access control system to permit users to
383 grant additional access control rights for entries which
387 4. Security Considerations
389 Access control is a security consideration. This
390 documents addresses the requirements.
398 Stokes, etal Expires 25 December 1999 [Page 7]
404 Internet-Draft ACI Requirements 25 June 1999
410 This glossary is intended to aid the novice not versed in
411 depth about access control. It contains a list [2] of
412 terms and their definitions that are commonly used in
413 discussing access control.
415 Access control - The prevention of use of a resource by
416 unidentified and/or unauthorized entities in any other
417 that an authorized manner.
419 Access control list - A set of control attributes. It is
420 a list, associated with a security object or a group of
421 security objects. The list contains the names of
422 security subjects and the type of access that may be
425 Access control policy - A set of rules, part of a
426 security policy, by which human users, or their
427 representatives, are authenticated and by which access by
428 these users to applications and other services and
429 security objects is granted or denied.
431 Access context - The context, in terms of such variables
432 as location, time of day, level of security of the
433 underlying associations, etc., in which an access to a
434 security object is made.
436 Authorization - The granting of access to a security
439 Authorization policy - A set of rules, part of an access
440 control policy, by which access by security subjects to
441 security objects is granted or denied. An authorization
442 policy may be defined in terms of access control lists,
443 capabilities, or attributes assigned to security
444 subjects, security objects, or both.
446 Control attributes - Attributes, associated with a
447 security object that, when matched against the privilege
448 attributes of a security subject, are used to grant or
449 deny access to the security object. An access control
450 list or list of rights or time of day range are examples
451 of control attributes.
456 Stokes, etal Expires 25 December 1999 [Page 8]
462 Internet-Draft ACI Requirements 25 June 1999
466 Credentials - Data that serve to establish the claimed
467 identity of a security subject relative to a given
470 Privilege attributes - Attributes, associated with a
471 security subject that, when matched against control
472 attributes of a security object, are used to grant or
473 deny access to that subject. Group and role memberships
474 are examples of privilege attributes.
476 Security attributes - A general term covering both
477 privilege attributes and control attributes. The use of
478 security attributes is defined by a security policy.
480 Security object - An entity in a passive role to which a
481 security policy applies.
483 Security policy - A general term covering both access
484 control policies and authorization policies.
486 Security subject - An entity in an active role to which a
487 security policy applies.
492 [1] Steve Kille, Tim Howes, M. Wahl, "Lightweight
493 Directory Access Protocol (v3)", RFC 2251, August 1997.
495 [2] ECMA, "Security in Open Systems: A Security
496 Framework" ECMA TR/46, July 1988
501 Bob Blakley Ellen Stokes
503 5515 Balcones Drive 11400 Burnet Rd
504 Austin, TX 78731 Austin, TX 78758
506 mail-to: blakley@dascom.com mail-to: stokes@austin.ibm.com
507 phone: +1 512 458 4037 ext 5012 phone: +1 512 838 3725
508 fax: +1 512 458 2377 fax: +1 512 838 0156
514 Stokes, etal Expires 25 December 1999 [Page 9]
520 Internet-Draft ACI Requirements 25 June 1999
524 Debbie Byrne Prasanta Behera
526 11400 Burnet Rd 501 Ellis Street
527 Austin, TX 78758 Mountain View, CA 94043
529 mail-to: djbyrne@us.ibm.com mail-to: prasanta@netscape.com
530 phone: +1 512 838 1930 phone: +1 650 937 4948
531 fax: +1 512 838 8597 fax: +1 650 528-4164
572 Stokes, etal Expires 25 December 1999 [Page 10]
578 Internet-Draft ACI Requirements 25 June 1999
582 7. Full Copyright Statement
584 Copyright (C) The Internet Society (1999).á All Rights
587 This document and translations of it may be copied and
588 furnished to others, and derivative works that comment on or
589 otherwise explain it or assist in its implementation may be
590 prepared, copied, published and distributed, in whole or in
591 part, without restriction of any kind, provided that the
592 above copyright notice and this paragraph are included on
593 all such copies and derivative works.á However, this
594 document itself may not be modified in any way, such as by
595 removing the copyright notice or references to the Internet
596 Society or other Internet organizations, except as needed
597 for the purpose of developing Internet standards in which
598 case the procedures for copyrights defined in the Internet
599 Standards process must be followed, or as required to
600 translate it into languages other than English.
602 The limited permissions granted above are perpetual and will
603 not be revoked by the Internet Society or its successors or
606 This document and the information contained herein is
607 provided on an "AS IS" basis and THE INTERNET SOCIETY AND
608 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
609 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
610 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
611 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
612 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
630 Stokes, etal Expires 25 December 1999 [Page 11]
projects / openldap / blob