1INTERNET-DRAFT S. Legg 2draft-legg-ldap-admin-02.txt Adacel Technologies 3Intended Category: Standards Track June 16, 2004 4 5 6 Lightweight Directory Access Protocol (LDAP): 7 Directory Administrative Model 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 for use 42 by the Lightweight Directory Access Protocol. The administrative 43 model partitions the Directory Information Tree for various aspects 44 of directory data administration, e.g., subschema, access control and 45 collective attributes. The generic framework that applies to every 46 aspect of administration is described in this document. The 47 definitions that apply for a specific aspect of administration, e.g., 48 access control administration, are described in other documents. 49 50 51 52Legg Expires 16 December 2004 [Page 1] 53 54INTERNET-DRAFT Directory Administrative Model June 16, 2004 55 56 57Table of Contents 58 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Administrative Areas . . . . . . . . . . . . . . . . . . . . . 2 62 4. Autonomous Administrative Areas. . . . . . . . . . . . . . . . 3 63 5. Specific Administrative Areas. . . . . . . . . . . . . . . . . 3 64 6. Inner Administrative Areas . . . . . . . . . . . . . . . . . . 4 65 7. Administrative Entries . . . . . . . . . . . . . . . . . . . . 4 66 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 5 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 10.1. Normative References. . . . . . . . . . . . . . . . . . 5 70 10.2. Informative References. . . . . . . . . . . . . . . . . 5 71 11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 72 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 6 73 741. Introduction 75 76 This document adapts the X.500 directory administrative model [X501] 77 for use by the Lightweight Directory Access Protocol (LDAP) [LDAP]. 78 The administrative model partitions the Directory Information Tree 79 (DIT) for various aspects of directory data administration, e.g., 80 subschema, access control and collective attributes. This document 81 provides the definitions for the generic parts of the administrative 82 model that apply to every aspect of directory data administration. 83 84 Sections 3 to 7, in conjunction with [SUBENTRY], describe the means 85 by which administrative authority is aportioned and exercised in the 86 DIT. 87 88 Aspects of administration that conform to the administrative model 89 described in this document are detailed elsewhere, e.g., access 90 control administration is described in [ACA] and collective attribute 91 administration is described in [COLLECT]. 92 93 This document is derived from, and duplicates substantial portions 94 of, Sections 4 and 8 of X.501 [X501]. 95 962. Conventions 97 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in BCP 14, RFC 2119 101 [RFC2119]. 102 1033. Administrative Areas 104 105 106 107 108Legg Expires 16 December 2004 [Page 2] 109 110INTERNET-DRAFT Directory Administrative Model June 16, 2004 111 112 113 An administrative area is a subtree of the DIT considered from the 114 perspective of administration. The root entry of the subtree is an 115 administrative point. An administrative point is represented by an 116 entry holding an administrativeRole attribute [SUBENTRY]. The values 117 of this attribute identify the kind of administrative point. 118 1194. Autonomous Administrative Areas 120 121 The DIT may be partitioned into one or more non-overlapping subtrees 122 termed autonomous administrative areas. It is expected that the 123 entries in an autonomous administrative area are all administered by 124 the same administrative authority. 125 126 An administrative authority may be responsible for several autonomous 127 administrative areas in separated parts of the DIT but it SHOULD NOT 128 arbitrarily partition the collection of entries under its control 129 into autonomous administrative areas (thus creating adjacent 130 autonomous areas administered by the same authority). 131 132 The root entry of an autonomous administrative area's subtree is 133 called an autonomous administrative point. An autonomous 134 administrative area extends from its autonomous administrative point 135 downwards until another autonomous administrative point is 136 encountered, at which point another autonomous administrative area 137 begins. 138 1395. Specific Administrative Areas 140 141 Entries in an administrative area may be considered in terms of a 142 specific administrative function. When viewed in this context, an 143 administrative area is termed a specific administrative area. 144 145 Examples of specific administrative areas are subschema specific 146 administrative areas, access control specific areas and collective 147 attribute specific areas. 148 149 An autonomous administrative area may be considered as implicitly 150 defining a single specific administrative area for each specific 151 aspect of administration. In this case, there is a precise 152 correspondence between each such specific administrative area and the 153 autonomous administrative area. 154 155 Alternatively, for each specific aspect of administration, the 156 autonomous administrative area may be partitioned into 157 non-overlapping specific administrative areas. 158 159 If so partitioned for a particular aspect of administration, each 160 entry of the autonomous administrative area is contained in one and 161 162 163 164Legg Expires 16 December 2004 [Page 3] 165 166INTERNET-DRAFT Directory Administrative Model June 16, 2004 167 168 169 only one specific administrative area for that aspect, i.e., specific 170 administrative areas do not overlap. 171 172 The root entry of a specific administrative area's subtree is called 173 a specific administrative point. A specific administrative area 174 extends from its specific administrative point downwards until 175 another specific administrative point of the same administrative 176 aspect is encountered, at which point another specific administrative 177 area begins. Specific administrative areas are always bounded by the 178 autonomous administrative area they partition. 179 180 Where an autonomous administrative area is not partitioned for a 181 specific aspect of administration, the specific administrative area 182 for that aspect coincides with the autonomous administrative area. 183 In this case, the autonomous administrative point is also the 184 specific administrative point for this aspect of administration. A 185 particular administrative point may be the root of an autonomous 186 administrative area and may be the root of one or more specific 187 administrative areas for different aspects of administration. 188 189 It is not necessary for an administrative point to represent each 190 specific aspect of administrative authority. For example, there 191 might be an administrative point, subordinate to the root of the 192 autonomous administrative area, which is used for access control 193 purposes only. 194 1956. Inner Administrative Areas 196 197 For some aspects of administration, e.g., access control or 198 collective attributes, inner administrative areas may be defined 199 within the specific administrative areas, to allow a limited form of 200 delegation, or for administrative or operational convenience. 201 202 An inner administrative area may be nested within another inner 203 administrative area. The rules for nested inner areas are defined as 204 part of the definition of the specific administrative aspect for 205 which they are allowed. 206 207 The root entry of an inner administrative area's subtree is called an 208 inner administrative point. An inner administrative area (within a 209 specific administrative area) extends from its inner administrative 210 point downwards until a specific administrative point of the same 211 administrative aspect is encountered. An inner administrative area 212 is bounded by the specific administrative area within which it is 213 defined. 214 2157. Administrative Entries 216 217 218 219 220Legg Expires 16 December 2004 [Page 4] 221 222INTERNET-DRAFT Directory Administrative Model June 16, 2004 223 224 225 An entry located at an administrative point is an administrative 226 entry. Administrative entries MAY have subentries [SUBENTRY] as 227 immediate subordinates. The administrative entry and its associated 228 subentries are used to control the entries encompassed by the 229 associated administrative area. Where inner administrative areas are 230 used, the scopes of these areas may overlap. Therefore, for each 231 specific aspect of administrative authority, a definition is required 232 of the method of combination of administrative information when it is 233 possible for entries to be included in more than one subtree or 234 subtree refinement associated with an inner area defined for that 235 aspect. 236 2378. Security Considerations 238 239 This document defines a generic framework for employing policy of 240 various kinds, e.g., access controls, to entries in the DIT. Such 241 policy can only be correctly enforced at a directory server holding a 242 replica of a portion of the DIT if the administrative entries for 243 administrative areas that overlap the portion of the DIT being 244 replicated, and the subentries of those administrative entries 245 relevant to any aspect of policy that is required to be enforced at 246 the replica, are included in the replicated information. 247 248 Administrative entries and subentries SHOULD be protected from 249 unauthorized examination or changes by appropriate access controls. 250 2519. Acknowledgements 252 253 This document is derived from, and duplicates substantial portions 254 of, Sections 4 and 8 of X.501 [X501]. 255 25610. References 257 25810.1. Normative References 259 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 263 [LDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access 264 Protocol (v3): Technical Specification", RFC 3377, 265 September 2002. 266 267 [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in the Lightweight 268 Directory Access Protocol (LDAP)", RFC 3672, December 269 2003. 270 27110.2. Informative References 272 273 274 275 276Legg Expires 16 December 2004 [Page 5] 277 278INTERNET-DRAFT Directory Administrative Model June 16, 2004 279 280 281 [COLLECT] Zeilenga, K., "Collective Attributes in the Lightweight 282 Directory Access Protocol (LDAP)", RFC 3671, December 283 2003. 284 285 [ACA] Legg, S., "Lightweight Directory Access Protocol (LDAP): 286 Access Control Administration", 287 draft-legg-ldap-acm-admin-xx.txt, a work in progress, June 288 2004. 289 290 [X501] ITU-T Recommendation X.501 (02/01) | ISO/IEC 9594-2:2001, 291 Information technology - Open Systems Interconnection - 292 The Directory: Models 293 29411. Author's Address 295 296 Steven Legg 297 Adacel Technologies Ltd. 298 250 Bay Street 299 Brighton, Victoria 3186 300 AUSTRALIA 301 302 Phone: +61 3 8530 7710 303 Fax: +61 3 8530 7888 304 EMail: steven.legg@adacel.com.au 305 306Full Copyright Statement 307 308 Copyright (C) The Internet Society (2004). This document is subject 309 to the rights, licenses and restrictions contained in BCP 78, and 310 except as set forth therein, the authors retain all their rights. 311 312 This document and the information contained herein are provided on an 313 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 314 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 315 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 316 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 317 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 318 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 319 320Intellectual Property 321 322 The IETF takes no position regarding the validity or scope of any 323 Intellectual Property Rights or other rights that might be claimed to 324 pertain to the implementation or use of the technology described in 325 this document or the extent to which any license under such rights 326 might or might not be available; nor does it represent that it has 327 made any independent effort to identify any such rights. Information 328 on the procedures with respect to rights in RFC documents can be 329 330 331 332Legg Expires 16 December 2004 [Page 6] 333 334INTERNET-DRAFT Directory Administrative Model June 16, 2004 335 336 337 found in BCP 78 and BCP 79. 338 339 Copies of IPR disclosures made to the IETF Secretariat and any 340 assurances of licenses to be made available, or the result of an 341 attempt made to obtain a general license or permission for the use of 342 such proprietary rights by implementers or users of this 343 specification can be obtained from the IETF on-line IPR repository at 344 http://www.ietf.org/ipr. 345 346 The IETF invites any interested party to bring to its attention any 347 copyrights, patents or patent applications, or other proprietary 348 rights that may cover technology that may be required to implement 349 this standard. Please address the information to the IETF at 350 ietf-ipr@ietf.org. 351 352Changes in Draft 00 353 354 This document reproduces Section 4 from 355 draft-legg-ldap-acm-admin-00.txt as a standalone document. All 356 changes made are purely editorial. No technical changes have been 357 introduced. 358 359Changes in Draft 01 360 361 RFC 3377 replaces RFC 2251 as the reference for LDAP. 362 363Changes in Draft 02 364 365 The document has been reformatted in line with current practice. 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388Legg Expires 16 December 2004 [Page 7] 389 390 391