1193323SedINTERNET-DRAFT S. Legg 2193323Seddraft-legg-ldap-admin-02.txt Adacel Technologies 3193323SedIntended Category: Standards Track June 16, 2004 4193323Sed 5193323Sed 6193323Sed Lightweight Directory Access Protocol (LDAP): 7193323Sed Directory Administrative Model 8193323Sed 9193323Sed Copyright (C) The Internet Society (2004). All Rights Reserved. 10193323Sed 11193323Sed Status of this Memo 12193323Sed 13193323Sed 14193323Sed This document is an Internet-Draft and is in full conformance with 15193323Sed all provisions of Section 10 of RFC2026. 16193323Sed 17193323Sed Internet-Drafts are working documents of the Internet Engineering 18193323Sed Task Force (IETF), its areas, and its working groups. Note that 19193323Sed other groups may also distribute working documents as 20193323Sed Internet-Drafts. 21193323Sed 22193323Sed Internet-Drafts are draft documents valid for a maximum of six months 23193323Sed and may be updated, replaced, or obsoleted by other documents at any 24193323Sed time. It is inappropriate to use Internet-Drafts as reference 25193323Sed material or to cite them other than as "work in progress". 26193323Sed 27193323Sed The list of current Internet-Drafts can be accessed at 28193323Sed http://www.ietf.org/ietf/1id-abstracts.txt 29245431Sdim 30193323Sed The list of Internet-Draft Shadow Directories can be accessed at 31193323Sed http://www.ietf.org/shadow.html. 32193323Sed 33193323Sed Distribution of this document is unlimited. Comments should be sent 34193323Sed to the author. 35193323Sed 36235633Sdim This Internet-Draft expires on 16 December 2004. 37193323Sed 38193323Sed 39193323SedAbstract 40193323Sed 41193323Sed This document adapts the X.500 directory administrative model for use 42193323Sed by the Lightweight Directory Access Protocol. The administrative 43193323Sed model partitions the Directory Information Tree for various aspects 44193323Sed of directory data administration, e.g., subschema, access control and 45245431Sdim collective attributes. The generic framework that applies to every 46193323Sed aspect of administration is described in this document. The 47193323Sed definitions that apply for a specific aspect of administration, e.g., 48193323Sed access control administration, are described in other documents. 49193323Sed 50193323Sed 51193323Sed 52193323SedLegg Expires 16 December 2004 [Page 1] 53193323Sed 54193323SedINTERNET-DRAFT Directory Administrative Model June 16, 2004 55193323Sed 56193323Sed 57193323SedTable of Contents 58245431Sdim 59193323Sed 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60193323Sed 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 2 61193323Sed 3. Administrative Areas . . . . . . . . . . . . . . . . . . . . . 2 62193323Sed 4. Autonomous Administrative Areas. . . . . . . . . . . . . . . . 3 63193323Sed 5. Specific Administrative Areas. . . . . . . . . . . . . . . . . 3 64193323Sed 6. Inner Administrative Areas . . . . . . . . . . . . . . . . . . 4 65193323Sed 7. Administrative Entries . . . . . . . . . . . . . . . . . . . . 4 66193323Sed 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 5 67193323Sed 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 68193323Sed 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69193323Sed 10.1. Normative References. . . . . . . . . . . . . . . . . . 5 70193323Sed 10.2. Informative References. . . . . . . . . . . . . . . . . 5 71193323Sed 11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 72193323Sed Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 6 73193323Sed 74193323Sed1. Introduction 75245431Sdim 76193323Sed This document adapts the X.500 directory administrative model [X501] 77193323Sed for use by the Lightweight Directory Access Protocol (LDAP) [LDAP]. 78193323Sed The administrative model partitions the Directory Information Tree 79245431Sdim (DIT) for various aspects of directory data administration, e.g., 80193323Sed subschema, access control and collective attributes. This document 81193323Sed provides the definitions for the generic parts of the administrative 82193323Sed model that apply to every aspect of directory data administration. 83193323Sed 84193323Sed Sections 3 to 7, in conjunction with [SUBENTRY], describe the means 85193323Sed by which administrative authority is aportioned and exercised in the 86193323Sed DIT. 87193323Sed 88193323Sed Aspects of administration that conform to the administrative model 89193323Sed described in this document are detailed elsewhere, e.g., access 90193323Sed control administration is described in [ACA] and collective attribute 91245431Sdim administration is described in [COLLECT]. 92193323Sed 93193323Sed This document is derived from, and duplicates substantial portions 94193323Sed of, Sections 4 and 8 of X.501 [X501]. 95193323Sed 96193323Sed2. Conventions 97193323Sed 98193323Sed The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99193323Sed "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100193323Sed document are to be interpreted as described in BCP 14, RFC 2119 101193323Sed [RFC2119]. 102245431Sdim 103193323Sed3. Administrative Areas 104193323Sed 105193323Sed 106193323Sed 107193323Sed 108193323SedLegg Expires 16 December 2004 [Page 2] 109193323Sed 110193323SedINTERNET-DRAFT Directory Administrative Model June 16, 2004 111193323Sed 112193323Sed 113193323Sed An administrative area is a subtree of the DIT considered from the 114193323Sed perspective of administration. The root entry of the subtree is an 115193323Sed administrative point. An administrative point is represented by an 116193323Sed entry holding an administrativeRole attribute [SUBENTRY]. The values 117193323Sed of this attribute identify the kind of administrative point. 118193323Sed 119193323Sed4. Autonomous Administrative Areas 120193323Sed 121193323Sed The DIT may be partitioned into one or more non-overlapping subtrees 122193323Sed termed autonomous administrative areas. It is expected that the 123193323Sed entries in an autonomous administrative area are all administered by 124193323Sed the same administrative authority. 125193323Sed 126193323Sed An administrative authority may be responsible for several autonomous 127193323Sed administrative areas in separated parts of the DIT but it SHOULD NOT 128193323Sed arbitrarily partition the collection of entries under its control 129193323Sed into autonomous administrative areas (thus creating adjacent 130245431Sdim autonomous areas administered by the same authority). 131193323Sed 132193323Sed The root entry of an autonomous administrative area's subtree is 133193323Sed called an autonomous administrative point. An autonomous 134201360Srdivacky administrative area extends from its autonomous administrative point 135193323Sed downwards until another autonomous administrative point is 136201360Srdivacky encountered, at which point another autonomous administrative area 137193323Sed begins. 138245431Sdim 139193323Sed5. Specific Administrative Areas 140193323Sed 141193323Sed Entries in an administrative area may be considered in terms of a 142193323Sed specific administrative function. When viewed in this context, an 143193323Sed administrative area is termed a specific administrative area. 144193323Sed 145193323Sed Examples of specific administrative areas are subschema specific 146193323Sed administrative areas, access control specific areas and collective 147193323Sed attribute specific areas. 148193323Sed 149193323Sed An autonomous administrative area may be considered as implicitly 150193323Sed defining a single specific administrative area for each specific 151193323Sed aspect of administration. In this case, there is a precise 152193323Sed correspondence between each such specific administrative area and the 153193323Sed autonomous administrative area. 154193323Sed 155193323Sed Alternatively, for each specific aspect of administration, the 156193323Sed autonomous administrative area may be partitioned into 157193323Sed non-overlapping specific administrative areas. 158193323Sed 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