1INTERNET-DRAFT S. Legg 2draft-legg-ldap-acm-admin-03.txt Adacel Technologies 3Intended Category: Standards Track June 16, 2004 4 5 6 Lightweight Directory Access Protocol (LDAP): 7 Access Control Administration 8 9 Copyright (C) The Internet Society (2004). All Rights Reserved. 10 11 Status of this Memo 12 13 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 16 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 21 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 26 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 32 33 Distribution of this document is unlimited. Comments should be sent 34 to the author. 35 36 This Internet-Draft expires on 16 December 2004. 37 38 39Abstract 40 41 This document adapts the X.500 directory administrative model, as it 42 pertains to access control administration, for use by the Lightweight 43 Directory Access Protocol. The administrative model partitions the 44 Directory Information Tree for various aspects of directory data 45 administration, e.g., subschema, access control and collective 46 attributes. This document provides the particular definitions that 47 support access control administration, but does not define a 48 particular access control scheme. 49 50 51 52Legg Expires 16 December 2004 [Page 1] 53 54INTERNET-DRAFT Access Control Administration June 16, 2004 55 56 57Table of Contents 58 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Access Control Administrative Areas. . . . . . . . . . . . . . 3 62 4. Access Control Scheme Indication . . . . . . . . . . . . . . . 3 63 5. Access Control Information . . . . . . . . . . . . . . . . . . 4 64 6. Access Control Subentries. . . . . . . . . . . . . . . . . . . 4 65 7. Applicable Access Control Information. . . . . . . . . . . . . 5 66 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 5 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 68 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 11.1. Normative References. . . . . . . . . . . . . . . . . . 6 71 11.2. Informative References. . . . . . . . . . . . . . . . . 7 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 7 74 751. Introduction 76 77 This document adapts the X.500 directory administrative model [X501], 78 as it pertains to access control administration, for use by the 79 Lightweight Directory Access Protocol (LDAP) [RFC3377]. 80 81 The administrative model [ADMIN] partitions the Directory Information 82 Tree (DIT) for various aspects of directory data administration, 83 e.g., subschema, access control and collective attributes. The parts 84 of the administrative model that apply to every aspect of directory 85 data administration are described in [ADMIN]. This document 86 describes the administrative framework for access control. 87 88 An access control scheme describes the means by which access to 89 directory information, and potentially to access rights themselves, 90 may be controlled. This document describes the framework for 91 employing access control schemes but does not define a particular 92 access control scheme. Two access control schemes known as Basic 93 Access Control and Simplified Access Control are defined by [BAC]. 94 Other access control schemes may be defined by other documents. 95 96 This document is derived from, and duplicates substantial portions 97 of, Sections 4 and 8 of X.501 [X501]. 98 992. Conventions 100 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in BCP 14, RFC 2119 104 [RFC2119]. 105 106 107 108Legg Expires 16 December 2004 [Page 2] 109 110INTERNET-DRAFT Access Control Administration June 16, 2004 111 112 113 Schema definitions are provided using LDAP description formats 114 [RFC2252]. Note that the LDAP descriptions have been rendered with 115 additional white-space and line breaks for the sake of readability. 116 1173. Access Control Administrative Areas 118 119 The specific administrative area [ADMIN] for access control is termed 120 an Access Control Specific Area (ACSA). The root of the ACSA is 121 termed an Access Control Specific Point (ACSP) and is represented in 122 the DIT by an administrative entry [ADMIN] which includes 123 accessControlSpecificArea as a value of its administrativeRole 124 operational attribute [SUBENTRY]. 125 126 An ACSA MAY be partitioned into subtrees termed inner administrative 127 areas [ADMIN]. Each such inner area is termed an Access Control 128 Inner Area (ACIA). The root of the ACIA is termed an Access Control 129 Inner Point (ACIP) and is represented in the DIT by an administrative 130 entry which includes accessControlInnerArea as a value of its 131 administrativeRole operational attribute. 132 133 An administrative entry can never be both an ACSP and an ACIP. The 134 corresponding values can therefore never be present simultaneously in 135 the administrativeRole attribute. 136 137 Each entry necessarily falls within one and only one ACSA. Each such 138 entry may also fall within one or more ACIAs nested inside the ACSA 139 containing the entry. 140 141 An ACSP or ACIP has zero, one or more subentries that contain Access 142 Control Information (ACI). 143 1444. Access Control Scheme Indication 145 146 The access control scheme (e.g., Basic Access Control [BAC]) in force 147 in an ACSA is indicated by the accessControlScheme operational 148 attribute contained in the administrative entry for the relevant 149 ACSP. 150 151 The LDAP description [RFC2252] for the accessControlScheme 152 operational attribute is: 153 154 ( 2.5.24.1 NAME 'accessControlScheme' 155 EQUALITY objectIdentifierMatch 156 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 157 SINGLE-VALUE USAGE directoryOperation ) 158 159 An access control scheme conforming to the access control framework 160 described in this document MUST define a distinct OBJECT IDENTIFIER 161 162 163 164Legg Expires 16 December 2004 [Page 3] 165 166INTERNET-DRAFT Access Control Administration June 16, 2004 167 168 169 value to identify it through the accessControlScheme attribute. 170 Object Identifier Descriptors for access control scheme identifiers 171 may be registered with IANA [BCP64]. 172 173 Only administrative entries for ACSPs are permitted to contain an 174 accessControlScheme attribute. If the accessControlScheme attribute 175 is absent from a given ACSP, the access control scheme in force in 176 the corresponding ACSA, and its effect on operations, results and 177 errors, is implementation defined. 178 179 Any entry or subentry in an ACSA is permitted to contain ACI if and 180 only if such ACI is permitted by, and consistent with, the access 181 control scheme identified by the value of the accessControlScheme 182 attribute of the ACSP. 183 1845. Access Control Information 185 186 There are three categories of Access Control Information (ACI): 187 entry, subentry and prescriptive. 188 189 Entry ACI applies to only the entry or subentry in which it appears, 190 and the contents thereof. Subject to the access control scheme, any 191 entry or subentry MAY hold entry ACI. 192 193 Subentry ACI applies to only the subentries of the administrative 194 entry in which it appears. Subject to the access control scheme, any 195 administrative entry, for any aspect of administration, MAY hold 196 subentry ACI. 197 198 Prescriptive ACI applies to all the entries within a subtree or 199 subtree refinement of an administrative area (either an ACSA or an 200 ACIA), as defined by the subtreeSpecification attribute of the 201 subentry in which it appears. Prescriptive ACI is only permitted in 202 subentries of an ACSP or ACIP. Prescriptive ACI in the subentries of 203 a particular administrative point never applies to the same or any 204 other subentry of that administrative point, but does apply to the 205 subentries of subordinate administrative points, where those 206 subentries are within the subtree or subtree refinement. 207 2086. Access Control Subentries 209 210 Each subentry which contains prescriptive ACI MUST have 211 accessControlSubentry as a value of its objectClass attribute. Such 212 a subentry is called an access control subentry. 213 214 The LDAP description [RFC2252] for the accessControlSubentry 215 auxiliary object class is: 216 217 218 219 220Legg Expires 16 December 2004 [Page 4] 221 222INTERNET-DRAFT Access Control Administration June 16, 2004 223 224 225 ( 2.5.17.1 NAME 'accessControlSubentry' AUXILIARY ) 226 227 A subentry of this object class MUST contain at least one 228 prescriptive ACI attribute of a type consistent with the value of the 229 accessControlScheme attribute of the corresponding ACSP. 230 231 The subtree or subtree refinement for an access control subentry is 232 termed a Directory Access Control Domain (DACD). A DACD can contain 233 zero entries, and can encompass entries that have not yet been added 234 to the DIT, but does not extend beyond the scope of the ACSA or ACIA 235 with which it is associated. 236 237 Since a subtreeSpecification may define a subtree refinement, DACDs 238 within a given ACSA may arbitrarily overlap. 239 2407. Applicable Access Control Information 241 242 Although particular items of ACI may specify attributes or values as 243 the protected items, ACI is logically associated with entries. 244 245 The ACI that is considered in access control decisions regarding an 246 entry includes: 247 248 (1) Entry ACI from that particular entry. 249 250 (2) Prescriptive ACI from access control subentries whose DACDs 251 contain the entry. Each of these access control subentries is 252 necessarily either a subordinate of the ACSP for the ACSA 253 containing the entry, or a subordinate of the ACIP for an ACIA 254 that contains the entry. 255 256 The ACI that is considered in access control decisions regarding a 257 subentry includes: 258 259 (1) Entry ACI from that particular subentry. 260 261 (2) Prescriptive ACI from access control subentries whose DACDs 262 contain the subentry, excluding those belonging to the same 263 administrative point as the subentry for which the decision is 264 being made. 265 266 (3) Subentry ACI from the administrative point associated with the 267 subentry. 268 2698. Security Considerations 270 271 This document defines a framework for employing an access control 272 scheme, i.e., the means by which access to directory information and 273 274 275 276Legg Expires 16 December 2004 [Page 5] 277 278INTERNET-DRAFT Access Control Administration June 16, 2004 279 280 281 potentially to access rights themselves may be controlled, but does 282 not itself define any particular access control scheme. The degree 283 of protection provided, and any security risks, are determined by the 284 provisions of the access control schemes (defined elsewhere) making 285 use of this framework. 286 287 Security considerations that apply to directory administration in 288 general [ADMIN] also apply to access control administration. 289 2909. Acknowledgements 291 292 This document is derived from, and duplicates substantial portions 293 of, Sections 4 and 8 of X.501 [X501]. 294 29510. IANA Considerations 296 297 The Internet Assigned Numbers Authority (IANA) is requested to update 298 the LDAP descriptors registry [BCP64] as indicated by the following 299 templates: 300 301 Subject: Request for LDAP Descriptor Registration 302 Descriptor (short name): accessControlScheme 303 Object Identifier: 2.5.24.1 304 Person & email address to contact for further information: 305 Steven Legg <steven.legg@adacel.com.au> 306 Usage: attribute type 307 Specification: RFC XXXX 308 Author/Change Controller: IESG 309 310 Subject: Request for LDAP Descriptor Registration 311 Descriptor (short name): accessControlSubentry 312 Object Identifier: 2.5.17.1 313 Person & email address to contact for further information: 314 Steven Legg <steven.legg@adacel.com.au> 315 Usage: object class 316 Specification: RFC XXXX 317 Author/Change Controller: IESG 318 31911. References 320 32111.1. Normative References 322 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997. 325 326 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, 327 "Lightweight Directory Access Protocol (v3): Attribute 328 Syntax Definitions", RFC 2252, December 1997. 329 330 331 332Legg Expires 16 December 2004 [Page 6] 333 334INTERNET-DRAFT Access Control Administration June 16, 2004 335 336 337 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 338 Protocol (v3): Technical Specification", RFC 3377, 339 September 2002. 340 341 [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA 342 Considerations for the Lightweight Directory Access 343 Protocol (LDAP)", BCP 64, RFC 3383, September 2002. 344 345 [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in the Lightweight 346 Directory Access Protocol (LDAP)", RFC 3672, December 347 2003. 348 349 [ADMIN] Legg, S., "Lightweight Directory Access Protocol (LDAP): 350 Directory Administrative Model", 351 draft-legg-ldap-admin-xx.txt, a work in progress, June 352 2004. 353 35411.2. Informative References 355 356 [COLLECT] Zeilenga, K., "Collective Attributes in the Lightweight 357 Directory Access Protocol (LDAP)", RFC 3671, December 358 2003. 359 360 [BAC] Legg, S., "Lightweight Directory Access Protocol (LDAP): 361 Basic and Simplified Access Control", 362 draft-legg-ldap-acm-bac-xx.txt, a work in progress, June 363 2004. 364 365 [X501] ITU-T Recommendation X.501 (02/01) | ISO/IEC 9594-2:2001, 366 Information technology - Open Systems Interconnection - 367 The Directory: Models 368 369Author's Address 370 371 Steven Legg 372 Adacel Technologies Ltd. 373 250 Bay Street 374 Brighton, Victoria 3186 375 AUSTRALIA 376 377 Phone: +61 3 8530 7710 378 Fax: +61 3 8530 7888 379 EMail: steven.legg@adacel.com.au 380 381Full Copyright Statement 382 383 Copyright (C) The Internet Society (2004). This document is subject 384 to the rights, licenses and restrictions contained in BCP 78, and 385 386 387 388Legg Expires 16 December 2004 [Page 7] 389 390INTERNET-DRAFT Access Control Administration June 16, 2004 391 392 393 except as set forth therein, the authors retain all their rights. 394 395 This document and the information contained herein are provided on an 396 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 397 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 398 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 399 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 400 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 401 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 402 403Intellectual Property 404 405 The IETF takes no position regarding the validity or scope of any 406 Intellectual Property Rights or other rights that might be claimed to 407 pertain to the implementation or use of the technology described in 408 this document or the extent to which any license under such rights 409 might or might not be available; nor does it represent that it has 410 made any independent effort to identify any such rights. Information 411 on the procedures with respect to rights in RFC documents can be 412 found in BCP 78 and BCP 79. 413 414 Copies of IPR disclosures made to the IETF Secretariat and any 415 assurances of licenses to be made available, or the result of an 416 attempt made to obtain a general license or permission for the use of 417 such proprietary rights by implementers or users of this 418 specification can be obtained from the IETF on-line IPR repository at 419 http://www.ietf.org/ipr. 420 421 The IETF invites any interested party to bring to its attention any 422 copyrights, patents or patent applications, or other proprietary 423 rights that may cover technology that may be required to implement 424 this standard. Please address the information to the IETF at 425 ietf-ipr@ietf.org. 426 427Changes in Draft 01 428 429 Section 4 has been extracted to become a separate Internet draft, 430 draft-legg-ldap-admin-00.txt. The subsections of Section 5 have 431 become the new Sections 3 to 7. Editorial changes have been made to 432 accommodate this split. No technical changes have been introduced. 433 434Changes in Draft 02 435 436 RFC 3377 replaces RFC 2251 as the reference for LDAP. 437 438 An IANA Considerations section has been added. 439 440Changes in Draft 03 441 442 443 444Legg Expires 16 December 2004 [Page 8] 445 446INTERNET-DRAFT Access Control Administration June 16, 2004 447 448 449 The document has been reformatted in line with current practice. 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500Legg Expires 16 December 2004 [Page 9] 501 502 503