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

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