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