idnits 2.17.1 draft-ietf-ldapext-acl-reqts-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope.' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 100: '... G1. Model SHOULD be general eno...' RFC 2119 keyword, line 106: '...L administration SHOULD be part of the...' RFC 2119 keyword, line 107: '...ss control information MUST be an LDAP...' RFC 2119 keyword, line 110: '...reuse protection SHOULD be provided an...' RFC 2119 keyword, line 112: '... SHOULD support policy con...' (47 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (25 June 1999) is 9072 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '2' on line 379 looks like a reference -- Missing reference section? '1' on line 376 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft E. Stokes 2 LDAP Extensions WG D. Byrne 3 Intended Category: Informational IBM 4 Expires: 25 December 1999 B. Blakley 5 Dascom 6 P. Behera 7 Netscape 8 25 June 1999 10 Access Control Requirements for LDAP 11 13 STATUS OF THIS MEMO 15 This document is an Internet-Draft and is in full 16 conformance with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet 19 Engineering Task Force (IETF), its areas, and its working 20 groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. Internet-Drafts are 22 draft documents valid for a maximum of six months and may 23 be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet- Drafts as 25 reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be 32 accessed at http://www.ietf.org/shadow.html. 34 Comments and suggestions on this document are encouraged. 35 Comments on this document should be sent to the LDAPEXT 36 working group discussion list: 38 ietf-ldapext@netscape.com 40 COPYRIGHT NOTICE 41 Copyright (C) The Internet Society (1997). All Rights 42 Reserved. 44 ABSTRACT 46 This document describes the fundamental requirements of 47 an access control list (ACL) model for the Lightweight 48 Directory Application Protocol (LDAP) directory service. 49 It is intended to be a gathering place for access control 50 requirements needed to provide authorized access to and 51 interoperability between directories. The RFC 2119 52 terminology is used in this document. 54 1. Introduction 56 The ability to securely access (replicate and distribute) 57 directory information throughout the network is necessary 58 for successful deployment. LDAP's acceptance as an 59 access protocol for directory information is driving the 60 need to provide an access control model definition for 61 LDAP directory content among servers within an enterprise 62 and the Internet. Currently LDAP does not define an 63 access control model, but is needed to ensure consistent 64 secure access across heterogeneous LDAP implementations. 65 The requirements for access control are critical to the 66 successful deployment and acceptance of LDAP in the 67 market place. 69 The RFC 2119 terminology is used in this document. 71 2. Objectives 73 The major objective is to provide a simple, but secure, 74 highly efficient access control model for LDAP while also 75 providing the appropriate flexibility to meet the needs 76 of both the Internet and enterprise environments and 77 policies. 79 This generally leads to several general requirements that 80 are discussed below. 82 3. Requirements 84 This section is divided into several areas of 85 requirements: general, semantics/policy, usability, and 86 nested groups (an unresolved issue). The requirements 87 are not in any priority order. Examples and explanatory 88 text is provided where deemed necessary. Usability is 89 perhaps the one set of requirements that is generally 90 overlooked, but must be addressed to provide a secure 91 system. Usability is a security issue, not just a nice 92 design goal and requirement. If it is impossible to set 93 and manage a policy for a secure situation that a human 94 can understand, then what was set up will probably be 95 non-secure. We all need to think of usability as a 96 functional security requirement. 98 3.1 General 100 G1. Model SHOULD be general enough to support 101 extensibility to add desirable features in the future. 103 G2. When in doubt, safer is better, especially when 104 establishing defaults. 106 G3. ACL administration SHOULD be part of the LDAP 107 protocol. Access control information MUST be an LDAP 108 attribute. 110 G4. Object reuse protection SHOULD be provided and MUST 111 NOT inhibit implementation of object reuse. The directory 112 SHOULD support policy controlling the re-creation of 113 deleted DNs, particularly in cases where they are re- 114 created for the purpose of assigning them to a subject 115 other than the owner of the deleted DN. 117 3.2 Semantics / Policy 119 S1. Omitted as redundant; see U8. 121 S2. More specific policies must override less specific 122 ones (e.g. individual user entry in ACL SHOULD take 123 precedence over group entry) for the evaluation of an 124 ACL. 126 S3. Multiple policies of equal specificity SHOULD be 127 combined in some easily-understood way (e.g. union or 128 intersection). This is best understood by example. 129 Suppose user A belongs to 3 groups and those 3 groups are 130 listed on the ACL. Also suppose that the permissions for 131 each of those groups are not identical. Each group is of 132 equal specificity (e.g. each group is listed on the ACL) 133 and the policy for granting user A access (given the 134 example) SHOULD be combined in some easily understood 135 way, such as by intersection or union. For example, an 136 intersection policy here may yield a more limited access 137 for user A than a union policy. 139 S4. Newly created directory entries SHOULD be subject to 140 a secure default policy. 142 S5. Access policy SHOULD NOT be expressed in terms of 143 attributes which the directory administrator or his 144 organization cannot administer (e.g. groups whose 145 membership is administered by another organization). 147 S6. Access policy SHOULD NOT be expressed in terms of 148 attributes which are easily forged (e.g. IP addresses). 149 There may be valid reasons for enabling access based on 150 attributes that are easily forged and the 151 behavior/implications of doing that should be documented. 153 S7. Humans (including administrators) SHOULD NOT be 154 required to manage access policy on the basis of 155 attributes which are not "human-readable" (e.g. IP 156 addresses). 158 S8. It MUST be possible to deny a subject the right to 159 invoke a directory operation. The system SHOULD NOT 160 require a specific implementation of denial (e.g. 161 explicit denial, implicit denial). 163 S9. The system MUST be able (semantically) to support 164 either default-grant or default-deny semantics (not 165 simultaneously). 167 S10. The system MUST be able to support either union 168 semantics or intersection semantics for aggregate 169 subjects (not simultaneously). 171 S11. Absence of policy SHOULD be interpretable as grant 172 or deny. Deny takes precedence over grant among entries 173 of equal specificity. 175 S12. ACL policy resolution MUST NOT depend on the order 176 of entries in the ACL. 178 S13. Rights management MUST have no side effects. 179 Granting a subject one right to an object MUST NOT 180 implicitly grant the same or any other subject a 181 different right to the same object. Granting a privilege 182 attribute to one subject MUST NOT implicitly grant the 183 same privilege attribute to any other subject. Granting 184 a privilege attribute to one subject MUST NOT implicitly 185 grant a different privilege attribute to the same or any 186 other subject. Definition: An ACL's "scope" is defined 187 as the set of directory objects governed by the policy it 188 defines; this set of objects is a sub-tree of the 189 directory. Changing the policy asserted by an ACL (by 190 changing one or more of its entries) MUST NOT implicitly 191 change the policy governed by an ACL in a different 192 scope. 194 S14. It SHOULD be possible to apply a single policy to 195 multiple directory entries, even if those entries are in 196 different subtrees. Applying a single policy to multiple 197 directory entries SHOULD NOT require creation and storage 198 of multiple copies of the policy data. The system SHOULD 199 NOT require a specific implementation (e.g. nested 200 groups, named ACLs) of support for policy sharing. 202 3.3 Usability (Manageability) 204 U1. When in doubt, simpler is better, both at the 205 interface and in the implementation. 207 U2. Subjects MUST be drawn from the "natural" LDAP 208 namespace; they should be DNs. 210 U3. It SHOULD NOT be possible via ACL administration to 211 lock all users, including all administrators, out of the 212 directory. 214 U4. Administrators SHOULD NOT be required to evaluate 215 arbitrary Boolean predicates in order to create or 216 understand policy. 218 U5. Administrators SHOULD be able to administer access 219 to directories and their attributes based on their 220 sensitivity, without having to understand the semantics 221 of individual schema elements and their attributes (see 222 U9). 224 U6. Management of access to resources in an entire 225 subtree SHOULD require only one ACL (at the subtree 226 root). Note that this makes access control based 227 explicitly on attribute types very hard, unless you 228 constrain the types of entries in subtrees. For example, 229 another attribute is added to an entry. That attribute 230 may fall outside the grouping covered by the ACL and 231 hence require additional administration where the desired 232 affect is indeed a different ACL. Access control 233 information specified in one administrative area MUST NOT 234 have jurisdiction in another area. You SHOULD NOT be 235 able to control access to the aliased entry in the alias. 236 You SHOULD be able to control access to the alias name. 238 U7. Override of subtree policy MUST be supported on a 239 per-directory-entry basis. 241 U8. Control of access to individual directory entry 242 attributes (not just the whole directory entry) MUST be 243 supported. 245 U9. Administrator MUST be able to coarsen access policy 246 granularity by grouping attributes with similar access 247 sensitivities. 249 U10. Control of access on a per-user granularity MUST be 250 supported. 252 U11. Administrator MUST be able to aggregate users (for 253 example, by assigning them to groups or roles) to 254 simplify administration. 256 U12. It MUST be possible to review "effective access" of 257 any user, group, or role to any entry's attributes. This 258 aids the administrator in setting the correct policy. 260 U13. A single administrator SHOULD be able to define 261 policy for the entire directory tree. An administrator 262 MUST be able to delegate policy administration for 263 specific subtrees to other users. This allows for the 264 partitioning of the entire directory tree for policy 265 administration, but still allows a single policy to be 266 defined for the entire tree independent of partitioning. 267 (Partition in this context means scope of 268 administration). An administrator MUST be able to create 269 new partitions at any point in the directory tree, and 270 MUST be able to merge a superior and subordinate 271 partition. An administrator MUST be able to configure 272 whether delegated access control information from 273 superior partitions is to be accepted or not. 275 U14. It MUST be possible to authorize users to traverse 276 directory structure even if they are not authorized to 277 examine or modify some traversed entries; it MUST also be 278 possible to prohibit this. The tree structure MUST be 279 able to be protected from view if so desired by the 280 administrator. 282 U15. It MUST be possible to create publicly readable 283 entries, which may be read even by unauthenticated 284 clients. 286 U16. The model for combining multiple access control 287 list entries referring to a single individual MUST be 288 easy to understand. 290 U17. Administrator MUST be able to determine where 291 inherited policy information comes from, that is, where 292 ACLs are located and which ACLs were applied. Where 293 inheritance of ACLs is applied, it must be able to be 294 shown how/where that new ACL is derived from. 296 U18. It SHOULD be possible for the administrator to 297 configure the access control system to permit users to 298 grant additional access control rights for entries which 299 they create. 301 4. Security Considerations 303 Access control is a security consideration. This 304 documents addresses the requirements. 306 5. Glossary 308 This glossary is intended to aid the novice not versed in 309 depth about access control. It contains a list [2] of 310 terms and their definitions that are commonly used in 311 discussing access control. 313 Access control - The prevention of use of a resource by 314 unidentified and/or unauthorized entities in any other 315 that an authorized manner. 317 Access control list - A set of control attributes. It is 318 a list, associated with a security object or a group of 319 security objects. The list contains the names of 320 security subjects and the type of access that may be 321 granted. 323 Access control policy - A set of rules, part of a 324 security policy, by which human users, or their 325 representatives, are authenticated and by which access by 326 these users to applications and other services and 327 security objects is granted or denied. 329 Access context - The context, in terms of such variables 330 as location, time of day, level of security of the 331 underlying associations, etc., in which an access to a 332 security object is made. 334 Authorization - The granting of access to a security 335 object. 337 Authorization policy - A set of rules, part of an access 338 control policy, by which access by security subjects to 339 security objects is granted or denied. An authorization 340 policy may be defined in terms of access control lists, 341 capabilities, or attributes assigned to security 342 subjects, security objects, or both. 344 Control attributes - Attributes, associated with a 345 security object that, when matched against the privilege 346 attributes of a security subject, are used to grant or 347 deny access to the security object. An access control 348 list or list of rights or time of day range are examples 349 of control attributes. 351 Credentials - Data that serve to establish the claimed 352 identity of a security subject relative to a given 353 security domain. 355 Privilege attributes - Attributes, associated with a 356 security subject that, when matched against control 357 attributes of a security object, are used to grant or 358 deny access to that subject. Group and role memberships 359 are examples of privilege attributes. 361 Security attributes - A general term covering both 362 privilege attributes and control attributes. The use of 363 security attributes is defined by a security policy. 365 Security object - An entity in a passive role to which a 366 security policy applies. 368 Security policy - A general term covering both access 369 control policies and authorization policies. 371 Security subject - An entity in an active role to which a 372 security policy applies. 374 6. References 376 [1] Steve Kille, Tim Howes, M. Wahl, "Lightweight 377 Directory Access Protocol (v3)", RFC 2251, August 1997. 379 [2] ECMA, "Security in Open Systems: A Security 380 Framework" ECMA TR/46, July 1988 382 AUTHOR(S) ADDRESS 384 Bob Blakley Ellen Stokes 385 Dascom IBM 386 5515 Balcones Drive 11400 Burnet Rd 387 Austin, TX 78731 Austin, TX 78758 388 USA USA 389 mail-to: blakley@dascom.com mail-to: stokes@austin.ibm.com 390 phone: +1 512 458 4037 ext 5012 phone: +1 512 838 3725 391 fax: +1 512 458 2377 fax: +1 512 838 0156 392 Debbie Byrne Prasanta Behera 393 IBM Netscape 394 11400 Burnet Rd 501 Ellis Street 395 Austin, TX 78758 Mountain View, CA 94043 396 USA USA 397 mail-to: djbyrne@us.ibm.com mail-to: prasanta@netscape.com 398 phone: +1 512 838 1930 phone: +1 650 937 4948 399 fax: +1 512 838 8597 fax: +1 650 528-4164 401 7. Full Copyright Statement 403 Copyright (C) The Internet Society (1999).� All Rights 404 Reserved. 406 This document and translations of it may be copied and 407 furnished to others, and derivative works that comment on or 408 otherwise explain it or assist in its implementation may be 409 prepared, copied, published and distributed, in whole or in 410 part, without restriction of any kind, provided that the 411 above copyright notice and this paragraph are included on 412 all such copies and derivative works.� However, this 413 document itself may not be modified in any way, such as by 414 removing the copyright notice or references to the Internet 415 Society or other Internet organizations, except as needed 416 for the purpose of developing Internet standards in which 417 case the procedures for copyrights defined in the Internet 418 Standards process must be followed, or as required to 419 translate it into languages other than English. 421 The limited permissions granted above are perpetual and will 422 not be revoked by the Internet Society or its successors or 423 assigns. 425 This document and the information contained herein is 426 provided on an "AS IS" basis and THE INTERNET SOCIETY AND 427 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 428 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 429 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 430 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 431 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.