idnits 2.17.1 draft-ietf-ldapext-acl-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 122 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 5 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([ATTR], [REQTS], [APPLICATION23], [Bradner97], [APPLICATION24], [LDAPv3], [ECMA], [10], [11], [0], [UTF], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 890: '... MUST ( definingAut...' RFC 2119 keyword, line 929: '... criticality MAY be either TRUE or...' RFC 2119 keyword, line 936: '...tyAttributeList OCTET STRING OPTIONAL...' RFC 2119 keyword, line 953: '... criticality MAY be either TRUE or...' RFC 2119 keyword, line 975: '... privileges that MUST be in effect for...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 924 has weird spacing: '...trol is inclu...' == Line 925 has weird spacing: '...ontrols field...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (27 March 1998) is 9527 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Bradner97' on line 1216 looks like a reference -- Missing reference section? 'LDAPv3' on line 1198 looks like a reference -- Missing reference section? 'APPLICATION 23' on line 1138 looks like a reference -- Missing reference section? '0' on line 1139 looks like a reference -- Missing reference section? '1' on line 1140 looks like a reference -- Missing reference section? 'APPLICATION 24' on line 1150 looks like a reference -- Missing reference section? '10' on line 1153 looks like a reference -- Missing reference section? '11' on line 1154 looks like a reference -- Missing reference section? 'ECMA' on line 1201 looks like a reference -- Missing reference section? 'REQTS' on line 1204 looks like a reference -- Missing reference section? 'ATTR' on line 1208 looks like a reference -- Missing reference section? 'UTF' on line 1212 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft B. Blakley 3 LDAP Extensions WG D. Byrne 4 Intended Category: Standards Track E. Stokes 5 Expires: 27 September 1998 IBM 6 27 March 1998 8 Access Control Model for LDAP 9 11 STATUS OF THIS MEMO 13 This document is an Internet Draft. Internet Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its Areas, and its Working Groups. Note that 16 other groups may also distribute working documents as 17 Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum 20 of six months. Internet Drafts may be updated, replaced, 21 or obsoleted by other documents at any time. It is not 22 appropriate to use Internet Drafts as reference material 23 or to cite them other than as a "working draft" or "work 24 in progress." 26 To view the entire list of current Internet-Drafts, please check 27 the "1id-abstracts.txt" listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 29 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 30 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 31 (US West Coast). 33 Comments and suggestions on this document are encouraged. 34 Comments on this document should be sent to the LDAPEXT 35 working group discussion list: 37 ietf-ldapext@netscape.com 39 ABSTRACT 41 This document describes the access control list (ACL) 42 model for the Lightweight Directory Application Protocol 43 (LDAP) directory service. It includes a description of 44 the model, the LDAP controls, and the extended operations 45 to the LDAP protocol. A separate document defines the 46 corresponding application programming interfaces (APIs). 47 RFC2219 [Bradner97] terminology is used. 49 1. Introduction 51 The ability to securely access (replicate and distribute) 52 directory information throughout the network is necessary 53 for successful deployment. LDAP's acceptance as an 54 access protocol for directory information is driving the 55 need to provide an access control model definition for 56 LDAP directory content among servers within an enterprise 57 and the Internet. Currently LDAP does not define an 58 access control model, but is needed to ensure consistent 59 secure access across heterogeneous LDAP implementations. 60 The major objective is to provide a simple, but secure, 61 highly efficient access control model for LDAP while also 62 providing the appropriate flexibility to meet the needs 63 of both the Internet and enterprise environments and 64 policies. This document defines the model and the 65 protocol extensions (controls and extended operations). 66 A separate document defines the corresponding application 67 programming interfaces (APIs). 69 2. Overview 71 Access Control mechanisms evaluate requests for access to 72 protected resources and make decisions about whether 73 those requests should be granted or denied. In order to 74 make a grant/deny decision about a request for access to 75 a protected resource, an access control mechanism needs 76 to evaluate policy data. This policy data describes 77 security-relevant characteristics of the requesting 78 subject and the rules which govern the use of the target 79 object. 81 This proposal defines directory attribute formats, 82 encodings, and protocol elements for storage and 83 transmission of this access control policy data in an 84 LDAP environment. 86 2.1 Access Control Activity Lifecycle 88 The access control proposal described in this draft 89 addresses four activities: 91 - Creation of subject security attribute information 92 and access control policy information 94 - Retrieval of subject security attribute information 95 at the time an access request is made 97 - Evaluation of access requests against policy, 98 resulting in an access decision 100 - Replication of access control policy information 101 from one server to another 103 2.2 Access Control Information Model 105 In support of the lifecycle activities described in the 106 previous section, This proposal defines two types of 107 access control information. 109 1. Subject Security Attribute Information (ssai) 111 Subject security attribute information enumerates 112 the security-relevant characteristics which entitle 113 subjects to rights in a system. 115 Subject security attribute information is 116 associated with subjects. Each subject must have 117 an LDAP directory entry, and a subject's security 118 attribute information is stored as attributes of 119 its directory entry. 121 2. Access Control Policy Information (acpi) 123 Access control policy information defines the rules 124 which govern access to objects in a system. 126 Access control policy information is associated 127 with objects. Objects are LDAP directory entries. 128 Access control policy information is stored in 129 attributes of the directory entries to which it 130 applies. 132 2.3 Access Control System Structure 134 The following diagram depicts the functional components 135 of the LDAP access control system, and illustrates the 136 use of access control information to implement the access 137 control lifecycle activities described above. 139 +---------+ 140 | admin | 141 | console | 142 +---------+ 143 | 144 1. set 145 privileges, 146 policy 147 (ssai, acpi) 148 | 149 +--------+ +--------------+ 150 | client | | LDAP | 151 | |- 5. access ->| server |- 9. replicate 152 +--------+ request +--------------+ (acpi, 153 ^ (ssai) | ^ | ssai) 154 | | | 7. check | 155 | | | access | 156 | | | (ssai) v 157 3. logon | | | +------+ 158 (ssai) 2. store | v | LDAP | 159 | privileges, | +--(adfi)--+ | srvr | 160 +--------+ policy | | access | +------+ 161 | auth'n | (ssai, acpi) | | decision | 162 | server | | | | function | 163 +--------+ | 6. get +----------+ 164 ^ | privs ^ 165 | | (ssai) | 166 | | | | 167 | | | 8. get 168 | | | policy 169 | | | (acpi) 170 | v | | 171 | +----------------+ 172 +-- 4. get -------| LDAP | 173 privileges | repository | 174 (ssai) +----------------+ 176 To enable the system to enforce access control, a 177 security administrator must assign security attributes to 178 the system's subjects and state the policy rules which 179 will govern access to the system's objects. The 180 administrator does this through the user interface of a 181 security administration tool, which then encodes the 182 resulting policy information and sends it to an LDAP 183 server for storage. 185 Sending subject security attribute information (ssai) 186 from the administrative console to the LDAP server 187 requires definition of an encoding and protocol elements 188 for ssai. 190 Sending access control policy information (acpi) from the 191 administrative console to the LDAP server requires 192 definition of an encoding and protocol elements for acpi. 193 (This is represented by the arrow labelled 1. in the 194 diagram). 196 The LDAP server must store the information it receives 197 from the administrator in the directory's data 198 respository. This requires definition of directory 199 schema elements for ssai and acpi. (This is represented 200 by the arrow labelled 2. in the diagram). 202 When a subject starts to use an LDAP directory, the 203 directory needs to determine what subject security 204 attributes that subject is entitled to. This will 205 normally involve authenticating the subject and returning 206 an authenticated credential, containing one or more 207 subject security attributes, to the LDAP client code. 208 The authentication service which validates the user's 209 logon needs to be able to retrieve ssai from the 210 directory, and create a credential which can be consumed 211 by the LDAP server or servers the subject needs to access 212 (This is represented by the arrows labelled 3. and 4. in 213 the diagram). 215 When a subject issues a request to access a directory 216 entry, the subject's LDAP client runtime needs to 217 transmit the subject's credential to the LDAP server so 218 that the server can use the subject security attribute 219 information in the credential as input to the access 220 decision it will have to make (This is represented by the 221 arrow labelled 5. in the diagram). 223 An LDAP server which receives a directory entry access 224 request may choose to retrieve additional subject 225 security attribute information (beyond that provided in 226 the credential the client sent with the request) from the 227 subject's directory entry. This might happen in two 228 cases: when the directory server being accessed does not 229 trust the authentication system which validated the 230 subject's logon to vouch for subject security attributes, 231 or when the directory server being accessed grants 232 subject security attributes in addition to those stored 233 in the directory server which authenticates subjects. 234 (This is represented by the arrow labelled 6. in the 235 diagram). 237 An LDAP server which receives a directory entry access 238 request needs to make an access decision to decide 239 whether to accept or reject the request. To do this, the 240 directory server needs to pass the subject's ssai, the 241 object's DN, and the operation being invoked to an access 242 decision function through an access decision function 243 interface (adfi). The access decision function needs to 244 retrieve the acpi for the specified object, and check to 245 see whether the required rights needed to invoke the 246 requested operation are in the granted rights of the acpi 247 entries matching security attributes in the subject's 248 ssai. In order to do this, it needs to retrieve the acpi 249 for the target object from the directory (This is 250 represented by the arrows labelled 7. and 8. in the 251 diagram). 253 When an LDAP server replicates data to another LDAP 254 server, it needs to replicate the security policy 255 attributes along with the other attributes of each 256 directory entry. This requires transferring both ssai 257 and acpi for each entry. (This is represented by the 258 arrow labelled 9. in the diagram). 260 2.4 Terminology 262 An "access control list" contains the access control 263 policy information controlling access to an object or 264 collection of objects. An access control list consists 265 of a set of access control list entries. No subject 266 security attribute appears in more than one access 267 control list entry in the same access control list. 269 An "access control list entry" defines a single subject 270 security attribute's granted rights for the objects 271 governed by the access control list to which it belongs. 273 The "access control policy information" (acpi) for an 274 object or a collection of objects defines which subject 275 security attributes entitle a subject to which granted 276 rights. The access control policy information for an 277 object is stored in an access control list. 279 An "access decision" is a boolean-valued function which 280 answers the question: "can the subject with these subject 281 security attributes perform this operation on this 282 object?" 284 An "access decision function" is an algorithm which makes 285 an access decision based on subject security attributes, 286 access control policy information, an object identifier, 287 and an operation name (possibly augmented by additional 288 contextual information). 290 An "access decision function interface" is a programmatic 291 interface through which applications can request an 292 access decision. 294 An "access identity" is an identity which is used by an 295 access decision function to make an access decision. 297 An "audit identity" is an identity which does not, in the 298 absence of additional information, enable a party 299 receiving and examining it to determine which subject it 300 belongs to. 302 A "credential" is a collection of subject security 303 attributes. 305 "effective rights" are the complete set of rights a 306 subject is entitled to based on all access control lists 307 which apply to a specific object and based on all of the 308 subject's security attributes. 310 "granted rights" are the complete set of rights an access 311 control list entitles a subject to based on a specific 312 subject security attribute. 314 A "group" is a privilege attribute asserting a subject's 315 membership in the collection of subjects whose name is 316 that of the group. 318 An "identity" is a subject security attribute which is 319 unique to a single subject. 321 An "object" is the target of operations in an information 322 system. 324 An "operation" is the result of executing the code 325 accessed through a named entry point in an information 326 system. 328 An "operation name" is the name of the entry point 329 through which an operation is invoked in an information 330 system. 332 A "privilege attribute" is a subject security attribute 333 which may be shared by several subjects. 335 "required rights" are the complete set of rights needed 336 to authorize a requester to perform a specific operation 337 on an object of a specific type. 339 A "right" is the basic unit of access control policy 340 administration. For each object type in an information 341 system, a security administrator defines a set of 342 required rights for each operation. For each object in 343 the system, a security administrator defines a set of 344 granted rights for each subject security attribute. When 345 an access decision is required, an access decision 346 function checks to make sure that the requester's subject 347 security attributes have been granted all required rights 348 needed to perform the requested operation on the 349 specified target object. 351 A "role" is a privilege attribute asserting a subject's 352 organizational position and entitlement to perform the 353 operations appropriate to that organizational position. 355 A "subject" is an entity which intiates actions in an 356 information system. 358 A "subject security attribute" is a defined property 359 which is used by a security policy evaluation system to 360 make policy decisions. 362 3. Subject Security Attribute Information 364 This section defines the data structures used to describe 365 subject security attribute information in support of LDAP 366 Access Control. 368 3.1 Terminology 370 A "security attribute" is a defined property which is 371 used by a security policy evaluation system to make 372 policy decisions. 374 A "subject" is an entity which intiates actions in an 375 information system. 377 A "subject security attribute" is a defined property of a 378 subject which is relevant to security. 380 3.2 Subject Security Attribute Properties 382 Subject security attributes need to have a variety of 383 properties: 385 - Defining Authority 387 Access control policies must sometimes 388 distinguish between security attributes which 389 share the same type-name but which have been 390 defined by different organizations and which 391 have different interpretations. for example, 392 the Israeli MOSSAD and the United States CIA 393 might both define an attribute type called 394 CLEARANCE. The US CIA might then define a 395 policy which says that subjects with 396 CLEARANCE="SECRET" may access information 397 classified as SECRET if their CLEARANCE 398 attribute was defined by the US CIA, but may 399 access only information classified as 400 CONFIDENTIAL if their CLEARANCE attribute was 401 defined by the Israeli MOSSAD. In order to 402 allow access control subsystems to distinguish 403 between attributes with the same type-name but 404 different defining authorities, the defining 405 authorities of security attribute types must be 406 explicitly identified. 408 - Type 410 There are many different kinds of subject 411 security attributes, including identities, 412 groups, roles, and clearances. The namespaces 413 (or identifier spaces) of different types of 414 security attributes are not always disjoint; 415 for example, a bank might have a ROLE attribute 416 with the value "TELLER" and an employee named 417 Edward Teller whose ACCESS_IDENTITY attribute 418 also has the value "TELLER". For this reason, 419 the types of security attributes must be 420 explicitly identified. 422 - Asserting Authority 424 When making access control decisions, it is 425 important for the access control subsystem to 426 know the identity of the authority which has 427 assigned an attribute to the requesting 428 subject. For example, an access control 429 subsystem will probably grant a request to 430 access IBM resources initiated by a subject 431 whose ROLE attribute has the value "CEO", 432 asserted by "IBM". On the other hand, the same 433 access control subsystem is unlikely to grant a 434 request initiated by a subject whose ROLE 435 attribute has the value "CEO", asserted by "JOE 436 SMITH". In order to allow access control 437 subsystems to determine whether they trust the 438 authority asserting security attribute values, 439 the asserting authorities of security attribute 440 values must be explicitly identified. 442 - Value 444 Each security attribute may take on a variety 445 of values; the set of legal values of a 446 security attribute is determined by its type 447 and its defining authority. 449 3.3 Examples of Subject Security Attributes 451 Examples of subject security attributes might include: 453 - Access identity (the unique name by which the 454 subject is known to the access control policy 455 evaluation subsystem of an information system). 456 Values might include "Bob Blakley" or "server357". 458 - Group membership (the name of a group to which the 459 subject belongs). Values might include "Task Force 460 Members", "Department UVZS", or "Dilbert Fans". 462 - Role membership (the name of a role which the 463 subject is entitled to assume for the purpose of 464 doing work in an information system). Values might 465 include "Vice President", "Teller", "Registered 466 Nurse", or "Primary Care Physician". 468 - Clearance (the name of a security clearance level). 469 Values might include "SECRET", "TOP SECRET", or 470 "UNCLASSIFIED". 472 3.4 Subject Security Attribute Information Structures 474 3.4.1 Credentials 476 Subject credentials are described by values for security 477 attributes, which are written in the 478 subjectSecurityAttributeList syntax. While lines have 479 been folded for readability, credential values 480 transferred in protocols and stored in repositories will 481 not contain newlines. 483 The subjectCredential is encoded according to the 484 following BNF; the productions for 485 are given in section 4.2. 487 ::= "(" 488 489 [ ] -- name used in 490 AttributeType 491 ")" 493 ::= INTEGER 495 The value of credentialVersion in credentials conforming 496 to this draft will be "1". 498 Note that no provision is made for identifying the 499 authority which issued and/or vouches for a 500 subjectCredential structure, or for allowing that 501 authority to sign the structure. It is viewed that this 502 will normally be provided by protocols incorporating the 503 subjectCredential structure. 505 3.4.2 Subject Security Attributes 507 A credential is a list of subject security attributes, 508 delimited by '$' characters. 510 ::= "(" 511 '$' 512 513 | 514 ")" 516 Subject security attributes describe security-relevant 517 attributes of subjects. As described in section 3.2, a 518 subject security attribute structure contains the 519 following: 521 - a defining authority 523 Defining authorities own subject security 524 attribute type namespaces. Each defining 525 authority defines a set of security attribute 526 types, each of which has a type-name which is 527 unique with respect to the defining authority. 529 - a type-name or privilege 531 Each security attribute has a type, named by a 532 printable string. The combination of a 533 defining authority and a type-name must 534 uniquely determine the type information which 535 will be used to interpret the value of the 536 subject security attribute. 538 - an asserting authority 540 An asserting authority assigns a value of the 541 appropriate type to a subject security 542 attribute. 544 - a value 546 Each subject security attribute has a value, of 547 the type named by 548 subjectSecurityAttributeTypeName, and asserted 549 by the authority named by 550 subjectSecurityAttributeValueAssertingAuthority. 551 Values are distinguished names. Values cannot 552 be interpreted without the type information 553 supplied by 554 subjectSecurityAttributeTypeDefiningAuthority 555 and subjectSecurityAttributeTypeName. 557 ::= "(" 558 '#' 559 '#' 560 '#' 561 562 ")" 564 ::= 566 ::= 568 ::= 569 571 ::= 573 3.4.3 Encoding 575 Encoding is that defined in RFC 2252. 577 3.4.4 Subject Security Attributes 579 Two types of subject security attributes are defined: 580 identities and privileges. The identities attribute 581 contains the identities associated with the subject 582 represented by the directory entry and may not have 583 corresponding directory entries. Examples are user and 584 audit_id. The privileges attribute contains the set of 585 privilege attributes associated with the subject 586 represented by the directory entry and will have 587 corresponding directory entries. Examples are group and 588 role. 590 4. Access Control Information 592 4.1 Composition of Access Control Information 594 Access to LDAP directory objects and attributes is 595 defined by Access Control Lists (ACLs). Each object in 596 the directory contains a special set of attribute:value 597 pairs that describe who is allowed to access information 598 within that object. There are two types of attributes, 599 Access Control List (ACL) information and Owner 600 information. 602 4.1.1 aclEntry Attribute 604 The aclEntry is a multi-valued attribute that contains 605 information pertaining to the access allowed to the entry 606 object and each of its attributes. An aclEntry lists the 607 following types of information: 609 - Who has rights to the entity object (scope of the 610 protection). 612 - What classes of attributes the user has access to 613 (attribute access classes). 615 - What rights the user or group has (permission). 617 4.1.2 aclOwner Attribute 619 Each object has an associated aclOwner attribute. The 620 aclOwner attribute might be a user or a group, similar to 621 what is allowed within the aclEntry. However, the 622 aclOwner subject has certain privileges over the object. 624 ACL owners are in essence the administrators for 625 particular objects. They have full access on that 626 particular object, similar to the administrator DN. 627 Notice that the administrator has full permission on any 628 object in the database. 630 ACL owners are not constrained by permissions given in 631 the aclEntry; they have complete access to any object 632 attribute. ACL owners (and the administrator) are the 633 only people who are allowed to change the access-related 634 attributes. 636 4.1.3 Attribute Classes 638 Attributes requiring similar permission for access are 639 grouped together in classes. The four standard attribute 640 classes are: 642 - 1 (Normal) 644 - 2 (Sensitive) 646 - 4 (Critical) 648 - 8 (Object) 650 The attribute classes 16, 32, 64, and 128 are reserved 651 for implementation defined classes which should not be 652 presumed to be interoperable. 654 Each of these attribute classes is discrete. Access to 655 information in one class does not give access to 656 information in any other class. The default attribute 657 class for an attribute is Normal. The Object attribute 658 class applies to the entire object instead of the 659 attributes within the object. 661 4.1.4 Access Permissions 663 Access permissions can apply to an entire object or to 664 attributes of the object. Each of the LDAP access 665 permissions are discrete. One permission does not imply 666 another permission. 668 Permissions that apply to an entire object (access class 669 = 8-object) are: 671 1 Add Add an object below this object 672 2 Delete Delete this object 674 Permissions which apply to attribute access classes (1- 675 normal, 2-sensitive, 4-critical) are: 677 4 Manage Perform a privileged operation; used to 678 restrict access to operations which 679 read or write especially sensitive data 680 8 Use Execute; useful in controlloing access to 681 the objects referred to by directory 682 entries than in controlling access to 683 the directory entries themselves 684 16 Read Read attribute values 685 32 Write Write attribute values 686 64 Search Search entries with specified attributes 687 128 Compare Compare attributes 689 The evaluation algorithm looks for an indentity first. 690 If the user's access id is in an ACL entry for the 691 object, that entry determines access. If the user's 692 access id is not in any ACL entry, the evaluation 693 algorithm finds all privilege attribute entries 694 applicable to the user and grants the user the union of 695 all the rights granted by those entries. 697 4.2 Default ACL 699 If no access control information is specified for a 700 directory, there is a default acl that will apply to the 701 entire directory. Notice that the default attribute 702 definitions include a default assignment of attributes to 703 access classes. 705 aclOwner: IETF#access-id#IETF#cn=admin,c=US 707 aclEntry: cn=IETF,c- 708 US#group#cn=IETF,c=US#cn=Everybody:: 710 The default ACL group contains everybody; it grants 711 permission to read, search, and compare all attributes 712 within the normal class. 714 4.3 Access Control Information Structures 716 ::= "(" 717 ")" 719 ::= "(" 720 "#" 721 [ "#" ] ")" 723 ::= 724 726 ::= "8:" 727 729 ::= | 731 ::= 1 733 ::= 2 735 ::= ":" 737 ::= | | 739 ::= 1 741 ::= 2 743 ::= 4 745 ::= 8 747 ::= | | | 748 | | 750 ::= 4 752 ::= 8 754 ::= 16 756 ::= 32 758 ::= 64 760 :::# 766 :#: 768 In this example, the user corresponding to access-id 769 "cn=personA, ou=deptXYZ, o=IBM, c=US" has permission to 770 add objects below this object, delete this object, read, 771 write, search, and compare both normal and sensitive 772 attributes, and to read, search and compare critical 773 attributes. 775 4.5 LDIF Syntax for Access Control Information 777 The LDIF syntax of the ACL attribute values is: 779 aclOwner ::= 781 aclEntry ::= '#' [obj- 782 granted-rights ] '#' + [class-granted-rights]* 784 obj-granted-rights ::= "8" + ':' + object-rights 786 class-granted-rights ::= "1" | "2" | "4" + ':' + class- 787 rights 789 object-rights ::= LISTOF 791 class-rights ::= LISTOF 793 * one or more 795 5. ACL Schema 797 5.1 Attributes 799 5.1.1 Identities Security Attribute 801 (1.3.18.0.2.4.101 802 NAME 'identities' 803 DESC identities associated with subject 804 represented by directory entry 805 EQUALITY subjectSecurityAttributeMatch 806 SUBSTR caseIgnoreSubstringMatch 807 SYNTAX 1.3.18.0.2.8.1 808 ) 810 5.1.2 Privileges Security Attribute 812 (1.3.18.0.2.4.108 813 NAME 'privileges' 814 DESC privileges associated with subject 815 represented by directory entry 816 EQUALITY subjectSecurityAttributeMatch 817 SUBSTR caseIgnoreSubstringMatch 818 SYNTAX 1.3.18.0.2.8.1 819 ) 821 5.1.3 Defining Authority 823 (1.3.18.0.2.4.102 824 NAME 'definingAuthority' 825 DESC Authority defining the privilege 826 attribute 827 EQUALITY distinguishedNameMatch 828 SUBSTR caseIgnoreSubstringMatch 829 SYNTAX DN 830 ) 832 5.1.4 Security Attribute Type 834 (1.3.18.0.2.4.103 835 NAME 'securityAttributeType' 836 DESC Type of attribute 837 EQUALITY caseIgnoreMatch 838 SUBSTR caseIgnoreSubstringMatch 839 SYNTAX printableString 840 ) 842 5.1.5 Asserting Authority 844 (1.3.18.0.2.4.104 845 NAME 'assertAuthority' 846 DESC Authority assigning value to privilege 847 attribute 848 EQUALITY distinguishedNameMatch 849 SUBSTR caseIgnoreSubstringMatch 850 SYNTAX DN 851 ) 853 5.1.6 Security Attribute Value 855 (1.3.18.0.2.4.105 856 NAME 'securityAttributeValue' 857 DESC Value of security attribute type 858 SYNTAX DN 859 ) 861 5.1.7 ACL Owner 863 (1.3.18.0.2.4.106 864 NAME 'aclOwner' 865 DESC Owner of the access control list 866 associated with object entry 867 EQUALITY distinguishedNameMatch 868 SUBSTR caseIgnoreSubstringMatch 869 SYNTAX DN 870 ) 872 5.1.8 ACL Entry 874 (1.3.18.0.2.4.107 875 NAME 'aclEntry' 876 DESC Access control list information 877 SUBSTR caseIgnoreSubstringMatch 878 SYNTAX directoryString --see BNF for aclEntry 879 ) 881 5.2 Object Classes 883 5.2.1 Security Object 885 (1.3.18.0.2.6.23 886 NAME 'subjectSecurityObject' 887 DESC security object class for subject 888 security attributes 889 SUP 'top' AUXILIARY 890 MUST ( definingAuthority $ privilegeAttribute $ 891 assertAuthority $ attributeValue 892 ) 893 ) 895 5.3 Matching Rules 897 5.3.1 Subject Security Attribute Match 899 (1.3.18.0.2.10.1 900 NAME 'subjectSecurityAttributeMatch' 901 DESC matching rule for security-relevant 902 attributes of subjects 903 SYNTAX 1.3.18.0.2.8.1 904 ) 906 5.4 Syntax 908 (1.3.18.0.2.8.1 909 DESC security-relevant attributes of subjects 910 syntax (see BNF for securityAttribute) 911 ) 913 6. ACL Credential Controls 915 The ACL credential controls provide a method to flow a 916 subject's credentials associated with a bind. These 917 credentials allow the ACL manager to determine whether 918 that subject's credentials allow access to an object 919 and/or its associated attributes when evaluated against 920 the aclEntry for that object and its attributes. 922 6.1 Request Control 924 This control is included in the bindRequest message as 925 part of the controls field of the LDAPMessage, as 926 defined in Section 4.1.12 of [LDAPv3]. 928 The controlType is set to 1.3.18.0.2.12.1. The 929 criticality MAY be either TRUE or FALSE (where absent is 930 also equivalent to FALSE) at the client's option. The 931 controlValue is an OCTET STRING, whose value is the BER 932 encoding of a value of the following SEQUENCE: 934 subjectCredentialRequest ::= SEQUENCE { 935 credentialVersion INTEGER, 936 subjectSecurityAttributeList OCTET STRING OPTIONAL 937 } 939 The subjectSecurityAttributeList is the list of 940 privileges to remove (assert least privilege) from the 941 subjectSecurityAttribute attribute associated with the 942 object of the bind. If subjectSecurityAttributeList is 943 not present, then the subjectSecurityAttribute attribute 944 associated with the object of the bind is used as-is. 946 6.2 Response Control 948 This control is included in the bindResult message as 949 part of the controls field of the LDAPMessage, as defined 950 in Section 4.1.12 of [LDAPv3]. 952 The controlType is set to 1.3.18.0.2.12.2. The 953 criticality MAY be either TRUE or FALSE (where absent is 954 also equivalent to FALSE). The controlValue is an OCTET 955 STRING, whose value is the BER encoding of a value of the 956 following SEQUENCE: 958 subjectCredentialResponse ::= SEQUENCE { 959 subjectCredentialResult ENUMERATED { 960 success (0), 961 operationsError (1), 962 unavailableCriticalExtension (12), 963 noSuchAttribute (16), 964 undefinedAttributeType (17), 965 invalidAttributeSyntax (21), 966 unavailable (52), 967 unwillingToPerform (53), 968 other (80) 969 } 970 } 972 6.3 Client-Server Interaction 974 The subjectCredentialRequest control specifies the 975 privileges that MUST be in effect for the scope of the 976 bind. The server that consumes the bind operation looks 977 up the subjectSecurityAttribute attribute associated with 978 the bind object, removes any subjectSecurityAttribute 979 attributes passed in the subjectSecurityAttributeList 980 from the set of that bind object's privileges, and stores 981 the result as state information associated with the scope 982 of that bind. 984 The application client may change the privileges 985 associated with the scope of the bind by issuing another 986 bindRequest. 988 There are six possible scenarios that may occur as a 989 result of the credential control being included on the 990 bind request: 992 1. If the server does not support this credential 993 control and the client specified TRUE for the 994 control's criticality field, then the server MUST 995 return unavailableCriticalExtension as a return 996 code in the bindResponse message and not send back 997 any other results. This behavior is specified in 998 section 4.1.12 of [LDAPv3]. 1000 2. If the server does not support this credential 1001 control and the client specified FALSE for the 1002 control's criticality field, then the server MUST 1003 ignore the credential control and process the 1004 credential request as if it were not present. This 1005 behavior is specified in section 4.1.12 of 1006 [LDAPv3]. 1008 3. If the server supports this credential control but 1009 for some reason such as cannot process specified 1010 version of credential and the client specified TRUE 1011 for the control's criticality field, then the 1012 server SHOULD do the following: return 1013 unavailableCriticalExtension as a return code in 1014 the bindResult message and include the 1015 subjectCredentialResponse control in the bindResult 1016 message. 1018 4. If the server supports this credential control but 1019 for some reason such as cannot process specified 1020 version of credential and the client specified 1021 FALSE for the control's criticality field, then the 1022 server should process as 'no privileges' and 1023 include the subjectCredentialResponse control in 1024 the bindResult message. 1026 5. If the server supports this credential control and 1027 can set the privileges per the 1028 subjectSecurityAttributeList information, then it 1029 should include the subjectCredentialResponse 1030 control in the bindResult message with a 1031 subjectCredentialResult of success. 1033 6. If the credential request failed for any reason, 1034 then the server SHOULD omit the 1035 subjectCredentialResponse control from the 1036 bindResult message. 1038 The client application is assured that the correct 1039 privileges are set for the scope of the bind operation if 1040 and only if the result code in the 1041 subjectCredentialResponse control is success. If the 1042 server omits the subjectCredentialResponse control from 1043 the bindResult message, the client SHOULD assume that the 1044 credential control was ignored by the server. 1046 The subjectCredentialResponse control, if included by the 1047 server in the bindResponse message, should have the 1048 subjectCredentialResult set to either success if the 1049 privileges were set in accordance with the privileges 1050 specified in the subjectCredentialRequest control or set 1051 to the appropriate error code as to why the privileges 1052 could not be set. 1054 The server may not be able to remove a privilege because 1055 it may not exist in that bind object's 1056 subjectSecurityAttribute attribute; in this case, the 1057 remove request for that privilege is ignored with error. 1059 7. ACL Extended Operations 1061 Basic operations on ACLs such as add, delete, and modify 1062 can be done using the currently defined set of LDAP 1063 operations. The extension mechanism as defined in the 1064 LDAP protocol specification [LDAPv3] is used to allow the 1065 additional ACL operations to be defined in the LDAP 1066 protocol. These operations are (1) get required rights, 1067 and (2) get effective rights. These extended operations 1068 provide queries associated with ACL operations that are 1069 not possible using the currently defined set of LDAP 1070 operations. 1072 7.1 Get Required Rights Operation 1074 getRequiredRightsRequest ::= [APPLICATION 23] SEQUENCE { 1075 requestName [0] 1.3.18.0.2.14.1, 1076 requestValue [1] OCTET STRING } 1078 where 1080 requestValue ::= SEQUENCE { 1081 dn LDAPDN, 1082 operation ENUMERATED { 1083 LDAP_ACL_ADD (1), 1084 LDAP_ACL_DELETE (2), 1085 LDAP_ACL_MODIFY (4), 1086 LDAP_ACL_COMPARE (8), 1087 LDAP_ACL_SEARCHATTRSONLY (16), 1088 LDAP_ACL_SEARCHATTRSVALS (32), 1089 LDAP_ACL_MODDN (64) 1090 } 1091 } 1093 The requestName is a dotted-decimal representation of the 1094 OBJECT IDENTIFIER corresponding to the request. The 1095 requestValue is information in a form defined by that 1096 request, encapsulated inside an OCTET STRING. 1098 The server will respond to this with an LDAPMessage 1099 containing the ExtendedResponse which is a rights list. 1101 getRequiredRightsResponse ::= [APPLICATION 24] SEQUENCE { 1102 COMPONENTS OF LDAPResult, 1103 responseName [10] 1.3.18.0.2.14.2 OPTIONAL, 1104 rightsList [11] OCTET STRING OPTIONAL } 1106 where 1108 rightsList ::= SEQUENCE OF SEQUENCE { 1109 whichObject ENUMERATED { 1110 LDAP_PARENT (1), 1111 LDAP_SELF (2), 1112 LDAP_NEWPARENT (4) 1113 }, 1114 attributeClass ENUMERATED { 1115 LDAP_NORMAL (1), 1116 LDAP_SENSITIVE (2), 1117 LDAP_CRITICAL (4), 1118 LDAP_OBJECT (8) 1119 }, 1120 permission ENUMERATED { 1121 ACL_ADD (1), 1122 ACL_DEL (2), 1123 ACL_MANAGE (4), 1124 ACL_USE (8), 1125 ACL_READ (16), 1126 ACL_SEARCH (32), 1127 ACL_WRITE (64), 1128 ACL_COMPARE (128), 1129 } 1130 } 1132 If the server does not recognize the request name, it 1133 MUST return only the response fields from LDAPResult, 1134 containing the protocolError result code. 1136 7.2 Get Effective Rights Operation 1138 getEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE { 1139 requestName [0] 1.3.18.0.2.14.3, 1140 requestValue [1] OCTET STRING OPTIONAL } 1142 The requestName is a dotted-decimal representation of the 1143 OBJECT IDENTIFIER corresponding to the request. The 1144 requestValue is information in a form defined by that 1145 request, encapsulated inside an OCTET STRING. 1147 The server will respond to this with an LDAPMessage 1148 containing the ExtendedResponse which is a rights list. 1150 getEffectiveRightsResponse ::= [APPLICATION 24] SEQUENCE 1151 { 1152 COMPONENTS OF LDAPResult, 1153 responseName [10] 1.3.18.0.2.14.4 OPTIONAL, 1154 rightsList [11] OCTET STRING OPTIONAL } 1156 where 1158 rightsList ::= SEQUENCE OF SEQUENCE { 1159 whichObject ENUMERATED { 1160 LDAP_PARENT (1), 1161 LDAP_SELF (2), 1162 LDAP_NEWPARENT (4) 1163 }, 1164 attributeClass ENUMERATED { 1165 LDAP_NORMAL (1), 1166 LDAP_SENSITIVE (2), 1167 LDAP_CRITICAL (4), 1168 LDAP_OBJECT (8) 1169 }, 1170 permission ENUMERATED { 1171 ACL_ADD (1), 1172 ACL_DEL (2), 1173 ACL_MANAGE (4), 1174 ACL_USE (8), 1175 ACL_READ (16), 1176 ACL_SEARCH (32), 1177 ACL_WRITE (64), 1178 ACL_COMPARE (128), 1179 } 1180 } 1182 If the server does not recognize the request name, it 1183 MUST return only the response fields from LDAPResult, 1184 containing the protocolError result code. 1186 8. Security Considerations 1188 This draft proposes a data structure for representing 1189 security policy information. Security considerations are 1190 discussed throughout this draft. Because subject 1191 security attribute information is used to evaluate 1192 decision requests, it is security-sensitive information 1193 and must be protected against unauthorized modification 1194 whenever it is stored or transmitted. 1196 9. References 1198 [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight 1199 Directory Access Protocol (v3)", RFC 2251, December 1997. 1201 [ECMA] ECMA, "Security in Open Systems: A Security 1202 Framework" ECMA TR/46, July 1988 1204 [REQTS] Stokes, Byrne, Blakley, "Access Control 1205 Requirements for LDAP, INTERNET-DRAFT , February 1998. 1208 [ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille, 1209 "Lightweight Directory Access Protocol (v3)": Attribute 1210 Syntax Definitions, RFC 2252, December 1997. 1212 [UTF] M. Wahl, S. Kille, "Lightweight Directory Access 1213 Protocol (v3)": A UTF-8 String Representation of 1214 Distinguished Names", RFC 2253, December 1997. 1216 [Bradner97] Bradner, Scott, "Key Words for use in RFCs to 1217 Indicate Requirement Levels", RFC 2119. 1219 AUTHOR(S) ADDRESS 1221 Bob Blakley Ellen Stokes 1222 IBM IBM 1223 11400 Burnet Rd 11400 Burnet Rd 1224 Austin, TX 78758 Austin, TX 78758 1225 USA USA 1226 mail-to: blakley@us.ibm.com mail-to: stokes@austin.ibm.com 1227 phone: +1 512 838 8133 phone: +1 512 838 3725 1228 fax: +1 512 838 0156 fax: +1 512 838 0156 1230 Debbie Byrne 1231 IBM 1232 11400 Burnet Rd 1233 Austin, TX 78758 1234 USA 1235 mail-to: djbyrne@us.ibm.com 1236 phone: +1 512 838 1960 1237 fax: +1 512 838 0156 1238 CONTENTS 1240 1. Introduction........................................ 2 1242 2. Overview............................................ 2 1243 2.1 Access Control Activity Lifecycle.............. 2 1244 2.2 Access Control Information Model............... 3 1245 2.3 Access Control System Structure................ 3 1246 2.4 Terminology.................................... 6 1248 3. Subject Security Attribute Information.............. 9 1249 3.1 Terminology.................................... 9 1250 3.2 Subject Security Attribute Properties.......... 9 1251 3.3 Examples of Subject Security Attributes........ 10 1252 3.4 Subject Security Attribute Information 1253 Structures..................................... 11 1254 3.4.1 Credentials 11 1255 3.4.2 Subject Security Attributes 12 1256 3.4.3 Encoding 13 1257 3.4.4 Subject Security Attributes 13 1259 4. Access Control Information.......................... 14 1260 4.1 Composition of Access Control Information...... 14 1261 4.1.1 aclEntry Attribute 14 1262 4.1.2 aclOwner Attribute 14 1263 4.1.3 Attribute Classes 15 1264 4.1.4 Access Permissions 15 1265 4.2 Default ACL.................................... 16 1266 4.3 Access Control Information Structures.......... 16 1267 4.4 An ACL Example................................. 17 1268 4.5 LDIF Syntax for Access Control Information..... 18 1270 5. ACL Schema.......................................... 18 1271 5.1 Attributes..................................... 18 1272 5.1.1 Identities Security Attribute 18 1273 5.1.2 Privileges Security Attribute 19 1274 5.1.3 Defining Authority 19 1275 5.1.4 Security Attribute Type 19 1276 5.1.5 Asserting Authority 19 1277 5.1.6 Security Attribute Value 20 1278 5.1.7 ACL Owner 20 1279 5.1.8 ACL Entry 20 1280 5.2 Object Classes................................. 20 1281 5.2.1 Security Object 20 1283 - i - 1285 5.3 Matching Rules................................. 21 1286 5.3.1 Subject Security Attribute Match 21 1287 5.4 Syntax......................................... 21 1289 6. ACL Credential Controls............................. 21 1290 6.1 Request Control................................ 21 1291 6.2 Response Control............................... 22 1292 6.3 Client-Server Interaction...................... 22 1294 7. ACL Extended Operations............................. 24 1295 7.1 Get Required Rights Operation.................. 25 1296 7.2 Get Effective Rights Operation................. 26 1298 8. Security Considerations............................. 27 1300 9. References.......................................... 27 1302 - ii -