git.sur5r.net Git - openldap/blob - doc/drafts/draft-legg-ldap-acm-admin-xx.txt

   1 INTERNET-DRAFT                                                   S. Legg
   2 draft-legg-ldap-acm-admin-03.txt                     Adacel Technologies
   3 Intended 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
  39 Abstract
  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
  52 Legg                    Expires 16 December 2004                [Page 1]
  53 \f
  54 INTERNET-DRAFT        Access Control Administration        June 16, 2004
  55
  56
  57 Table 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
  75 1.  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
  99 2.  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
 108 Legg                    Expires 16 December 2004                [Page 2]
 109 \f
 110 INTERNET-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
 117 3.  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
 144 4.  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
 164 Legg                    Expires 16 December 2004                [Page 3]
 165 \f
 166 INTERNET-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
 184 5.  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
 208 6.  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
 220 Legg                    Expires 16 December 2004                [Page 4]
 221 \f
 222 INTERNET-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
 240 7.  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
 269 8.  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
 276 Legg                    Expires 16 December 2004                [Page 5]
 277 \f
 278 INTERNET-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
 290 9.  Acknowledgements
 291
 292    This document is derived from, and duplicates substantial portions
 293    of, Sections 4 and 8 of X.501 [X501].
 294
 295 10.  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
 319 11.  References
 320
 321 11.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
 332 Legg                    Expires 16 December 2004                [Page 6]
 333 \f
 334 INTERNET-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
 354 11.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
 369 Author'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
 381 Full 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
 388 Legg                    Expires 16 December 2004                [Page 7]
 389 \f
 390 INTERNET-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
 403 Intellectual 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
 427 Changes 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
 434 Changes 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
 440 Changes in Draft 03
 441
 442
 443
 444 Legg                    Expires 16 December 2004                [Page 8]
 445 \f
 446 INTERNET-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
 500 Legg                    Expires 16 December 2004                [Page 9]
 501 \f
 502