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