git.sur5r.net Git - openldap/blob - doc/drafts/draft-ietf-ldapext-acl-model-xx.txt

   1           Internet-Draft                                     E. Stokes
   2           LDAP Extensions WG                                  D. Byrne
   3           Intended Category: Standards Track                B. Blakley
   4           Expires: 25 December 1999                                IBM
   5                                                           25 June 1999
   6
   7                          Access Control Model for LDAP
   8                      <draft-ietf-ldapext-acl-model-03.txt>
   9
  10           STATUS OF THIS MEMO
  11
  12              This document is an Internet-Draft and is in full
  13              conformance with all provisions of Section 10 of RFC2026.
  14
  15              Internet-Drafts are working documents of the Internet
  16              Engineering Task Force (IETF), its areas, and its working
  17              groups. Note that other groups may also distribute
  18              working documents as Internet-Drafts. Internet-Drafts are
  19              draft documents valid for a maximum of six months and may
  20              be updated, replaced, or obsoleted by other documents at
  21              any time. It is inappropriate to use Internet- Drafts as
  22              reference material or to cite them other than as "work in
  23              progress."
  24
  25              The list of current Internet-Drafts can be accessed at
  26              http://www.ietf.org/ietf/1id-abstracts.txt
  27
  28              The list of Internet-Draft Shadow Directories can be
  29              accessed at http://www.ietf.org/shadow.html.
  30
  31              Comments and suggestions on this document are encouraged.
  32              Comments on this document should be sent to the  LDAPEXT
  33              working group discussion list:
  34
  35                     ietf-ldapext@netscape.com
  36
  37           COPYRIGHT NOTICE
  38              Copyright (C) The Internet Society (1997).  All Rights
  39              Reserved.
  40
  41           ABSTRACT
  42
  43              This document describes the access control model for the
  44              Lightweight Directory Application Protocol (LDAP)
  45              directory service. It includes a description of the
  46
  47
  48
  49           Stokes, Byrne, Blakley   Expires 25 December 1999         [Page 1]
  50
  51
  52
  53
  54
  55
  56           Internet-Draft      Access Control Model        25 June 1999
  57
  58
  59
  60              model, the LDAP controls, and the extended operations to
  61              the LDAP protocol.  A separate document defines the
  62              corresponding application programming interfaces (APIs).
  63              RFC2219 [Bradner97] terminology is used.
  64
  65
  66
  67           1.  Introduction
  68
  69              The ability to securely access (replicate and distribute)
  70              directory information throughout the network is necessary
  71              for successful deployment.  LDAP's acceptance as an
  72              access protocol for directory information is driving the
  73              need to provide an access control model definition for
  74              LDAP directory content among servers within an enterprise
  75              and the Internet.  Currently LDAP does not define an
  76              access control model, but is needed to ensure consistent
  77              secure access across heterogeneous LDAP implementations.
  78              The major objective is to provide a simple, but secure,
  79              highly efficient access control model for LDAP while also
  80              providing the appropriate flexibility to meet the needs
  81              of both the Internet and enterprise environments and
  82              policies.  This document defines the model and the
  83              protocol extensions (controls and extended operations).
  84              A separate document defines the corresponding application
  85              programming interfaces (APIs).
  86
  87
  88           2.  Overview
  89
  90              Access Control mechanisms evaluate requests for access to
  91              protected resources and make decisions about whether
  92              those requests should be granted or denied.  In order to
  93              make a grant/deny decision about a request for access to
  94              a protected resource, an access control mechanism needs
  95              to evaluate policy data.  This policy data describes
  96              security-relevant characteristics of the requesting
  97              subject and the rules which govern the use of the target
  98              object.
  99
 100              This proposal defines the protocol elements for
 101              transmission of this access control policy data in an
 102              LDAP environment and an attribute that defines the access
 103              control mechanism in effect for a given part of the LDAP
 104              namespace.  The instantiation of an access control model
 105
 106
 107
 108           Stokes, Byrne, Blakley   Expires 25 December 1999         [Page 2]
 109
 110
 111
 112
 113
 114
 115           Internet-Draft      Access Control Model        25 June 1999
 116
 117
 118
 119              at the directory server is not defined in this document.
 120              By defining only what flows on the wire allows existing
 121              access control mechanisms to be used at the directory
 122              server.
 123
 124              No mechanisms are defined in this document to control
 125              access to access control information or for storage of
 126              access control information at the server; this is vendor
 127              dependent.
 128
 129              A separate requirements document for access control
 130              exists.  The access control model used the requirements
 131              documents as a guideline for the development of this
 132              specification and are reflected in this specification to
 133              the extent that the working group could agree on an
 134              access control model.
 135
 136              The access control model defines
 137
 138                 - A wire protocol for interoperability:  The existing
 139                   LDAP protocol flows for add, delete, modify, etc are
 140                   used to manipulate access control information.
 141                   There are additional LDAP controls and extended
 142                   protocol operations defined to further help
 143                   management of access control information:
 144                   getEffectiveRights and specifyCredentials.
 145
 146                 - A set of access control information (ACI) attributes
 147                   for application portability:  These attributes are
 148                   used as input to the LDAP APIs so access control
 149                   information can be addressed uniformly independent
 150                   of how that information is addressed and stored at
 151                   the server. These same attributes appear in LDIF
 152                   output for interchange of access control
 153                   information.
 154
 155                 - A set of attributes to identity the access control
 156                   mechanisms supported by a server.
 157
 158              Encoding of access control information on the wire is per
 159              the LDAPv3 specifications.
 160
 161
 162
 163
 164
 165
 166
 167           Stokes, Byrne, Blakley   Expires 25 December 1999         [Page 3]
 168
 169
 170
 171
 172
 173
 174           Internet-Draft      Access Control Model        25 June 1999
 175
 176
 177
 178           3.  Terminology
 179
 180              An "access control list" contains the access control
 181              policy information controlling access to an object or
 182              collection of objects.  An access control list consists
 183              of a set of access control list entries.
 184
 185              An "access control list entry" defines a single subject
 186              security attribute's granted rights for the objects
 187              governed by the access control list to which it belongs.
 188
 189              The "access control policy information" (acpi) for an
 190              object or a collection of objects defines which subject
 191              security attributes entitle a subject to which granted
 192              rights.  The access control policy information for an
 193              object is stored in an access control list.
 194
 195              An "access decision" is a boolean-valued function which
 196              answers the question: "can the subject with these subject
 197              security attributes perform this operation on this
 198              object?"
 199
 200              An "access decision function" is an algorithm which makes
 201              an access decision based on subject security attributes,
 202              access control policy information, an object identifier,
 203              and an operation name (possibly augmented by additional
 204              contextual information).
 205
 206              An "access decision function interface" is a programmatic
 207              interface through which applications can request an
 208              access decision.
 209
 210              An "access identity" is an identity which is used by an
 211              access decision function to make an access decision.
 212
 213              An "audit identity" is an identity which does not, in the
 214              absence of additional information, enable a party
 215              receiving and examining it to determine which subject it
 216              belongs to.
 217
 218              A "credential" is a collection of subject security
 219              attributes.
 220
 221              "effective rights" are the complete set of rights a
 222              subject is entitled to based on all access control lists
 223
 224
 225
 226           Stokes, Byrne, Blakley   Expires 25 December 1999         [Page 4]
 227
 228
 229
 230
 231
 232
 233           Internet-Draft      Access Control Model        25 June 1999
 234
 235
 236
 237              which apply to a specific object and based on all of the
 238              subject's security attributes.
 239
 240              "granted rights" are the complete set of rights an access
 241              control list entitles a subject to based on a specific
 242              subject security attribute.
 243
 244              A "group" is a privilege attribute asserting a subject's
 245              membership in the collection of subjects whose name is
 246              that of the group.
 247
 248              An "identity" is a subject security attribute which is
 249              unique to a single subject.
 250
 251              An "object" is the target of operations in an information
 252              system.
 253
 254              An "operation" is the result of executing the code
 255              accessed through a named entry point in an information
 256              system.
 257
 258              An "operation name" is the name of the entry point
 259              through which an operation is invoked in an information
 260              system.
 261
 262              A "privilege attribute" is a subject security attribute
 263              which may be shared by several subjects.
 264
 265              "required rights" are the complete set of rights needed
 266              to authorize a requester to perform a specific operation
 267              on an object of a specific type.
 268
 269              A "right" is the basic unit of access control policy
 270              administration.  For each object type in an information
 271              system, a security administrator defines a set of
 272              required rights for each operation.  For each object in
 273              the system, a security administrator defines a set of
 274              granted rights for each subject security attribute.  When
 275              an access decision is required, an access decision
 276              function checks to make sure that the requester's subject
 277              security attributes have been granted all required rights
 278              needed to perform the requested operation on the
 279              specified target object.
 280
 281              A "role" is a privilege attribute asserting a subject's
 282
 283
 284
 285           Stokes, Byrne, Blakley   Expires 25 December 1999         [Page 5]
 286
 287
 288
 289
 290
 291
 292           Internet-Draft      Access Control Model        25 June 1999
 293
 294
 295
 296              organizational position and entitlement to perform the
 297              operations appropriate to that organizational position.
 298
 299              A "subject" is an entity which intiates actions in an
 300              information system.
 301
 302              A "subject security attribute" is a defined property
 303              which is used by a security policy evaluation system to
 304              make policy decisions.
 305
 306
 307           4.  The Model
 308
 309
 310           4.1  Access Control Activity Lifecycle
 311
 312              The access control proposal described in this draft
 313              addresses four activities:
 314
 315                 - Creation of subject security attribute information
 316                   and access control policy information
 317
 318                 - Retrieval of subject security attribute information
 319                   at the time an access request is made
 320
 321                 - Evaluation of access requests against policy,
 322                   resulting in an access decision
 323
 324                 - Replication of access control policy information
 325                   from one server to another
 326
 327           4.2  Access Control Information Model
 328
 329              This document does not define formats for storage of
 330              access control information; it does define the
 331              operational semantics of access control operations.
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344           Stokes, Byrne, Blakley   Expires 25 December 1999         [Page 6]
 345
 346
 347
 348
 349
 350
 351           Internet-Draft      Access Control Model        25 June 1999
 352
 353
 354
 355              The diagram below illustrates the componentry of an LDAP
 356              system and the placement of the function specified in
 357              this draft.
 358
 359                          +-------------+
 360                          | Application |
 361                          +-------------+
 362                            +--------+
 363                            | LDAP   |
 364                            | Client |
 365                            +--------+
 366                                |
 367                                |
 368                                | <-- LDAP Extended Access Control
 369              Controls
 370                                |     or Extended Access Control
 371              Operations
 372                                v
 373                     +-----------------------------+
 374                     |   LDAP Server (e.g. SLAPD)  |
 375                     +-----------------------------+
 376                           .                 |
 377                           .                 |
 378                           .                 |
 379                           .                 |
 380                           v                 v
 381                     +----------+      +-----------+
 382                     | Access   |      |           |
 383                     | Control  |<.....| Datastore |
 384                     | Manager  |      |           |
 385                     +----------+      +-----------+
 386
 387              LDAP clients use the controls and extended operations
 388              specified in this document to administer access control
 389              policy enforced by LDAP servers.  Servers may store
 390              access control information in any way they choose. In
 391              particular, servers may use the access control mechanisms
 392              of their datastores to store and enforce LDAP access
 393              control, or they may implement access control managers
 394              external to their datastores.  Datastores and external
 395              access control managers may implement  any access control
 396              rule syntax and semantics they choose, as long as the
 397              semantics is compatible with that defined in the section
 398              titled "Operational Semantics of Access Control
 399              Operations" (found after the control and extended
 400
 401
 402
 403           Stokes, Byrne, Blakley   Expires 25 December 1999         [Page 7]
 404
 405
 406
 407
 408
 409
 410           Internet-Draft      Access Control Model        25 June 1999
 411
 412
 413
 414              operation definition).
 415
 416              The access control administration mechanisms specified in
 417              this document are neutral with respect to policy
 418              inheritance mechanisms, explicit vs.  implicit denial,
 419              and group nesting.
 420
 421           4.3  Bind and Credentials
 422
 423              A bind authenticates a principal to the directory.  A
 424              principal is represented by a DN.  A principal has a set
 425              of credentials that are used for determining whether
 426              access to resources specified in ldap operations.  These
 427              credentials may be pushed to the server by the client or
 428              may be pulled by the server from the directory data.
 429              Credentials may be local with respect to the server.  If
 430              not local (owned by another server or administrative
 431              scope), then the server may decide to define a trust
 432              model that states how to evaluate the trust of a
 433              credential at bind time.  The definition of such a trust
 434              model is outside the scope of this document.
 435
 436
 437           5.  Access Control Information Schema
 438
 439
 440           5.1  Attributes
 441
 442
 443           5.1.1  Root DSE Attribute for Access Control Mechanism
 444
 445              The following attribute may be included in the Root DSE.
 446
 447               (<OID to be assigned>
 448                  NAME      'supportedACIMechanisms'
 449                  DESC      list of access control mechanisms supported
 450                              by this directory server
 451                  SYNTAX    LDAPOID
 452               )
 453
 454              Two access control mechanisms are defined by this
 455              document:
 456                   LDAPv3     <OID to be assigned>
 457                   X500       <OID to be assigned>
 458
 459
 460
 461
 462           Stokes, Byrne, Blakley   Expires 25 December 1999         [Page 8]
 463
 464
 465
 466
 467
 468
 469           Internet-Draft      Access Control Model        25 June 1999
 470
 471
 472
 473              Other vendor access control mechanisms can be defined (by
 474              OID) and are the responsibility of those vendors to
 475              provide the definition and OID.
 476
 477           5.1.2  Subschema Attribute for Access Control Mechanism
 478
 479              A given naming context must provide information about
 480              which access control mechanism is in effect for that
 481              portion of the namespace.  The following attribute must
 482              be in each subschema entry associated with a naming
 483              context whose access control mechanism is different from
 484              adjacent naming contexts supported by that directory
 485              server.
 486
 487                 - aCIMechanism lists the value (an OID) that defines
 488                   the access control mechanism in effect for the scope
 489                   of that subschema entry
 490
 491           5.2  Other Defined Parameters/OIDs
 492
 493
 494           5.2.1  Rights Families and Rights
 495
 496              The following rights families are defined:
 497                   LDAPv3     <OID to be assigned>
 498                   X500       <OID to be assigned>
 499
 500              Other parties can (and will) define other rights
 501              families.  It is the responsibility of those parties to
 502              provide the definition and OID.
 503
 504           5.2.1.1  LDAPv3 Rights Family
 505
 506              Access rights can apply to an entire object or to
 507              attributes of the object.  Each of the LDAP access rights
 508              are discrete. One permission does not imply another
 509              permission.  The rights may be ORed together to provide
 510              the desired rights list.
 511
 512              Rights which apply to attributes are:
 513
 514                 1   Read     Read attribute values
 515                 2   Write    Write attribute values
 516                 4   Search   Search entries with specified attributes
 517                 8   Compare  Compare attributes
 518
 519
 520
 521           Stokes, Byrne, Blakley   Expires 25 December 1999         [Page 9]
 522
 523
 524
 525
 526
 527
 528           Internet-Draft      Access Control Model        25 June 1999
 529
 530
 531
 532              Rights that apply to an entire object are:
 533
 534                 16   Add      Add an object below this object
 535                 32   Delete   Delete this object
 536                 64   EditDN   Edit an object's DN
 537
 538              Rights that apply to the object to which the directory
 539              object points are:
 540
 541                128   Manage   Perform a privileged operation; used to
 542                               restrict access to operations which
 543                               read or write especially sensitive data
 544                256   Use      Execute; useful in controlling access to
 545                               the objects referred to by directory
 546                               entries than in controlling access to
 547                               the directory entries themselves
 548                512   Get      Get retrieves the attribute values
 549               1024   Set      Set writes the attribute values
 550
 551           5.2.1.2  The X.500 Rights Family
 552
 553              <define the rights for X.500>
 554
 555           5.2.2  DN Types
 556
 557              The following DN Types are defined:
 558
 559                 - access-id, OID=<OID to be assigned>
 560
 561                 - group, OID=<OID to be assigned>
 562
 563                 - role, OID=<OID to be assigned>
 564
 565              access-id, group, and role MUST be supported.  An acess-
 566              id is a non-collection (non-group and non-role objects)
 567              DN that can be authenticated.
 568
 569              Other parties can (and will) define other DN Types.  It
 570              is the responsibility of those parties to provide the
 571              definition and OID.
 572
 573
 574
 575
 576
 577
 578
 579
 580           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 10]
 581
 582
 583
 584
 585
 586
 587           Internet-Draft      Access Control Model        25 June 1999
 588
 589
 590
 591           6.  Access Control Parameters for LDAP Controls & Extended
 592           Operations
 593
 594              This section defines the parameters used in the access
 595              control LDAP controls and extended operations in this
 596              document.
 597
 598              targetDN specifies the initial directory entry in DN
 599              syntax on which the control or extended operation is
 600              performed.
 601
 602              whichObject specifies whether the access control
 603              information which is get/set is for the target directory
 604              entry (ENTRY) or the target directory entry and its
 605              subtree (SUBTREE).
 606
 607              rightsFamily specifies the family of rights that will be
 608              get/set for the control or extended operation performed.
 609              A rights family has a defined set of rights.
 610
 611              rightsList in the SearchResultEntry is of the form
 612              specified in the LDIF BNF for <right>.
 613
 614              dnType speficies the type of subject security attribute.
 615              Defined types are access-id, group, and role.
 616
 617              subjectDN is a LDAP string that defines the subject or
 618              value of the dnType.  The subjectDN may be a DN or
 619              another string such as IPAddress (dotted-decimal string
 620              representation) on which access control is get/set.  If
 621              the subject is an entry in the directory, then the syntax
 622              of the LDAP string is DN.  We define two well-known
 623              subjectDNs, the strings
 624
 625                 - public - meaning public access for all users
 626
 627                 - this - meaning the user whose name matches the entry
 628                   being accessed
 629
 630              Four operations are defined:
 631
 632                 - ACI_GRANT grants the rights specified in the
 633                   rightsList for the given subject. If an access
 634                   control list does not exist for the specified
 635                   entry/attribute, then the access control list is
 636
 637
 638
 639           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 11]
 640
 641
 642
 643
 644
 645
 646           Internet-Draft      Access Control Model        25 June 1999
 647
 648
 649
 650                   created with the granted rights for the given
 651                   subject.  If the access control list already exists
 652                   for the specified entry/attribute, then the access
 653                   control list is modified to grant the rights for the
 654                   given subject.
 655
 656                 - ACI_DENY denies the rights specified in the
 657                   rightsList for the given subject.  No implementation
 658                   is implied for this operation.  For example, denial
 659                   of rights may be implemented as explicit denial
 660                   (negative rights) on the access control list or
 661                   removal of rights from the access control list.
 662
 663                 - ACI_REPLACE replaces the entire access control list
 664                   for the specified entry/attribute.  If an access
 665                   control list does not exist for the specified
 666                   entry/attribute, then the access control list is
 667                   created with the granted rights for the given
 668                   subject.
 669
 670                 - ACI_DELETE deletes the entire access control list
 671                   for the specified entry/attribute.
 672
 673              attrs specifies the list of attributes against which the
 674              operation is performed.  attrs can be defined using a
 675              LDAP filter expression.
 676
 677
 678           7.  Access Control Information (ACI) Controls
 679
 680              The access control information controls provide a way to
 681              manipulate access control information in conjunction with
 682              an LDAP operation such as ldap_add, ldap_modify, or
 683              ldap_search.  Three LDAP controls are defined for
 684              transmission of access control information.  These
 685              controls allow access control information to be get/set
 686              while manipulating other directory information.  The
 687              controls are:
 688
 689                 - getEffectiveRights to obtain the effective rights
 690                   for a given directory entry(s) for a given subject
 691                   during a ldap_search operation
 692
 693                 - specifyCredentials to specify a set of credentials
 694                   for the bind identity (DN) during a ldap_bind
 695
 696
 697
 698           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 12]
 699
 700
 701
 702
 703
 704
 705           Internet-Draft      Access Control Model        25 June 1999
 706
 707
 708
 709                   operation
 710
 711           7.1  getEffectiveRights Control
 712
 713
 714           7.1.1  Request Control
 715
 716              This control is  included in  the ldap_search  message as
 717              part of the controls  field  of the  LDAPMessage, as
 718              defined in  Section  4.1.12 of [LDAPv3].
 719
 720              The controlType is set to <OID to be assigned>. The
 721              criticality MAY be either TRUE or FALSE (where absent is
 722              also equivalent to FALSE) at the client's option.  The
 723              controlValue is an OCTET STRING, whose value is the BER
 724              encoding of a value of the following SEQUENCE:
 725
 726               getEffectiveRightsRequest ::= SEQUENCE {
 727                    targetDN  LDAPDN,
 728                    effectiveRightsRequest   SEQUENCE OF SEQUENCE {
 729                                rightsFamily  LDAPOID | "*",
 730                                whichObject   ENUMERATED {
 731                                                LDAP_ENTRY (1),
 732                                                LDAP_SUBTREE (2)
 733                                                },
 734                                dnType        LDAPOID | "*",
 735                                subjectDN     LDAPString,
 736                                }
 737               }
 738
 739              The targetDN specifies the initial directory entry in DN
 740              syntax on which the getEffectiveRights control is
 741              performed.  request is a set of sequences that state the
 742              whichObject (entry or entry plus subtree) and specifics
 743              of the control request to be performed.  One or more
 744              rightsFamily can be be obtained for a given subjectDN ad
 745              dnType.  A "*" in the rightsFamily field indicates that
 746              the rights for all rights families defined for the
 747              subjectDN / dnType are to be returned.  This control is
 748              applied to the scope set by the ldap_search operation,
 749              i.e.  base, one-level, subtree.
 750
 751           7.1.2  Response Control
 752
 753              This control is included in the ldap_search_response
 754
 755
 756
 757           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 13]
 758
 759
 760
 761
 762
 763
 764           Internet-Draft      Access Control Model        25 June 1999
 765
 766
 767
 768              message as part of the controls field of the LDAPMessage,
 769              as defined in Section 4.1.12 of [LDAPv3].
 770
 771              The controlType is set to <OID to be assigned>. The
 772              criticality MAY be either TRUE or FALSE (where absent is
 773              also equivalent to FALSE).  The controlValue is an OCTET
 774              STRING, whose value is the BER encoding of a value of the
 775              following SEQUENCE:
 776
 777               getEffectiveRightsResponse ::= {
 778                 result  ENUMERATED {
 779                    success                       (0),
 780                    operationsError               (1),
 781                    unavailableCriticalExtension (12),
 782                    noSuchAttribute              (16),
 783                    undefinedAttributeType       (17),
 784                    invalidAttributeSyntax       (21),
 785                    unavailable                  (52),
 786                    unwillingToPerform           (53),
 787                    other                        (80)
 788                    }
 789               }
 790
 791              The effective rights returned are returned with each
 792              entry returned by the search result.  The control
 793              response for ldap_search is:
 794
 795               PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE {
 796                  rightFamily   LDAPOID,
 797                  rightsList    ENUMERATED,
 798                  whichObject   ENUMERATED {
 799                                    LDAP_ENTRY (1),
 800                                    LDAP_SUBTREE (2)
 801                                    }
 802               }
 803
 804              Although this extends the search operation, there are no
 805              incompatibilities between versions.  LDAPv2 cannot send a
 806              control, hence the above structure cannot be returned to
 807              a LDAPv2 client.  A LDAPv3 client cannot send this
 808              request to a LDAPv2 server.  A LDAPv3 server not
 809              supporting this control cannot return the additional
 810              data.
 811
 812
 813
 814
 815
 816           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 14]
 817
 818
 819
 820
 821
 822
 823           Internet-Draft      Access Control Model        25 June 1999
 824
 825
 826
 827           7.1.3  Client-Server Interaction
 828
 829              The getEffectiveRightsRequest control requests the rights
 830              that MUST be in effect for requested directory
 831              entry/attribute based on the subject DN.  The server that
 832              consumes the search operation looks up the rights for the
 833              returned directory information based on the subject DN
 834              and returns that rights information.
 835
 836              There are six possible scenarios that may occur as a
 837              result of the getEffectiveRights control being included
 838              on the search request:
 839
 840
 841                1.  If the server does not support this control and the
 842                    client specified TRUE for the control's criticality
 843                    field, then the server MUST return
 844                    unavailableCriticalExtension as a return code in
 845                    the searchResponse message and not send back any
 846                    other results.  This behavior is specified in
 847                    section 4.1.12 of [LDAPv3].
 848
 849                2.  If the server does not support this control and the
 850                    client specified FALSE for the control's
 851                    criticality field, then the server MUST ignore the
 852                    control and process the request as if it were not
 853                    present.  This behavior is specified in section
 854                    4.1.12 of [LDAPv3].
 855
 856                3.  If the server supports this control but for some
 857                    reason such as cannot process specified
 858                    rightsFamily and the client specified TRUE for the
 859                    control's criticality field, then the server SHOULD
 860                    do the following: return
 861                    unavailableCriticalExtension as a return code in
 862                    the searchResult message.
 863
 864                4.  If the server supports this control but for some
 865                    reason such as cannot process specified
 866                    rightsFamily and the client specified FALSE for the
 867                    control's criticality field, then the server should
 868                    process as 'no rights returned for that family' and
 869                    include the result Unavailable in the
 870                    getEffectiveRightsResponse control in the
 871                    searchResult message.
 872
 873
 874
 875           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 15]
 876
 877
 878
 879
 880
 881
 882           Internet-Draft      Access Control Model        25 June 1999
 883
 884
 885
 886                5.  If the server supports this control and can return
 887                    the rights per the rightsFamily information, then
 888                    it should include the getEffectiveRightsResponse
 889                    control in the searchResult message with a result
 890                    of success.
 891
 892                6.  If the search request failed for any other reason,
 893                    then the server SHOULD omit the
 894                    getEffectiveRightsResponse control from the
 895                    searchResult message.
 896
 897              The client application is assured that the correct rights
 898              are returned for scope of the search operation if and
 899              only if the getEffectiveRightsResponse control returns
 900              the rights.  If the server omits the
 901              getEffectiveRightsResponse control from the searchResult
 902              message, the client SHOULD assume that the control was
 903              ignored by the server.
 904
 905              The getEffectiveRightsResponse control, if included by
 906              the server in the searchResponse message, should have the
 907              getEffectiveRightsResult set to either success if the
 908              rights are returned or set to the appropriate error code
 909              as to why the rights could not be returned.
 910
 911              The server may not be able to return a right because it
 912              may not exist in that directory object's attribute; in
 913              this case, the rights request is ignored with success.
 914
 915           7.2  specifyCredentials Control
 916
 917
 918           7.2.1  Request Control
 919
 920              This control is included in  the ldap_bind  message as
 921              part of the controls  field  of the  LDAPMessage, as
 922              defined in  Section  4.1.12 of [LDAPv3].
 923
 924              The controlType is set to <OID to be assigned>. The
 925              criticality MAY be either TRUE or FALSE (where absent is
 926              also equivalent to FALSE) at the client's option.  The
 927              controlValue is an OCTET STRING, whose value is the BER
 928              encoding of a value of the following SEQUENCE:
 929
 930               specifyCredentialRequest ::= SEQUENCE {
 931
 932
 933
 934           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 16]
 935
 936
 937
 938
 939
 940
 941           Internet-Draft      Access Control Model        25 June 1999
 942
 943
 944
 945                    credential  LDAPString
 946                                }
 947               }
 948
 949              The credential specifies the credential (e.g. groups,
 950              roles, etc) that the client is requesting be associated
 951              with the bind DN for access control determination in
 952              subsequent ldap operations.  This provides a 'push' model
 953              for credentials where the client attempts to 'push' the
 954              credential to the server.  The server may process at bind
 955              time as follows:
 956
 957                 - server may unconditionally ignore
 958
 959                 - server may unconditionally accept
 960
 961                 - server may define trust model and evaluate of the
 962                   trust of each credential
 963
 964              If this control is not used, it is assumed that the
 965              server determines (pulls) the credentials associated with
 966              the bind DN when needed in subsequent ldap operations to
 967              provide access control.
 968
 969           7.2.2  Response Control
 970
 971              This control is included in the ldap_bind message as part
 972              of the controls field of the LDAPMessage, as defined in
 973              Section 4.1.12 of [LDAPv3].
 974
 975              The controlType is set to <OID to be assigned>. The
 976              criticality MAY be either TRUE or FALSE (where absent is
 977              also equivalent to FALSE).  The controlValue is an OCTET
 978              STRING, whose value is the BER encoding of a value of the
 979              following SEQUENCE:
 980
 981               specifyCredentialsResponse ::= {
 982                 result  ENUMERATED {
 983                    success                       (0),
 984                    operationsError               (1),
 985                    unavailableCriticalExtension (12),
 986                    unavailable                  (52),
 987                    unwillingToPerform           (53),
 988                    other                        (80)
 989                    }
 990
 991
 992
 993           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 17]
 994
 995
 996
 997
 998
 999
1000           Internet-Draft      Access Control Model        25 June 1999
1001
1002
1003
1004               }
1005
1006              No data is returned; just the result is returned.
1007
1008              Although this extends the bind operation, there are no
1009              incompatibilities between versions.  LDAPv2 cannot send a
1010              control.  A LDAPv3 client cannot send this request to a
1011              LDAPv2 server.  A LDAPv3 server not supporting this
1012              control cannot return the additional data.
1013
1014           7.2.3  Client-Server Interaction
1015
1016              The specifyCredentialsRequest control specifies the
1017              credentials that the client wants the server to use for
1018              access control in subsequent ldap operations.  The server
1019              that consumes the bind operation may unconditionally
1020              accept, ignore, or evaluate the trust of the specified
1021              credentials at bind time and returns only a success or
1022              failure response (no data returned).
1023
1024              There are six possible scenarios that may occur as a
1025              result of the specifyCredential control being included on
1026              the bind request:
1027
1028
1029                1.  If the server does not support this control and the
1030                    client specified TRUE for the control's criticality
1031                    field, then the server MUST return
1032                    unavailableCriticalExtension as a return code in
1033                    the bindResponse message.  This behavior is
1034                    specified in section 4.1.12 of [LDAPv3].
1035
1036                2.  If the server does not support this control and the
1037                    client specified FALSE for the control's
1038                    criticality field, then the server MUST ignore the
1039                    control and process the request as if it were not
1040                    present.  This behavior is specified in section
1041                    4.1.12 of [LDAPv3].
1042
1043                3.  If the server supports this control but for some
1044                    reason such as cannot process specified credential
1045                    (e.g. server decided to evaluate the trust of that
1046                    credential and the result is the server not
1047                    trusting all the credentials or unconditionally
1048                    ignores the credential) and the client specified
1049
1050
1051
1052           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 18]
1053
1054
1055
1056
1057
1058
1059           Internet-Draft      Access Control Model        25 June 1999
1060
1061
1062
1063                    TRUE for the control's criticality field, then the
1064                    server SHOULD do the following: return
1065                    unavailableCriticalExtension as a return code in
1066                    the bindResult message and omit the
1067                    specifyCredentialResponse control in the bindResult
1068                    message.
1069
1070                4.  If the server supports this control but for some
1071                    reason such as cannot process specified credential
1072                    (e.g. server decided to evaluate the trust of that
1073                    credential and the result is the server not
1074                    trusting all the credentials or unconditionally
1075                    ignores the credential) and the client specified
1076                    FALSE for the control's criticality field, then the
1077                    server should process as 'credential ignored' and
1078                    include the result Unavailable in the
1079                    specifyCredentialResponse control in the bindResult
1080                    message.
1081
1082                5.  If the server supports this control and evaulates
1083                    the trust of that credential and the result is the
1084                    server trusting all the credentials, then it should
1085                    include the specifyCredentialResponse control in
1086                    the bindResult message with a result of success.
1087
1088                6.  If the bind request failed for any other reason,
1089                    then the server SHOULD omit the
1090                    specifyCredentialResponse control from the
1091                    bindResult message.
1092
1093              The client application is assured that the correct
1094              credentials are used by the server when specified by the
1095              client for subsequent ldap operations if and only if the
1096              specifyCredentialResponse is successful.  If the server
1097              omits the specifyCredentialResponse control from the
1098              bindResponse message, the client SHOULD assume that the
1099              control was ignored by the server.
1100
1101              The specifyCredentialResponse control, if included by the
1102              server in the bindResponse message, should have the
1103              bindResult set to either success if the credentials were
1104              accepted by the server or set to the appropriate error
1105              code as to why the credentials were not accepted.
1106
1107
1108
1109
1110
1111           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 19]
1112
1113
1114
1115
1116
1117
1118           Internet-Draft      Access Control Model        25 June 1999
1119
1120
1121
1122           8.  Access Control Extended Operations
1123
1124              Two extended operations (analogous to the controls) are
1125              defined for transmission of access control information.
1126              These operations help with the management of access
1127              control information independent of manipulating other
1128              directory information.  The extended operations are:
1129
1130                 - LDAP Get Effective Rights to obtain the effective
1131                   rights for a given directory entry for a given
1132                   subject
1133
1134           8.1  LDAP Get Effective Rights Operation
1135
1136              ldapGetEffectiveRightsRequest ::= [APPLICATION 23]
1137              SEQUENCE {
1138                 requestName      [0] <OID to be assigned>,
1139                 requestValue     [1] OCTET STRING OPTIONAL }
1140
1141                 where
1142
1143                 requestValue ::= SEQUENCE {
1144                    targetDN  LDAPDN,
1145                    updates   SEQUENCE OF SEQUENCE {
1146                                rightsFamily  LDAPOID | "*",
1147                                whichObject   ENUMERATED {
1148                                                LDAP_ENTRY (1),
1149                                                LDAP_SUBTREE (2)
1150                                                },
1151                                dnType        LDAPOID | "*",
1152                                subjectDN     LDAPString,
1153                                }
1154                    }
1155
1156
1157              The requestName is a dotted-decimal representation of the
1158              OBJECT IDENTIFIER corresponding to the request. The
1159              requestValue is information in a form defined by that
1160              request, encapsulated inside an OCTET STRING.
1161
1162              The server will respond to this with an LDAPMessage
1163              containing the ExtendedResponse which is a rights list.
1164
1165              ldpGetEffectiveRightsResponse ::= [APPLICATION 24]
1166              SEQUENCE {
1167
1168
1169
1170           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 20]
1171
1172
1173
1174
1175
1176
1177           Internet-Draft      Access Control Model        25 June 1999
1178
1179
1180
1181                 COMPONENTS OF LDAPResult,
1182                 responseName     [10] <OID to be assigned> OPTIONAL,
1183                 effectiveRights  [11] OCTET STRING OPTIONAL }
1184
1185                 where
1186
1187                 effectiveRights ::= SEQUENCE OF SEQUENCE {
1188                    rightFamily   LDAPOID,
1189                    rightsList    ENUMERATED,
1190                    whichObject   ENUMERATED {
1191                                     LDAP_ENTRY (1),
1192                                     LDAP_SUBTREE (2)
1193                                     },
1194                    subjectDnType LDAPOID,
1195                    subjectDN     LDAPSTRING
1196                 }
1197
1198              If the server does not recognize the request name, it
1199              MUST return only the response fields from LDAPResult,
1200              containing the protocolError result code.
1201
1202
1203
1204           9.  Access Control Information Attributes/LDIF
1205
1206           The intent of the following attribute definitions is to
1207           design a common interchange format.  Any given LDAP server
1208           should be able to translate the below defined attributes
1209           into a meaningful operation requests. Each server should be
1210           able to understand the attributes; there should not be any
1211           ambiguity into what any part of the syntax means.
1212
1213           While the end goal is to have a common behavior model
1214           between different LDAP server implementations, the attribute
1215           definition alone will not ensure identical ACL processing
1216           behavior between servers.  The semantics of how a server
1217           interprets the ACI syntax are not defined here. What 'deny'
1218           means on server1 might be different than on server2.
1219           Additionally, while the server must recognize and act on the
1220           attribute when received over the wire, there are no
1221           requirements for the server to actually implement this
1222           attribute.
1223
1224           The attribute definition maintains an assumption that the
1225           receiving server supports inheritance within the security
1226
1227
1228
1229           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 21]
1230
1231
1232
1233
1234
1235
1236           Internet-Draft      Access Control Model        25 June 1999
1237
1238
1239
1240           model. If the server does not support inheritance, the
1241           receiving server must expand any inherited information based
1242           on the scope flag.
1243
1244
1245           9.1  ACI Attributes
1246
1247           There are three attributes which may be queried or set on
1248           all directory objects:  aci, vendorAci and policyOwner. The
1249           syntax of these attributes is defined below.
1250
1251
1252           9.1.1  The BNF
1253
1254           < aci > ::= < acl syntax >
1255
1256           < vendorAci > ::= <oid> + '#' + < printable string >
1257
1258           < acl syntax > ::= <familyOID> + '#' + <scope > + '#'
1259                              + < rights >  + '#' + < dnType >
1260                              + '#' + < subjectDn >
1261
1262           < policyOwner > ::= < familyOid > + '#' + <scope >
1263                              + '#' +< dnType > + '#' + < subjectDn >
1264
1265           < subjectDn > ::= < printable string >
1266
1267           < familyOid > ::= < oid >
1268
1269           <scope > ::= "entry"  | "subtree" | <level>
1270
1271           < level > ::= numericstring
1272
1273           < dnType > ::= "access-id" | "role" | "group"
1274
1275           < rights > ::= [  ]   |   [ < right > + [ '$'
1276                          + <right> ] * ]
1277
1278           < right > ::= <action > + ';' + <permissions>
1279                         + ';' +  <attrs>
1280
1281           < action > ::= "grant" | "deny"
1282
1283           < permissions > ::= [  ]  |   [ < permission >
1284                               + [ ',' + <permission> ] *  ]
1285
1286
1287
1288           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 22]
1289
1290
1291
1292
1293
1294
1295           Internet-Draft      Access Control Model        25 June 1999
1296
1297
1298
1299           < attrs > ::= [ < attributeString>
1300                          + [ ',' + < attributeString > ] * ]
1301
1302           < attributeString > ::= "[all]" | "[entry]"
1303                                   | <printableString >
1304
1305           < permission > ::= "a" | "d" | "r" | "s" | "w" |
1306                              "c" | "g" | "s" | "m" | "u" | "e"
1307
1308           These are the permissions defined for the IETF family OID.
1309                "a" corresponds to add
1310                "d" corresponds to delete
1311                "r" corresponds to read
1312                "w" corresponds to write
1313                "c" corresponds to compare
1314                "g" corresponds to get
1315                "s" corresponds to set
1316                "m" corresponds to manage
1317                "u" corresponds to use
1318                "e" corresponds to editDn
1319
1320
1321           9.1.2  VendorACI
1322
1323           ( vendorAciOID NAME 'vendorACI'  DESC  'Vendor specific
1324           Access control information' EQUALITY caseIgnoreMatch SYNTAX
1325           directoryString )
1326
1327           The Vendor specific ACI information is listed in its own
1328           attribute.  This may be used by vendors to provide vendor
1329           specific access control related information which can not be
1330           expressed in defined ACISyntax. Within the vendorACI, the
1331           oid determines the format or the printable string to follow.
1332
1333
1334           9.1.3  Policy Owner
1335
1336           ( policySyntaxOID  DESC  'PolicyOwner Syntax' ) (
1337           policyOwnerOID NAME 'policyOwner' DESC  'Policy Owner Access
1338           Control Information' EQUALITY caseIgnoreMatch SYNTAX
1339           policySyntaxOID )
1340
1341           Policy ownership controls administrative subdomains. It can
1342           also control who has permission to set / change acls for
1343           implementations that do not have ACI controlling access to
1344
1345
1346
1347           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 23]
1348
1349
1350
1351
1352
1353
1354           Internet-Draft      Access Control Model        25 June 1999
1355
1356
1357
1358           itself.   If there are multiple policy owners it is
1359           implementation specific as to the behavior of whether policy
1360           owner #1 can override policy owner # 2.
1361
1362           The syntax for policyOwner includes the 'scope' flag.
1363           Servers which do not support inheritance must expand the
1364           policyOwner inheritance similar to the expansion of the ACI.
1365           The scope and any inheritance hierarchy for policy ownership
1366           is distinct from any inheritance hierarchy defined for ACI
1367           values.
1368
1369           If the policy owner is not specified for any object in the
1370           tree, behavior is implementation defined. For instance, if
1371           no object anywhere in the tree has a policy owner, then the
1372           server could simply assert that the 'root DN' is considered
1373           the policy owner for all objects. An alternate approach
1374           might be that the implementation defines the entryDN to be
1375           the policy owner.
1376
1377
1378           9.1.4  ACI
1379
1380           ( aciSyntaxOID  DESC  'ACI Syntax' )
1381            ( aciOID NAME 'aci' DESC  'Access control information'
1382           EQUALITY caseIgnoreMatch SYNTAX  aciSyntaxOID  )
1383
1384           Within the access control syntax, the family OID describes
1385           the permissions, dnType, subjectDn and scope  that will be
1386           found in the following string. If the OID within the ACI
1387           attribute is listed as other than the IETF family oid, the
1388           syntax is the same as listed below, but one or more of the
1389           scope, dnType, subjectDn or permissions may vary from the
1390           IETF defined syntax.
1391
1392           Within the access control syntax, there is a string which
1393           describes the rights. This is a composite of the permissions
1394           and resources to which the user is being granted or denied
1395           access. The set of permissions is fixed. Either of the
1396           actions "grant" | "deny"  may be used when creating or
1397           updating ACI.
1398
1399           The attributeString is an attribute Name (defined to be a
1400           printable string).  If the string refers to an attribute not
1401           defined in the given server's schema, the server SHOULD
1402           report an error.   Another option for the attributeString is
1403
1404
1405
1406           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 24]
1407
1408
1409
1410
1411
1412
1413           Internet-Draft      Access Control Model        25 June 1999
1414
1415
1416
1417           "[entry]". This is provided to describe permissions which
1418           apply to an entire object. This could mean actions such as
1419           delete the object, or add a child object. The third option
1420           for attributeString is "[all]" which means the permission
1421           set should apply to all attributes.
1422
1423           If the keyword "[all]" and another attribute are both
1424           specified within an aci, the more specific permission set
1425           for the attribute overrides the less specific permission set
1426           for "[all]".
1427
1428           If two ACIs contain identical familyOID, scope, DnTypes and
1429           DNs, the permission given DN is specified in two distinct
1430           acis on any given entry, the rights lists can be combined
1431           into one list. For example,
1432
1433            aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
1434            aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ
1435
1436           is the equivalent of
1437
1438            aci: 1.2.3.4#subtree#grant;r,w;[all];
1439                  r,attribute1#group#cn=Dept XYZ
1440
1441           Using the defined BNF it is possible for the permission
1442           string to be empty. The ACI
1443
1444            aci: 1.2.3.4#subtree#grant;;attribute1$grant;r,s;
1445                  [all]#group#cn=Dept XYZ,c=US
1446
1447           means that this group is granted permission to read and
1448           search all attributes except attribute1.
1449
1450           Similarly, the ACI
1451
1452           aci: 1.2.3.4#subtree##group#cn=Dept XYZ, c=US
1453
1454           simply means that no permissions have been defined for this
1455           group. It is up to the server implementation as to whether
1456           the group does or does not receive permission to attributes
1457           on an entry with an empty rights list.
1458
1459           Multiple attributeStrings can be listed after any given
1460           permission set; for instance, "r,w ; attribute1,
1461           attribute2". This means that if the server supports a
1462
1463
1464
1465           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 25]
1466
1467
1468
1469
1470
1471
1472           Internet-Draft      Access Control Model        25 June 1999
1473
1474
1475
1476           attribute aggregation mechanism, attribute1 and attribute2
1477           should be considered to be part of the same group. If the
1478           server does not support a grouping mechanism, the permission
1479           set applies independently to attribute1 and attribute2. For
1480           servers that do not support attribute grouping, "grant ; r,w
1481           ; attribute1, attribute2" results in the same operations as
1482           "grant ; r,w; attribute1$grant; r,w; attribute2"
1483
1484
1485           9.1.5  LDAP Operations
1486
1487           The attributes which are defined for access control
1488           interchange may be used in all LDAP operations.
1489
1490           Within the ldapmodify-delete operation, the entire acl may
1491           be deleted by specifying
1492
1493            dn: cn = some Entry
1494            changetype: modify
1495            delete: aci
1496
1497           In this case, the entry would then inherit its ACI from some
1498           other node in the tree depending on the server inheritance
1499           model.
1500
1501           Deleting the last ACI value from an entry is not the same as
1502           deleting the ACI from the entry. It is possible for an entry
1503           to contain an ACI with no values. In this case, nothing is
1504           returned to the client when querying the aci. It is server
1505           dependent whether access is granted or denied in the absence
1506           of any ACI information.  Deleting an ACI value which does
1507           not exist will result in an unchanged ACI and a return code
1508           specifying that the attribute value does not exist.
1509
1510
1511           9.2  Examples
1512
1513
1514           9.2.1  Attribute Definition
1515
1516              Pretend IETFFamilyOID = 1.2.3.4
1517
1518              The following two examples show an administrative
1519              subdomain being established. The first example shows a
1520              single user being assigned the policyOwner for the entire
1521
1522
1523
1524           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 26]
1525
1526
1527
1528
1529
1530
1531           Internet-Draft      Access Control Model        25 June 1999
1532
1533
1534
1535              domain. The second example shows a group of ids assigned
1536              to the policy Owner.
1537
1538              policyOwner: 1.2.3.4#subtree#access-id#cn=Hoyt
1539
1540              policyOwner: 1.2.3.4#subtree#group#cn=System Owners,
1541              o=Company
1542
1543              The next example shows an aci attribute where a group
1544              "cn=Dept XYZ, c=US" is being given permissions to read,
1545              search and compare attribute1. The permission should
1546              apply to the entire subtree below the node containing
1547              this ACI.
1548
1549               aci:1.2.3.4#subtree#grant;r,s,c;
1550                    attribute1#group#cn=Dept XYZ,c=US
1551
1552              The next example shows an ACI attribute where a role
1553              "cn=SysAdmins,o=Company"  is being given permissions to
1554              add objects below this node, and read, search and compare
1555              attributes 2 and 3. The permission should apply to the
1556              entire subtree below the node containing this ACI.
1557
1558                aci: 1.2.3.4#subtree#grant;a;[entry]$grant;
1559                     r,s,c;attribute2, attribute3#role#
1560                     cn=SysAdmins,o=Company
1561
1562
1563           9.2.2  Modifying the ACI Values
1564
1565           Replace works similarly to all other attributes. If the
1566           attribute value does not exist, create the value. If the
1567           attribute does exist, replace the value.  If the ACI value
1568           is replaced, all ACI values are replaced.
1569
1570           A given aci for an entry:
1571
1572            aci: 1.2.3.4#subtree#deny;r,w;[all]$grant;r,s,c;
1573                 attribute2#group#cn=Dept ABC
1574
1575            aci: 1.2.3.4#subtree#grant;r;[all]$grant;r,s,c;
1576                 attribute1#group#cn=Dept XYZ
1577
1578           perform the following change:
1579
1580
1581
1582
1583           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 27]
1584
1585
1586
1587
1588
1589
1590           Internet-Draft      Access Control Model        25 June 1999
1591
1592
1593
1594             dn: cn=someEntry
1595             changetype: modify
1596             replace: aci
1597             aci: 1.2.3.4#subtree#grant;r,w;[all];#group#cn=Dept LMN
1598
1599           The resulting acl is:
1600
1601           aci: 1.2.3.4#subtree#grant;r,w;[all];#group#cn=Dept LMN
1602
1603           ( aci values for Dept XYZ and ABC are lost through the
1604           replace )
1605
1606           During an ldapmodify-add, if the ACI does not exist, the
1607           create the ACI with the specific aci value(s).  If the ACI
1608           does exist, then add the specified values to the given ACI.
1609           For example a given ACI:
1610
1611           aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
1612
1613           with a modification:
1614
1615             dn: cn=someEntry
1616             changetype: modify
1617             add: aci
1618             aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ
1619
1620           would yield an multi-valued aci of:
1621
1622             aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
1623             aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ
1624           To delete a particular aci value, use the regular ldapmodify
1625           - delete syntax
1626
1627           Given an ACI of:
1628
1629             aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
1630             aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ
1631
1632             dn: cn = some Entry
1633             changetype: modify
1634             delete: aci
1635             aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ
1636
1637           would yield a remaining ACI on the server of
1638
1639
1640
1641
1642           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 28]
1643
1644
1645
1646
1647
1648
1649           Internet-Draft      Access Control Model        25 June 1999
1650
1651
1652
1653           aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
1654
1655
1656
1657           10.  Security Considerations
1658
1659              This draft proposes protocol elements for transmission of
1660              security policy information.  Security considerations are
1661              discussed throughout this draft.  Because subject
1662              security attribute information is used to evaluate
1663              decision requests, it is security-sensitive information
1664              and must be protected against unauthorized modification
1665              whenever it is stored or transmitted.
1666
1667
1668
1669           11.  References
1670
1671              [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight
1672              Directory Access Protocol (v3)", RFC 2251, December 1997.
1673
1674              [ECMA] ECMA, "Security in Open Systems: A Security
1675              Framework" ECMA TR/46, July 1988
1676
1677              [REQTS] Stokes, Byrne, Blakley, "Access Control
1678              Requirements for LDAP, INTERNET-DRAFT <draft-ietf-
1679              ldapext-acl-reqts-01.txt>, August 1998.
1680
1681              [ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille,
1682              "Lightweight Directory Access Protocol (v3)": Attribute
1683              Syntax Definitions, RFC 2252, December 1997.
1684
1685              [UTF] M. Wahl, S. Kille, "Lightweight Directory Access
1686              Protocol (v3)": A UTF-8 String Representation of
1687              Distinguished Names", RFC 2253, December 1997.
1688
1689              [Bradner97] Bradner, Scott, "Key Words for use in RFCs to
1690              Indicate Requirement Levels", RFC 2119.
1691
1692
1693           AUTHOR(S) ADDRESS
1694
1695               Ellen Stokes                       Bob Blakley
1696               IBM                                Dascom
1697               11400 Burnet Rd                    5515 Balcones Drive
1698
1699
1700
1701           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 29]
1702
1703
1704
1705
1706
1707
1708           Internet-Draft      Access Control Model        25 June 1999
1709
1710
1711
1712               Austin, TX 78758                   Austin, TX 78731
1713               USA                                USA
1714               mail-to: stokes@austin.ibm.com     mail-to: blakley@dascom.com
1715               phone: +1 512 838 3725             phone: +1 512 458 4037  ext 5012
1716               fax:   +1 512 838 8597             fax:   +1 512 458 237
1717
1718
1719               Debbie Byrne
1720               IBM
1721               11400 Burnet Rd
1722               Austin, TX 78758
1723               USA
1724               mail-to: djbyrne@us.ibm.com
1725               phone: +1 512 838 1960
1726               fax:   +1 512 838 8597
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 30]
1761
1762
1763
1764
1765
1766
1767           Internet-Draft      Access Control Model        25 June 1999
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819           Stokes, Byrne, Blakley   Expires 25 December 1999        [Page 31]
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830                                     CONTENTS
1831
1832
1833            1.  Introduction.......................................   2
1834
1835            2.  Overview...........................................   2
1836
1837            3.  Terminology........................................   4
1838
1839            4.  The Model..........................................   6
1840                4.1  Access Control Activity Lifecycle.............   6
1841                4.2  Access Control Information Model..............   6
1842                4.3  Bind and Credentials..........................   8
1843
1844            5.  Access Control Information Schema..................   8
1845                5.1  Attributes....................................   8
1846                     5.1.1  Root DSE Attribute for Access Control
1847                            Mechanism   8
1848                     5.1.2  Subschema Attribute for Access Control
1849                            Mechanism   9
1850                5.2  Other Defined Parameters/OIDs.................   9
1851                     5.2.1  Rights Families and Rights   9
1852                     5.2.2  DN Types  10
1853
1854            6.  Access Control Parameters for LDAP Controls &
1855                Extended Operations................................  11
1856
1857            7.  Access Control Information (ACI) Controls..........  12
1858                7.1  getEffectiveRights Control....................  13
1859                     7.1.1  Request Control  13
1860                     7.1.2  Response Control  13
1861                     7.1.3  Client-Server Interaction  15
1862                7.2  specifyCredentials Control....................  16
1863                     7.2.1  Request Control  16
1864                     7.2.2  Response Control  17
1865                     7.2.3  Client-Server Interaction  18
1866
1867            8.  Access Control Extended Operations.................  20
1868                8.1  LDAP Get Effective Rights Operation...........  20
1869
1870           10.  Security Considerations............................  29
1871
1872           11.  References.........................................  29
1873
1874
1875
1876
1877
1878                                      - i -
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890           Full Copyright Statement
1891
1892           Copyright (C) The Internet Society (1999).á All Rights
1893           Reserved.
1894
1895           This document and translations of it may be copied and
1896           furnished to others, and derivative works that comment on or
1897           otherwise explain it or assist in its implementation may be
1898           prepared, copied, published and distributed, in whole or in
1899           part, without restriction of any kind, provided that the
1900           above copyright notice and this paragraph are included on
1901           all such copies and derivative works.á However, this
1902           document itself may not be modified in any way, such as by
1903           removing the copyright notice or references to the Internet
1904           Society or other Internet organizations, except as needed
1905           for the purpose of developing Internet standards in which
1906           case the procedures for copyrights defined in the Internet
1907           Standards process must be followed, or as required to
1908           translate it into languages other than English.
1909
1910           The limited permissions granted above are perpetual and will
1911           not be revoked by the Internet Society or its successors or
1912           assigns.
1913
1914           This document and the information contained herein is
1915           provided on an "AS IS" basis and THE INTERNET SOCIETY AND
1916           THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
1917           WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
1918           ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
1919           INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1920           MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938                                      - ii -
1939
1940
1941
1942