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