idnits 2.17.1 draft-ietf-webdav-acl-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 4) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 568 has weird spacing: '...d, what are t...' -- 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 (January 21, 2001) is 8495 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: 'WEBDAV' is mentioned on line 321, but not defined == Unused Reference: 'RFC2026' is defined on line 1312, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'REC-XML' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Geoffrey Clemm, Rational Software 2 draft-ietf-webdav-acl-04 Anne Hopkins, Microsoft Corporation 3 Eric Sedlar, Oracle Corporation 4 Jim Whitehead, U.C. Santa Cruz 6 Expires July 21, 2001 January 21, 2001 8 WebDAV Access Control Protocol 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document specifies a set of methods, headers, and message bodies 33 that define the WebDAV Access Control extensions to the HTTP/1.1 34 protocol. This protocol permits a client to remotely read and modify 35 access control lists that instruct a server whether to grant or deny 36 operations upon a resource (such as HTTP method invocations) by a given 37 principal. 39 This document is a product of the Web Distributed Authoring and 40 Versioning (WebDAV) working group of the Internet Engineering Task 41 Force. Comments on this draft are welcomed, and should be addressed to 42 the acl@webdav.org mailing list. Other related documents can be found 43 at http://www.webdav.org/acl/, and 44 http://www.ics.uci.edu/pub/ietf/webdav/. 46 Table of Contents 48 1 INTRODUCTION......................................................3 49 1.1 Terms..........................................................4 50 1.2 Notational Conventions.........................................5 52 2 PRINCIPALS........................................................5 54 3 PRIVILEGES........................................................5 55 3.1 DAV:read Privilege.............................................6 56 3.2 DAV:write Privilege............................................6 57 3.3 DAV:read-acl Privilege.........................................7 58 3.4 DAV:write-acl Privilege........................................7 59 3.5 DAV:all Privilege..............................................7 61 4 PRINCIPAL PROPERTIES..............................................7 62 4.1 DAV:is-principal...............................................7 63 4.2 DAV:authentication-id..........................................7 65 5 ACCESS CONTROL PROPERTIES.........................................8 66 5.1 DAV:owner......................................................8 67 5.2 DAV:supported-privilege-set....................................8 68 5.3 DAV:current-user-privilege-set.................................9 69 5.4 DAV:acl........................................................9 70 5.4.1 ACE Principal................................................9 71 5.4.2 ACE Grant and Deny..........................................10 72 5.4.3 ACE Protection..............................................11 73 5.4.4 ACE Inheritance.............................................11 74 5.5 DAV:acl-semantics.............................................11 75 5.6 DAV:principal-collection-set..................................11 76 5.7 Example: PROPFIND to retrieve access control properties.......12 78 6 ACL SEMANTICS....................................................15 79 6.1 ACE Combination...............................................15 80 6.1.1 DAV:first-match ACE Combination.............................15 81 6.1.2 DAV:all-grant-before-any-deny ACE Combination...............15 82 6.1.3 DAV:no-deny ACE Combination.................................15 83 6.2 ACE Ordering..................................................16 84 6.2.1 DAV:deny-before-grant ACE Ordering..........................16 85 6.3 Required Principals...........................................16 87 7 ACCESS CONTROL AND EXISTING METHODS..............................16 88 7.1 OPTIONS.......................................................16 89 7.1.1 Example - OPTIONS...........................................16 91 8 ACCESS CONTROL METHODS...........................................17 92 8.1 ACL...........................................................17 93 8.1.1 ACL Preconditions...........................................17 94 8.1.2 Example: the ACL method.....................................17 95 8.1.3 Example: ACL method failure due to omission of protected ACE18 96 8.1.4 Example: ACL method failure due to inherited ACEs preceding 97 non-inherited ACEs................................................19 98 8.1.5 Example: ACL method failure due to an attempt to set grant and 99 deny in a single ACE..............................................20 100 9 INTERNATIONALIZATION CONSIDERATIONS..............................21 102 10 SECURITY CONSIDERATIONS........................................22 103 10.1 Increased Risk of Compromised Users...........................22 104 10.2 Authentication-id Property and Dictionary Attacks.............22 105 10.3 Risks of the read-acl Privilege...............................23 107 11 AUTHENTICATION.................................................23 109 12 IANA CONSIDERATIONS............................................23 111 13 INTELLECTUAL PROPERTY..........................................23 113 14 ACKNOWLEDGEMENTS...............................................24 115 15 REFERENCES.....................................................24 116 15.1 Normative References..........................................24 117 15.2 Informational References......................................25 119 16 AUTHORS' ADDRESSES.............................................25 121 17 APPENDICIES....................................................25 122 17.1 XML Document Type Definition..................................25 124 1 INTRODUCTION 126 The goal of the WebDAV access control extensions is to provide an 127 interoperable mechanism for handling discretionary access control 128 for content in WebDAV servers. WebDAV access control can be 129 implemented on content repositories with security as simple as that 130 of a UNIX file system, as well as more sophisticated models. The 131 underlying principle of access control is that who you are 132 determines how you can access a resource. The "who you are" is 133 defined by a "principal" identifier; users, client software, 134 servers, and groups of the previous have principal identifiers. The 135 "how" is determined by a single "access control list" (ACL) 136 associated with a resource. An ACL contains a set of "access 137 control entries" (ACEs), where each ACE specifies a principal and a 138 set of privileges that are either granted or denied to that 139 principal. When a principal submits an operation (such as an HTTP or 140 WebDAV method) to a resource for execution, the server evaluates the 141 ACEs in the ACL to determine if the principal has permission for 142 that operation. 144 This specification intentionally omits discussion of authentication, 145 as the HTTP protocol already has a number of authentication 146 mechanisms [RFC2617]. Some authentication mechanism (such as HTTP 147 Digest Authentication, which all WebDAV compliant implementations 148 are required to support) must be available to validate the identity 149 of a principal. 151 In the interests of timeliness, the following set of security 152 mechanisms are not addressed by this document: 154 * Access control that applies only to a particular property on 155 a resource, rather than the entire resource, 157 * Role-based security (where a role can be seen as a 158 dynamically defined collection of principals), 160 * Specification of the ways an ACL on a resource is 161 initialized, 163 * Specification of an ACL that applies globally to a method, 164 rather than to a particular resource. 166 This specification is organized as follows. Section 1.1 defines key 167 concepts used throughout the specification, and is followed by more 168 in-depth discussion of principals (Section 2), and privileges 169 (Section 3). Properties defined on principals are specified in 170 Section 4, and access control properties for content resources are 171 specified in Section 5. The semantics of access control lists are 172 described in Section 6, including sections on ACE combination 173 (Section 6.1), ACE ordering (Section 6.2), and principals required 174 to be present in an ACE (Section 6.3). Client discovery of access 175 control capability using OPTIONS is described in Section 7.1, and 176 the access control setting method, ACL, is specified in Section 8. 177 Internationalization considerations (Section 9) and security 178 considerations (Section 10) round out the specification. An appendix 179 (Section 17.1) provides an XML Document Type Definition (DTD) for 180 the XML elements defined in the specification. 182 1.1 Terms 184 This draft uses the terms defined in HTTP [RFC2616] and WebDAV 185 [RFC2518]. In addition, the following terms are defined: 187 principal 189 A "principal" is a distinct human or computational actor that 190 initiates access to network resources. In this protocol, a 191 principal is an HTTP resource that represents such an actor. 193 principal collection 195 A "principal collection" is a group of principals, and is 196 represented in this protocol by a WebDAV collection containing HTTP 197 resources that represent principals, and principal collections. 199 privilege 201 A "privilege" controls access to a particular set of HTTP operations 202 on a resource. 204 aggregate privilege 206 An "aggregate privilege" is a privilege that contains a set of other 207 privileges. 209 abstract privilege 210 The modifier "abstract", when applied to an atomic or aggregate 211 privilege, means the privilege cannot be set in an access control 212 element (ace). 214 access control list (acl) 216 An "acl" is a list of access control elements that define access 217 control to a particular resource. 219 access control element (ace) 221 An "ace" either grants or denies a particular set of (non-abstract) 222 privileges for a particular principal. 224 inherited ace 226 An "inherited ace" is an ace that is shared from the acl of another 227 resource. 229 1.2 Notational Conventions 231 The augmented BNF used by this document to describe protocol 232 elements is described in Section 2.1 of [RFC2616]. Because this 233 augmented BNF uses the basic production rules provided in Section 234 2.2 of [RFC2616], those rules apply to this document as well. 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 238 document are to be interpreted as described in [RFC2119]. 240 2 PRINCIPALS 242 A principal is an HTTP resource that represents a distinct human or 243 computational actor that initiates access to network resources. On 244 many implementations, users and groups are represented as 245 principals; other types of principals are also possible. Although 246 an implementation MAY support PROPFIND and PROPPATCH to access and 247 modify information about a principal, it is not required to do so. 249 A principal resource may or may not be a collection. A collection 250 principal may only contain other principals (not other types of 251 resources). Servers that support aggregation of principals (e.g. 252 groups of users or other groups) MUST manifest them as collection 253 principals. The WebDAV methods for examining and maintaining 254 collections (e.g. DELETE, PROPFIND) MAY be used to maintain 255 collection principals. Membership in a collection principal is 256 recursive, so a principal in a collection principal GRPA contained 257 by collection principal GRPB is a member of both GRPA and GRPB. 258 Implementations not supporting recursive membership in principal 259 collections can return an error if the client attempts to bind 260 collection principals into other collection principals. 262 3 PRIVILEGES 264 Ability to perform a given method on a resource SHOULD be controlled 265 by one or more privileges. Authors of protocol extensions that 266 define new HTTP methods SHOULD specify which privileges (by defining 267 new privileges, or mapping to ones below) are required to perform 268 the method. A principal with no privileges to a resource SHOULD be 269 denied any HTTP access to that resource. 271 Privileges may be containers of other privileges, in which case they 272 are termed aggregate privileges. If a principal is granted or 273 denied an aggregate privilege, it is semantically equivalent to 274 granting or denying each of the aggregated privileges individually. 275 For example, an implementation may define add-member and remove- 276 member privileges that control the ability to add and remove an 277 internal member of a collection. Since these privileges control the 278 ability to update the state of a collection, these privileges would 279 be aggregated by the DAV:write privilege on a collection, and 280 granting the DAV:write privilege on a collection would also grant 281 the add-member and remove-member privileges. 283 Privileges may have the quality of being abstract, in which case 284 they cannot be set in an ACE. Aggregate and atomic privileges are 285 both capable of being abstract. Abstract privileges are useful for 286 modeling privileges that otherwise would not be exposed via the 287 protocol. Abstract privileges also provide server implementations 288 with flexibility in implementing the privileges defined in this 289 specification. For example, if a server is incapable of separating 290 the read resource capability from the read ACL capability, it can 291 still model the DAV:read and DAV:read-acl privileges defined in this 292 specification by declaring them abstract, and containing them within 293 a non-abstract aggregate privilege (say, read-all) that holds 294 DAV:read, and DAV:read-acl. In this way, it is possible to set the 295 aggregate privilege, read-all, thus coupling the setting of DAV:read 296 and DAV:read-acl, but it is not possible to set DAV:read, or 297 DAV:read-acl individually. Since aggregate privileges can be 298 abstract, it is also possible to use abstract privileges to group 299 and classify non-abstract privileges. 301 The set of privileges that apply to a particular resource may vary 302 with the DAV:resourcetype of the resource, as well as between 303 different server implementations. To promote interoperability, 304 however, WebDAV defines a set of well-known privileges (e.g. 305 DAV:read and DAV:write), which can at least be used to classify the 306 other privileges defined on a particular resource. 308 3.1 DAV:read Privilege 310 The read privilege controls methods that return information about 311 the state of the resource, including the resource's properties. 312 Affected methods include GET and PROPFIND. Additionally, the read 313 privilege MAY control the OPTIONS method. 315 317 3.2 DAV:write Privilege 319 The write privilege controls methods that modify the state of the 320 resource, such as PUT and PROPPATCH. Note that state modification 321 is also controlled via locking (see section 5.3 of [WEBDAV]), so 322 effective write access requires that both write privileges and write 323 locking requirements are satisfied. 325 327 3.3 DAV:read-acl Privilege 329 The DAV:read-acl privilege controls the use of PROPFIND to retrieve 330 the DAV:acl, and DAV:current-user-privilege-set properties of the 331 resource. 333 335 3.4 DAV:write-acl Privilege 337 The DAV:write-acl privilege controls use of the ACL method to modify 338 the DAV:acl property of the resource. 340 342 3.5 DAV:all Privilege 344 DAV:all is an aggregate privilege that contains all privileges on 345 the resource. 347 349 4 PRINCIPAL PROPERTIES 351 Principals are manifested to clients as an HTTP resource, identified 352 by a URL. A principal MUST have a DAV:displayname property. This 353 protocol defines the following additional properties for a 354 principal. 356 4.1 DAV:is-principal 358 This property indicates whether this resource is a principal. A 359 resource MUST have a non-empty DAV:is-principal property if and only 360 if it is a principal resource. (Note: If we can just add a 361 DAV:principal element to the DAV:resourcetype property, then we do 362 not need a DAV:is-principal property.) 364 365 PCDATA value: any non-empty value ("T" is suggested) 367 4.2 DAV:authentication-id 369 A property containing the name used to authenticate this principal 370 (typically typed into a login prompt/dialog). 372 373 PCDATA value: any string 374 5 ACCESS CONTROL PROPERTIES 376 This specification defines a number of new properties for WebDAV 377 resources. Access control properties may be retrieved just like 378 other WebDAV properties, using the PROPFIND method. Some access 379 control properties (such as DAV:owner) MAY be updated with the 380 PROPPATCH method. 382 HTTP resources that support the WebDAV Access Control Protocol MUST 383 contain the following properties: 385 5.1 DAV:owner 387 This property identifies a particular principal as being the "owner" 388 of the resource. 390 391 393 An implementation MAY include a list of selected properties of that 394 principal resource. Which properties (if any) are included is 395 implementation defined. An implementation MAY allow the use of 396 PROPPATCH to update the DAV:owner field. 398 5.2 DAV:supported-privilege-set 400 This is a read-only property that identifies the privileges defined 401 for the resource. 403 405 Each privilege appears as an XML element, where aggregate privileges 406 list as sub-elements all of the privileges that they aggregate. 408 410 412 An abstract privilege of a resource MUST NOT be used in an ACE for 413 that resource. Servers MUST fail an attempt to set an abstract 414 privilege. 416 418 A description is a human-readable description of what this privilege 419 controls access to. 421 423 It is envisioned that a WebDAV ACL-aware administrative client would 424 list the supported privileges in a dialog box, and allow the user to 425 choose non-abstract privileges to apply in an ACE. The privileges 426 tree is useful programmatically to map well-known privileges 427 (defined by WebDAV or other standards groups) into privileges that 428 are supported by any particular server implementation. The 429 privilege tree also serves to hide complexity in implementations 430 allowing large number of privileges to be defined by displaying 431 aggregates to the user. 433 5.3 DAV:current-user-privilege-set 435 DAV:current-user-privilege-set is a read-only property containing 436 the exact set of privileges (as computed by the server) granted to 437 the currently authenticated HTTP user. A user-agent can use the 438 value of this property to adjust its user interface to make actions 439 inaccessible (e.g, by graying out a menu item or button) for which 440 the current principal does not have permission. This is particularly 441 useful for an access control user interface, which can be 442 constructed without knowing the ACE combining semantics of the 443 server. This property is also useful for determine what operations 444 can be performed by the current principal, without having to 445 actually execute an operation. 447 448 450 If the current user is granted a specific privilege, that privilege 451 must belong to the set of privileges that may be set on this 452 resource. Therefore, each element in the DAV:current-user-privilege- 453 set property MUST identify a privilege from the DAV:supported- 454 privilege-set property. 456 5.4 DAV:acl 458 This property specifies the list of access control entries (ACEs), 459 which define what principals are to get what privileges for this 460 resource. 462 464 Each DAV:ace element specifies the set of privileges to be either 465 granted or denied to a single principal. If the DAV:acl property is 466 empty, no principal is granted any privilege. 468 470 An attempt to update the DAV:acl property with a PROPPATCH MUST 471 fail. 473 5.4.1 ACE Principal 475 The DAV:principal element identifies the principal to which this ACE 476 applies. 478 482 The current user matches DAV:href only if that user is authenticated 483 as being (or being a member of) the principal identified by the URL 484 contained by that DAV:href. An implementation MAY include a 485 DAV:prop element after the DAV:href element, containing a list of 486 selected properties of that principal resource. Which properties 487 (if any) are included in the DAV:prop element is implementation 488 defined. The DAV:prop element is primarily intended for 489 implementations that do not support PROPFIND requests on the 490 principal URL. 492 494 The current user always matches DAV:all. 496 498 The current user matches DAV:authenticated only if authenticated. 500 502 The current user matches DAV:unauthenticated only if not 503 authenticated. 505 507 DAV:all is the union of DAV:authenticated, and DAV:unauthenticated. 508 For a given request, the user matches either DAV:authenticated, or 509 DAV:unauthenticated, but not both. 511 The current user matches a DAV:property principal in a DAV:acl 512 property of a resource only if the identified property of that 513 resource contains a DAV:href that identifies a principal, and the 514 current user is authenticated as being (or being a member of) that 515 principal. For example, if the DAV:property element contained 516 , the current user would match the DAV:property 517 principal only if the current user is authenticated as matching the 518 principal identified by the DAV:owner property of the resource. 520 522 The current user matches DAV:self in a DAV:acl property of the 523 resource only if that resource is a principal object and the current 524 user is authenticated as being that principal. 526 528 5.4.2 ACE Grant and Deny 530 Each DAV:grant or DAV:deny element specifies the set of privileges 531 to be either granted or denied to the specified principal. A 532 DAV:grant or DAV:deny element of the DAV:acl of a resource MUST only 533 contain elements specified in the DAV:supported-privilege-set of 534 that resource. 536 537 538 539 5.4.3 ACE Protection 541 If an ACE contains a DAV:protected element, an ACL request without 542 that ACE MUST fail. 544 546 5.4.4 ACE Inheritance 548 The presence of a DAV:inherited element indicates that this ACE is 549 inherited from another resource that is identified by the URL 550 contained in a DAV:href element. An inherited ACE cannot be 551 modified directly, but instead the ACL on the resource from which it 552 is inherited must be modified. 554 Note that ACE inheritance is not the same as ACL initialization. 555 ACL initialization defines the ACL that a newly created resource 556 will use (if not specified). ACE inheritance refers to an ACE that 557 is logically shared - where an update to the resource containing an 558 ACE will affect the ACE of each resource that inherits that ACE. 559 The method by which ACLs are initialized or by which ACEs are 560 inherited is not defined by this document. 562 564 5.5 DAV:acl-semantics 566 This is a read-only property that defines the ACL semantics. These 567 semantics define how multiple ACEs that match the current user are 568 combined, what are the constraints on how ACEs can be ordered, and 569 which principals must have an ACE. 571 Since it is not practical to require all implementations to use the 572 same ACL semantics, the DAV:acl-semantics property is used to 573 identify the ACL semantics for a particular resource. The DAV:acl- 574 semantics element is defined in section 6. 576 5.6 DAV:principal-collection-set 578 This read-only property contains zero, one, or more URLs that 579 identify a collection principal. It is expected that implementations 580 of this protocol will typically employ a relatively small number of 581 locations in the URL namespace for principal, and collection 582 principals. In cases where this assumption holds, the DAV:principal- 583 collection-set property will contain a small set of URLs identifying 584 the top of collection hierarchy containing multiple principals and 585 collection principals. An access control protocol user agent could 586 use the contents of DAV:principal-collection-set to, for example, 587 query the DAV:displayname property (specified in Section 13.2 of 588 [RFC2518]) of all principals on that server, thereby yielding human- 589 readable names for each principal that could be displayed in a user 590 interface. 592 594 Since different servers can control different parts of the URL 595 namespace, different resources on the same host MAY have different 596 DAV:principal-collection-set values. The collections specified in 597 the DAV:principal-collection-set MAY be located on different hosts 598 from the resource. The URLs in DAV:principal-collection-set are not 599 limited to http scheme URLs, and can, for example, be ldap scheme 600 URLs. For security and scalability reasons, a server MAY report only 601 a subset of the entire set of known collection principals, and 602 therefore clients should not assume they have retrieved an 603 exhaustive listing. Additionally, a server MAY elect to report none 604 of the collection principals it knows about. 606 5.7 Example: PROPFIND to retrieve access control properties 608 The following example shows how access control information can be 609 retrieved by using the PROPFIND method to fetch the values of the 610 DAV:owner, DAV:supported-privilege-set, DAV:current-user-privilege- 611 set, and DAV:acl properties. 613 >> Request << 615 PROPFIND /top/container/ HTTP/1.1 616 Host: www.foo.org 617 Content-type: text/xml; charset="utf-8" 618 Content-Length: xxx 619 Depth: 0 620 Authorization: Digest username="ejw", 621 realm="users@foo.org", nonce="...", 622 uri="/top/container/", response="...", opaque="..." 624 625 626 627 628 629 630 632 >> Response << 634 HTTP/1.1 207 Multi-Status 635 Content-Type: text/xml; charset="utf-8" 636 Content-Length: xxx 638 639 642 HTTP/1.1 200 OK 643 644 645 http://www.foo.org/users/gclemm 646 647 648 649 650 Any operation 651 652 653 Read any object 654 655 656 657 658 Write any object 659 660 661 Create an object 662 663 664 665 Update an object 666 667 668 669 Delete an object 670 671 672 673 674 Read the ACL 675 676 677 678 Write the ACL 679 680 681 682 683 684 685 686 687 688 689 http://www.foo.org/users/esedlar 690 691 esedlar 692 Eric Sedlar 693 694 695 696 697 698 699 700 701 http://www.foo.org/groups/marketing/ 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 http://www.foo.org/top/ 719 720 721 723 The value of the DAV:owner property is a single DAV:href XML element 724 containing the URL of the principal that owns this resource. 726 The value of the DAV:supported-privilege-set property is a tree of 727 supported privileges: 729 DAV:acl (aggregate, abstract) 730 | 731 +-- DAV:read 732 +-- DAV:write (aggregate, abstract) 733 | 734 +-- http://www.acl.org/create 735 +-- http://www.acl.org/update 736 +-- http://www.acl.org/delete 737 +-- DAV:read-acl 738 +-- DAV:write-acl 740 The DAV:current-user-privilege-set property contains two privileges, 741 DAV:read, and DAV:read-acl. This indicates that the current 742 authenticated user only has the ability to read the resource, and 743 read the DAV:acl property on the resource. 745 The DAV:acl property contains a set of four ACEs: 747 ACE #1: The principal identified by the URL 748 http://www.foo.org/users/esedlar is granted the DAV:read, DAV:write, 749 and DAV:read-acl privileges. 751 ACE #2: The principals identified by the URL 752 http://www.foo.org/groups/marketing/ are denied the DAV:read 753 privilege. In this example, the principal URL identifies a group, 754 which is represented by a collection principal. 756 ACE #3: In this ACE, the principal is a property principal, 757 specifically the DAV:owner property. When evaluating this ACE, the 758 value of the DAV:owner property is retrieved, and is examined to see 759 if it contains a DAV:href XML element. If so, the URL within the 760 DAV:href element is read, and identifies a principal. In this ACE, 761 the owner is granted DAV:read-acl, and DAV:write-acl privileges. 763 ACE #4: This ACE grants the DAV:all principal (all users) the 764 DAV:read privilege. This ACE is inherited from the resource 765 http://www.foo.org/top/, the parent collection of this resource. 767 6 ACL SEMANTICS 769 The ACL semantics define how multiple ACEs that match the current 770 user are combined, what are the constraints on how ACEs can be 771 ordered, and which principals must have an ACE. 773 775 778 6.1 ACE Combination 780 The DAV:ace-combination element defines how privileges from multiple 781 ACEs that match the current user will be combined to determine the 782 access privileges for that user. Multiple ACEs may match the same 783 user because the same principal can appear in multiple ACEs, because 784 multiple principals can identify the same user, and because one 785 principal can be a member of another principal. 787 790 6.1.1 DAV:first-match ACE Combination 792 The ACEs are evaluated in the order in which they appear in the ACL. 793 If the first ACE that matches the current user does not grant all 794 the privileges needed for the request, the request MUST fail. 796 798 6.1.2 DAV:all-grant-before-any-deny ACE Combination 800 The ACEs are evaluated in the order in which they appear in the ACL. 801 If an evaluated ACE denies a privilege needed for the request, the 802 request MUST fail. If all ACEs have been evaluated without the user 803 being granted all privileges needed for the request, the request 804 MUST fail. 806 808 6.1.3 DAV:no-deny ACE Combination 810 All ACEs in the ACL are evaluated. An "individual ACE" is one whose 811 principal identifies the current user. A "group ACE" is one whose 812 principal is a collection that contains a principal that identifies 813 the current user. A privilege is granted if it is granted by an 814 individual ACE and not denied by an individual ACE, or if it is 815 granted by a group ACE and not denied by an individual or group ACE. 816 A request MUST fail if any of its needed privileges are not granted. 818 820 6.2 ACE Ordering 822 The DAV:ace-ordering element defines a constraint on how the ACEs 823 can be ordered in the ACL. 825 827 6.2.1 DAV:deny-before-grant ACE Ordering 829 This element indicates that all deny ACEs must precede all grant 830 ACEs. 832 834 6.3 Required Principals 836 The required principal elements identify which principals must have 837 an ACE defined in the ACL. 839 843 For example, the following element requires that the ACE contain a 844 DAV:owner property ACE: 846 847 848 850 7 ACCESS CONTROL AND EXISTING METHODS 852 This section defines the impact of access control functionality on 853 existing methods. 855 7.1 OPTIONS 857 If the server supports access control, it MUST return "access- 858 control" as a field in the DAV response header from an OPTIONS 859 request on any resource implemented by that server. 861 7.1.1Example - OPTIONS 863 >> REQUEST << 865 OPTIONS /foo.html HTTP/1.1 866 Host: www.webdav.org 867 Content-Length: 0 868 >> RESPONSE << 870 HTTP/1.1 200 OK 871 DAV: 1, 2, access-control 872 Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL 874 In this example, the OPTIONS response indicates that the server 875 supports access control and that /foo.html can have its access 876 control list modified by the ACL method. 878 8 ACCESS CONTROL METHODS 880 8.1 ACL 882 A DAV:acl property of a resource is modified by the ACL method. A 883 new DAV:acl value must be written in its entirety, including any 884 inherited ACEs. Unless the DAV:acl property of the resource can be 885 updated to be exactly the value specified in the ACL request, the 886 ACL request MUST fail. If a server restricts the set of ACEs 887 visible to the current user via the DAV:acl property, then the ACL 888 request would only replace the set of ACEs visible to the current 889 user, and would not affect any ACE that was not visible. 891 In order to avoid overwriting DAV:acl changes by another client, a 892 client SHOULD acquire a WebDAV lock on the resource before 893 retrieving the DAV:acl property of a resource that it intends on 894 updating. 896 8.1.1 ACL Preconditions 898 An implementation MAY enforce one or more of the following 899 constraints on an ACL request. If the constraint is violated, a 403 900 (Forbidden) response MUST be returned and the indicated XML element 901 MUST be returned in the response body. 903 : An implementation MAY protect an ACE from 904 modification or deletion. For example, some implementations 905 implicitly grant the DAV:owner of a resource DAV:read-acl and 906 DAV:write-acl privileges, and this cannot be changed by a client. 908 : An implementation MAY limit the number of ACEs 909 in an ACL. However, ACL-compliant servers MUST support at least one 910 ACE granting privileges to a single principal, and one ACE granting 911 privileges to a collection principal. 913 : All non-inherited ACEs 914 MUST precede all inherited ACEs. 916 : All non-inherited deny ACEs MUST 917 precede all non-inherited grant ACEs. 919 8.1.2 Example: the ACL method 921 In the following example, user "fielding", authenticated by 922 information in the Authorization header, grants the principal 923 identified by the URL http://www.foo.org/users/esedlar (i.e., the 924 user "esedlar") read and write privileges, grants the owner of the 925 resource read-acl and write-acl privileges, and grants everyone read 926 privileges inherited from the parent collection 927 http://www.foo.bar/top/. 929 >> Request << 931 ACL /top/container/ HTTP/1.1 932 Host: www.foo.org 933 Content-Type: text/xml; charset="utf-8" 934 Content-Length: xxxx 935 Authorization: Digest username="fielding", 936 realm="users@foo.org", nonce="...", 937 uri="/top/container/", response="...", opaque="..." 939 940 941 942 943 http://www.foo.org/users/esedlar 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 http://www.foo.org/top/ 962 964 >> Response << 966 HTTP/1.1 200 OK 968 8.1.3 Example: ACL method failure due to omission of protected ACE 970 In the following request, user "fielding", authenticated by 971 information in the Authorization header, attempts to grant the 972 principal identified by the URL http://www.foo.org/users/esedlar 973 (i.e., the user "esedlar") read privileges, but fails because an 974 protected ACE has been omitted (e.g. the ACE granting the DAV:owner 975 DAV:read-acl and DAV:write-acl privileges must always be present 976 since it is protected -- see Section 5.4.3). 978 >> Request << 980 ACL /top/container/ HTTP/1.1 981 Host: www.foo.org 982 Content-Type: text/xml; charset="utf-8" 983 Content-Length: xxxx 984 Authorization: Digest username="fielding", 985 realm="users@foo.org", nonce="...", 986 uri="/top/container/", response="...", opaque="..." 988 989 990 991 992 http://www.foo.org/users/esedlar 993 994 995 996 997 999 >> Response << 1001 HTTP/1.1 403 Forbidden 1002 Content-Type: text/xml; charset="utf-8" 1003 Content-Length: xxx 1005 1006 1008 8.1.4 Example: ACL method failure due to inherited ACEs preceding non- 1009 inherited ACEs 1011 In the following request, user "ejw", authenticated by information 1012 in the Authorization header, tries to change the access control list 1013 on the resource http://www.foo.org/top/index.html. This resource has 1014 two inherited ACEs. 1016 Inherited ACE #1 grants the principal identified by URL 1017 http://www.foo.org/users/ejw (i.e., the user "ejw") 1018 http://www.foo.org/privs/write-all and DAV:read-acl privileges. On 1019 this server, http://www.foo.org/privs/write-all is an aggregate 1020 privilege containing DAV:write, and DAV:write-acl. 1022 Inherited ACE #2 grants principal DAV:all the DAV:read privilege. 1024 The request attempts to add a third ACE, granting the principal 1025 identified by the URL http://www.foo.org/users/gclemm (i.e., the 1026 user "gclemm") DAV:write permission, but in the request places the 1027 inherited ACEs before the non-inherited ACEs, causing an error on 1028 this specific server implementation. Note that on a different 1029 implementation, this request might be accepted. 1031 >> Request << 1032 ACL /top/index.html HTTP/1.1 1033 Host: www.foo.org 1034 Content-Type: text/xml; charset="utf-8" 1035 Content-Length: xxxx 1036 Authorization: Digest username="ejw", 1037 realm="users@foo.org", nonce="...", 1038 uri="/top/index.html", response="...", opaque="..." 1040 1041 1042 1043 1044 http://www.foo.org/users/ejw 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 http://www.foo.org/users/gclemm 1060 1061 1062 1063 1065 >> Response << 1067 HTTP/1.1 403 Forbidden 1068 Content-Type: text/xml; charset="utf-8" 1069 Content-Length: xxx 1071 1072 1074 8.1.5 Example: ACL method failure due to an attempt to set grant and 1075 deny in a single ACE. 1077 In this example, user "ygoland", authenticated by information in the 1078 Authorization header, tries to change the access control list on the 1079 resource http://www.foo.org/diamond/engagement-ring.gif. The ACL 1080 request includes a single, syntactically and semantically incorrect 1081 ACE, which attempts to grant the collection principal identified by 1082 the URL http://www.foo.org/users/friends/ DAV:read privilege and 1083 deny the principal identified by URL 1084 http://www.foo.org/users/ygoland-so (i.e., the user "ygoland-so") 1085 DAV:read privilege. However, it is illegal to have multiple 1086 principal elements, as well as both a grant and deny element in the 1087 same ACE, so the request fails due to poor syntax. 1089 >> Request << 1091 ACL /diamond/engagement-ring.gif HTTP/1.1 1092 Host: www.foo.org 1093 Content-Type: text/xml; charset="utf-8" 1094 Content-Length: xxxx 1095 Authorization: Digest username="ygoland", 1096 realm="users@foo.org", nonce="...", 1097 uri="/diamond/engagement-ring.gif", response="...", 1098 opaque="..." 1100 1101 1102 1103 1104 http://www.foo.org/users/friends/ 1105 1106 1107 1108 http://www.foo.org/users/ygoland-so 1109 1110 1111 1112 1114 >> Response << 1116 HTTP/1.1 400 Bad Request 1117 Content-Length: 0 1119 Note that if the request had been divided into two ACEs, one to 1120 grant, and one to deny, the request would have been syntactically 1121 well formed. 1123 9 INTERNATIONALIZATION CONSIDERATIONS 1125 In this specification, the only human-readable content can be found 1126 in the DAV:authentication-id property, found on principal resources. 1127 This property contains the name used to authenticate a principal, 1128 typically by a user entering this name into a password entry screen. 1129 As a result, the authentication-id must be capable of representing 1130 names in multiple character sets. Since DAV:authentication-id is a 1131 WebDAV property, it is represented on-the-wire as XML [REC-XML], and 1132 hence can leverage XML's language tagging and character set encoding 1133 capabilities. Specifically, XML processors must, at minimum, be able 1134 to read XML elements encoded using the UTF-8 [UTF-8] encoding of the 1135 ISO 10646 multilingual plane. XML examples in this specification 1136 demonstrate use of the charset parameter of the Content-Type header, 1137 as defined in [RFC3023], as well as the XML "encoding" attribute, 1138 which together provide charset identification information for MIME 1139 and XML processors. 1141 For properties other than DAV:authentication-id, it is expected that 1142 implementations will treat the property names and values as tokens, 1143 and convert these tokens into human-readable text in the user's 1144 language and character set when displayed to a person. Only a 1145 generic WebDAV property display utility would display these values 1146 in their raw form. 1148 For error reporting, we follow the convention of HTTP/1.1 status 1149 codes, including with each status code a short, English description 1150 of the code (e.g., 200 (OK)). While the possibility exists that a 1151 poorly crafted user agent would display this message to a user, 1152 internationalized applications will ignore this message, and display 1153 an appropriate message in the user's language and character set. 1155 Further internationalization considerations for this protocol are 1156 described in the WebDAV Distributed Authoring protocol specification 1157 [RFC2518]. 1159 10 SECURITY CONSIDERATIONS 1161 Applications and users of this access control protocol should be 1162 aware of several security considerations, detailed below. In 1163 addition to the discussion in this document, the security 1164 considerations detailed in the HTTP/1.1 specification [RFC2616], the 1165 WebDAV Distributed Authoring Protocol specification [RFC2518], and 1166 the XML Media Types specification [RFC3023] should be considered in 1167 a security analysis of this protocol. 1169 10.1 Increased Risk of Compromised Users 1171 In the absence of a mechanism for remotely manipulating access 1172 control specifications, if a single user's authentication 1173 credentials are compromised, only those resources for which the user 1174 has access permission can be read, modified, moved, or deleted. With 1175 the introduction of this access control protocol, if a single 1176 compromised user has the ability to change ACLs for a broad range of 1177 other users (e.g., a super-user), the number of resources that could 1178 be altered by a single compromised user increases. This risk can be 1179 mitigated by limiting the number of people who have write-acl 1180 privileges across a broad range of resources. 1182 10.2 Authentication-id Property and Dictionary Attacks 1184 Every principal has a DAV:authentication-id property defined on it, 1185 which provides the name used to authenticate this principal, 1186 typically the username portion of a username/password authentication 1187 scheme. An attacker can use the information in this property when 1188 attempting either a brute-force, or a dictionary attack to guess the 1189 principal's identifying password. By providing the username in 1190 DAV:authentication-id, the scope of an attack can be reduced to a 1191 single, valid username. Furthermore, it is possible that principals 1192 can potentially belong to a collection. In this case, it is possible 1193 to use the PROPFIND method to retrieve the DAV:authentication-id 1194 property from all of the principals in a collection, thus providing 1195 multiple usernames that can be the focus of attack. 1197 To reduce this risk, the DAV:authentication-id property should not 1198 be world-readable. Which principals are granted default read 1199 privilege for DAV:authentication-id should be carefully considered 1200 in any deployment of this protocol. 1202 10.3 Risks of the read-acl Privilege 1204 The ability to read the access privileges (stored in the DAV:acl 1205 property), or the privileges permitted the currently authenticated 1206 user (stored in the DAV:current-user-privilege-set property) on a 1207 resource may seem innocuous, since reading an ACL cannot possibly 1208 affect the resource's state. However, if all resources have world- 1209 readable ACLs, it is possible to perform an exhaustive search for 1210 those resources that have inadvertently left themselves in a 1211 vulnerable state, such as being world-writeable. In particular, the 1212 property retrieval method PROPFIND, executed with Depth infinity on 1213 an entire hierarchy, is a very efficient way to retrieve the DAV:acl 1214 or DAV:current-user-privilege-set properties. Once found, this 1215 vulnerability can be exploited by a denial of service attack in 1216 which the open resource is repeatedly overwritten. Alternately, 1217 writeable resources can be modified in undesirable ways. 1219 To reduce this risk, read-acl privileges should not be granted to 1220 unauthenticated principals, and restrictions on read-acl privileges 1221 for authenticated principals should be carefully analyzed when 1222 deploying this protocol. 1224 11 AUTHENTICATION 1226 Authentication mechanisms defined in WebDAV also apply to this 1227 WebDAV Access Control Protocol, in particular the Basic and Digest 1228 authentication mechanisms defined in [RFC2617]. 1230 12 IANA CONSIDERATIONS 1232 This document uses the namespace defined by [RFC2518] for XML 1233 elements. All other IANA considerations mentioned in [RFC2518] also 1234 applicable to WebDAV ACL. 1236 13 INTELLECTUAL PROPERTY 1238 The following notice is copied from RFC 2026, section 10.4, and 1239 describes the position of the IETF concerning intellectual property 1240 claims made against this document. 1242 The IETF takes no position regarding the validity or scope of any 1243 intellectual property or other rights that might be claimed to 1244 pertain to the implementation or use other technology described in 1245 this document or the extent to which any license under such rights 1246 might or might not be available; neither does it represent that it 1247 has made any effort to identify any such rights. Information on the 1248 IETF's procedures with respect to rights in standards-track and 1249 standards-related documentation can be found in BCP-11. Copies of 1250 claims of rights made available for publication and any assurances 1251 of licenses to be made available, or the result of an attempt made 1252 to obtain a general license or permission for the use of such 1253 proprietary rights by implementers or users of this specification 1254 can be obtained from the IETF Secretariat. 1256 The IETF invites any interested party to bring to its attention any 1257 copyrights, patents or patent applications, or other proprietary 1258 rights that may cover technology that may be required to practice 1259 this standard. Please address the information to the IETF Executive 1260 Director. 1262 14 ACKNOWLEDGEMENTS 1264 This protocol is the collaborative product of the WebDAV ACL design 1265 team: Bernard Chester, Geoff Clemm (Rational), Anne Hopkins 1266 (Microsoft), Barry Lind (Xythos), Sean Lyndersay (Microsoft), Eric 1267 Sedlar (Oracle), Greg Stein (Apache.org), and Jim Whitehead (UC 1268 Santa Cruz). The authors are grateful for the detailed review and 1269 comments provided by Jim Amsden, Gino Basso, Murthy Chintalapati, 1270 Dennis Hamilton, Ron Jacobs, Chris Knight, and Remy Maucherat. Prior 1271 work on WebDAV access control protocols has been performed by Yaron 1272 Goland, Paul Leach, Lisa Dusseault, Howard Palmer, and Jon Radoff. 1273 We would like to acknowledge the foundation laid for us by the 1274 authors of the WebDAV and HTTP protocols upon which this protocol is 1275 layered, and the invaluable feedback from the WebDAV working group. 1277 15 REFERENCES 1279 15.1 Normative References 1281 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 1282 Requirement Levels." RFC 2119, BCP 14, Harvard, March, 1997. 1284 [REC-XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible 1285 Markup Language (XML)." World Wide Web Consortium Recommendation 1286 REC-xml-19980210. http://www.w3.org/TR/REC-xml-19980210. 1288 [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. 1289 Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol 1290 -- HTTP/1.1." RFC 2616. U.C.Irvine, Compaq, Xerox, Microsoft, 1291 MIT/LCS, June, 1999. 1293 [RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. 1294 Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and 1295 Digest Access Authentication. " RFC 2617. Northwestern University, 1296 Verisign, AbiSource, Agranat, Microsoft, Netscape, Open Market, 1297 June, 1999. 1299 [RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. R. Carter, D. 1300 Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV." RFC 1301 2518. Microsoft, U.C.Irvine, Netscape, Novell, February, 1999. 1303 [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types." RFC 1304 3023. IBM Tokyo Research Laboratory, simonstl.com, Skymoon Ventures, 1305 January, 2001. 1307 [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and 1308 ISO 10646." RFC 2279. Alis Technologies. January, 1998. 1310 15.2Informational References 1312 [RFC2026] S.Bradner, "The Internet Standards Process � Revision 3." 1313 RFC 2026, BCP 9. Harvard, October, 1996. 1315 16 AUTHORS' ADDRESSES 1317 Geoffrey Clemm 1318 Rational Software 1319 20 Maguire Road 1320 Lexington, MA 02421 1321 Email: geoffrey.clemm@rational.com 1323 Anne Hopkins 1324 Microsoft Corporation 1325 One Microsoft Way 1326 Redmond, WA 98052 1327 Email: annehop@microsoft.com 1329 Eric Sedlar 1330 Oracle Corporation 1331 500 Oracle Parkway 1332 Redwood Shores, CA 94065 1333 Email: esedlar@us.oracle.com 1335 Jim Whitehead 1336 U.C. Santa Cruz 1337 Dept. of Computer Science 1338 Baskin Engineering 1339 1156 High Street 1340 Santa Cruz, CA 95064 1341 Email: ejw@cse.ucsc.edu 1343 17 APPENDICIES 1345 17.1XML Document Type Definition 1347 1349 1350 1351 1352 1353 1355 1356 1357 1359 1361 1363 1364 1366 1368 1369 1372 1373 1374 1375 1377 1379 1381 1383 1385 1386 1390 1391 1392 1393 1394 1395 1397 1398 1399 1401 1403 1405 1406 1408 1410 1411 1414 1416 1417 1418 1420 1421 1423 1427 1429 1430 1431 1432 1433