12. Security Considerations
Applications and users of this access control protocol should be aware of several security considerations, detailed below. In addition to the discussion in this document, the security considerations detailed in the HTTP/1.1 specification [RFC2616], the WebDAV Distributed Authoring Protocol specification [RFC2518], and the XML Media Types specification [RFC3023] should be considered in a security analysis of this protocol.12.1. Increased Risk of Compromised Users
In the absence of a mechanism for remotely manipulating access control lists, if a single user's authentication credentials are compromised, only those resources for which the user has access permission can be read, modified, moved, or deleted. With the introduction of this access control protocol, if a single compromised user has the ability to change ACLs for a broad range of other users (e.g., a super-user), the number of resources that could be altered by a single compromised user increases. This risk can be mitigated by limiting the number of people who have write-acl privileges across a broad range of resources.12.2. Risks of the DAV:read-acl and DAV:current-user-privilege-set Privileges
The ability to read the access privileges (stored in the DAV:acl property), or the privileges permitted the currently authenticated user (stored in the DAV:current-user-privilege-set property) on a resource may seem innocuous, since reading an ACL cannot possibly affect the resource's state. However, if all resources have world- readable ACLs, it is possible to perform an exhaustive search for those resources that have inadvertently left themselves in a vulnerable state, such as being world-writable. In particular, the property retrieval method PROPFIND, executed with Depth infinity on an entire hierarchy, is a very efficient way to retrieve the DAV:acl or DAV:current-user-privilege-set properties. Once found, this vulnerability can be exploited by a denial of service attack in which the open resource is repeatedly overwritten. Alternately, writable resources can be modified in undesirable ways.
To reduce this risk, read-acl privileges should not be granted to unauthenticated principals, and restrictions on read-acl and read- current-user-privilege-set privileges for authenticated principals should be carefully analyzed when deploying this protocol. Access to the current-user-privilege-set property will involve a tradeoff of usability versus security. When the current-user-privilege-set is visible, user interfaces are expected to provide enhanced information concerning permitted and restricted operations, yet this information may also indicate a vulnerability that could be exploited. Deployment of this protocol will need to evaluate this tradeoff in light of the requirements of the deployment environment.12.3. No Foreknowledge of Initial ACL
In an effort to reduce protocol complexity, this protocol specification intentionally does not address the issue of how to manage or discover the initial ACL that is placed upon a resource when it is created. The only way to discover the initial ACL is to create a new resource, then retrieve the value of the DAV:acl property. This assumes the principal creating the resource also has been granted the DAV:read-acl privilege. As a result, it is possible that a principal could create a resource, and then discover that its ACL grants privileges that are undesirable. Furthermore, this protocol makes it possible (though unlikely) that the creating principal could be unable to modify the ACL, or even delete the resource. Even when the ACL can be modified, there will be a short period of time when the resource exists with the initial ACL before its new ACL can be set. Several factors mitigate this risk. Human principals are often aware of the default access permissions in their editing environments and take this into account when writing information. Furthermore, default privilege policies are usually very conservative, limiting the privileges granted by the initial ACL.13. Authentication
Authentication mechanisms defined for use with HTTP and WebDAV also apply to this WebDAV Access Control Protocol, in particular the Basic and Digest authentication mechanisms defined in [RFC2617]. Implementation of the ACL spec requires that Basic authentication, if used, MUST only be supported over secure transport such as TLS.
14. IANA Considerations
This document uses the namespace defined by [RFC2518] for XML elements. That is, this specification uses the "DAV:" URI namespace, previously registered in the URI schemes registry. All other IANA considerations mentioned in [RFC2518] are also applicable to this specification.15. Acknowledgements
This protocol is the collaborative product of the WebDAV ACL design team: Bernard Chester, Geoff Clemm, Anne Hopkins, Barry Lind, Sean Lyndersay, Eric Sedlar, Greg Stein, and Jim Whitehead. The authors are grateful for the detailed review and comments provided by Jim Amsden, Dylan Barrell, Gino Basso, Murthy Chintalapati, Lisa Dusseault, Stefan Eissing, Tim Ellison, Yaron Goland, Dennis Hamilton, Laurie Harper, Eckehard Hermann, Ron Jacobs, Chris Knight, Remy Maucherat, Larry Masinter, Joe Orton, Peter Raymond, and Keith Wannamaker. We thank Keith Wannamaker for the initial text of the principal property search sections. Prior work on WebDAV access control protocols has been performed by Yaron Goland, Paul Leach, Lisa Dusseault, Howard Palmer, and Jon Radoff. We would like to acknowledge the foundation laid for us by the authors of the DeltaV, WebDAV and HTTP protocols upon which this protocol is layered, and the invaluable feedback from the WebDAV working group.16. References
16.1. Normative References
[REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 ((Third ed)", W3C REC REC-xml-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>. [REC-XML-INFOSET] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C REC REC-xml-infoset- 20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-infoset- 20040204/>. [REC-XML-NAMES] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C REC REC-xml-names-19990114, January 1999, <http://www.w3.org/TR/1999/REC-xml-names- 19990114>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. Whitehead, "Versioning Extensions to WebDAV", RFC 3253, March 2002. [RFC3530] Shepler, S., Ed., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M. and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629 November 2003.16.2. Informative References
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997. [UNICODE4] The Unicode Consortium, "The Unicode Standard - Version 4.0", Addison-Wesley , August 2003, <http://www.unicode.org/versions/Unicode4.0.0/>. ISBN 0321185781.
Appendix A. WebDAV XML Document Type Definition Addendum
All XML elements defined in this Document Type Definition (DTD) belong to the DAV namespace. This DTD should be viewed as an addendum to the DTD provided in [RFC2518], section 23.1. <!-- Privileges -- (Section 3)> <!ELEMENT read EMPTY> <!ELEMENT write EMPTY> <!ELEMENT write-properties EMPTY> <!ELEMENT write-content EMPTY> <!ELEMENT unlock EMPTY> <!ELEMENT read-acl EMPTY> <!ELEMENT read-current-user-privilege-set EMPTY> <!ELEMENT write-acl EMPTY> <!ELEMENT bind EMPTY> <!ELEMENT unbind EMPTY> <!ELEMENT all EMPTY> <!-- Principal Properties (Section 4) --> <!ELEMENT principal EMPTY> <!ELEMENT alternate-URI-set (href*)> <!ELEMENT principal-URL (href)> <!ELEMENT group-member-set (href*)> <!ELEMENT group-membership (href*)> <!-- Access Control Properties (Section 5) --> <!-- DAV:owner Property (Section 5.1) --> <!ELEMENT owner (href?)> <!-- DAV:group Property (Section 5.2) --> <!ELEMENT group (href?)> <!-- DAV:supported-privilege-set Property (Section 5.3) --> <!ELEMENT supported-privilege-set (supported-privilege*)> <!ELEMENT supported-privilege (privilege, abstract?, description, supported-privilege*)> <!ELEMENT privilege ANY> <!ELEMENT abstract EMPTY> <!ELEMENT description #PCDATA>
<!-- DAV:current-user-privilege-set Property (Section 5.4) --> <!ELEMENT current-user-privilege-set (privilege*)> <!-- DAV:acl Property (Section 5.5) --> <!ELEMENT acl (ace)* > <!ELEMENT ace ((principal | invert), (grant|deny), protected?, inherited?)> <!ELEMENT principal (href) | all | authenticated | unauthenticated | property | self)> <!ELEMENT all EMPTY> <!ELEMENT authenticated EMPTY> <!ELEMENT unauthenticated EMPTY> <!ELEMENT property ANY> <!ELEMENT self EMPTY> <!ELEMENT invert principal> <!ELEMENT grant (privilege+)> <!ELEMENT deny (privilege+)> <!ELEMENT privilege ANY> <!ELEMENT protected EMPTY> <!ELEMENT inherited (href)> <!-- DAV:acl-restrictions Property (Section 5.6) --> <!ELEMENT acl-restrictions (grant-only?, no-invert?, deny-before-grant?, required-principal?)> <!ELEMENT grant-only EMPTY> <!ELEMENT no-invert EMPTY> <!ELEMENT deny-before-grant EMPTY> <!ELEMENT required-principal (all? | authenticated? | unauthenticated? | self? | href* |property*)> <!-- DAV:inherited-acl-set Property (Section 5.7) --> <!ELEMENT inherited-acl-set (href*)> <!-- DAV:principal-collection-set Property (Section 5.8) -->
<!ELEMENT principal-collection-set (href*)> <!-- Access Control and Existing Methods (Section 7) --> <!ELEMENT need-privileges (resource)* > <!ELEMENT resource ( href, privilege ) <!-- ACL method preconditions (Section 8.1.1) --> <!ELEMENT no-ace-conflict EMPTY> <!ELEMENT no-protected-ace-conflict EMPTY> <!ELEMENT no-inherited-ace-conflict EMPTY> <!ELEMENT limited-number-of-aces EMPTY> <!ELEMENT grant-only EMPTY> <!ELEMENT no-invert EMPTY> <!ELEMENT deny-before-grant EMPTY> <!ELEMENT no-abstract EMPTY> <!ELEMENT not-supported-privilege EMPTY> <!ELEMENT missing-required-principal EMPTY> <!ELEMENT recognized-principal EMPTY> <!ELEMENT allowed-principal EMPTY> <!-- REPORTs (Section 9) --> <!ELEMENT acl-principal-prop-set ANY> ANY value: a sequence of one or more elements, with at most one DAV:prop element. <!ELEMENT principal-match ((principal-property | self), prop?)> <!ELEMENT principal-property ANY> ANY value: an element whose value identifies a property. The expectation is the value of the named property typically contains an href element that contains the URI of a principal <!ELEMENT self EMPTY> <!ELEMENT principal-property-search ((property-search+), prop?) > <!ELEMENT property-search (prop, match) > <!ELEMENT match #PCDATA > <!ELEMENT principal-search-property-set ( principal-search-property*) > <!ELEMENT principal-search-property (prop, description) > <!ELEMENT description #PCDATA >
Appendix B. WebDAV Method Privilege Table (Normative)
The following table of WebDAV methods (as defined in RFC 2518, 2616, and 3253) clarifies which privileges are required for access for each method. Note that the privileges listed, if denied, MUST cause access to be denied. However, given that a specific implementation MAY define an additional custom privilege to control access to existing methods, having all of the indicated privileges does not mean that access will be granted. Note that lack of the indicated privileges does not imply that access will be denied, since a particular implementation may use a sub-privilege aggregated under the indicated privilege to control access. Privileges required refer to the current resource being processed unless otherwise specified.
+---------------------------------+---------------------------------+ | METHOD | PRIVILEGES | +---------------------------------+---------------------------------+ | GET | <D:read> | | HEAD | <D:read> | | OPTIONS | <D:read> | | PUT (target exists) | <D:write-content> on target | | | resource | | PUT (no target exists) | <D:bind> on parent collection | | | of target | | PROPPATCH | <D:write-properties> | | ACL | <D:write-acl> | | PROPFIND | <D:read> (plus <D:read-acl> and | | | <D:read-current-user-privilege- | | | set> as needed) | | COPY (target exists) | <D:read>, <D:write-content> and | | | <D:write-properties> on target | | | resource | | COPY (no target exists) | <D:read>, <D:bind> on target | | | collection | | MOVE (no target exists) | <D:unbind> on source collection | | | and <D:bind> on target | | | collection | | MOVE (target exists) | As above, plus <D:unbind> on | | | the target collection | | DELETE | <D:unbind> on parent collection | | LOCK (target exists) | <D:write-content> | | LOCK (no target exists) | <D:bind> on parent collection | | MKCOL | <D:bind> on parent collection | | UNLOCK | <D:unlock> | | CHECKOUT | <D:write-properties> | | CHECKIN | <D:write-properties> | | REPORT | <D:read> (on all referenced | | | resources) | | VERSION-CONTROL | <D:write-properties> | | MERGE | <D:write-content> | | MKWORKSPACE | <D:write-content> on parent | | | collection | | BASELINE-CONTROL | <D:write-properties> and | | | <D:write-content> | | MKACTIVITY | <D:write-content> on parent | | | collection | +---------------------------------+---------------------------------+
Index
A ACL method 40 C Condition Names DAV:allowed-principal (pre) 42 DAV:deny-before-grant (pre) 41 DAV:grant-only (pre) 41 DAV:limited-number-of-aces (pre) 41 DAV:missing-required-principal (pre) 42 DAV:no-abstract (pre) 41 DAV:no-ace-conflict (pre) 41 DAV:no-inherited-ace-conflict (pre) 41 DAV:no-invert (pre) 41 DAV:no-protected-ace-conflict (pre) 41 DAV:not-supported-privilege (pre) 42 DAV:number-of-matches-within-limits (post) 48, 53 DAV:recognized-principal (pre) 42 D DAV header compliance class 'access-control' 38 DAV:acl property 23 DAV:acl-principal-prop-set report 48 DAV:acl-restrictions property 27 DAV:all privilege 13 DAV:allowed-principal precondition 42 DAV:alternate-URI-set property 14 DAV:bind privilege 12 DAV:current-user-privilege-set property 21 DAV:deny-before-grant precondition 41 DAV:grant-only precondition 41 DAV:group property 18 DAV:group-member-set property 14 DAV:group-membership property 14 DAV:inherited-acl-set property 29 DAV:limited-number-of-aces precondition 41 DAV:missing-required-principal precondition 42 DAV:no-abstract precondition 41 DAV:no-ace-conflict precondition 41 DAV:no-inherited-ace-conflict precondition 41 DAV:no-invert precondition 41 DAV:no-protected-ace-conflict precondition 41 DAV:not-supported-privilege precondition 42 DAV:number-of-matches-within-limits postcondition 48, 53 DAV:owner property 15
DAV:principal resource type 13 DAV:principal-collection-set property 30 DAV:principal-match report 50 DAV:principal-property-search 51 DAV:principal-search-property-set 56 DAV:principal-URL property 14 DAV:read privilege 10 DAV:read-acl privilege 11 DAV:read-current-user-privilege-set privilege 12 DAV:recognized-principal precondition 42 DAV:supported-privilege-set property 18 DAV:unbind privilege 12 DAV:unlock privilege 11 DAV:write privilege 10 DAV:write-acl privilege 12 DAV:write-content privilege 10 DAV:write-properties privilege 10 M Methods ACL 40 P Privileges DAV:all 13 DAV:bind 12 DAV:read 10 DAV:read-acl 11 DAV:read-current-user-privilege-set 12 DAV:unbind 12 DAV:unlock 11 DAV:write 10 DAV:write-acl 12 DAV:write-content 11 DAV:write-properties 10 Properties DAV:acl 23 DAV:acl-restrictions 27 DAV:alternate-URI-set 14 DAV:current-user-privilege-set 21 DAV:group 18 DAV:group-member-set 14 DAV:group-membership 14 DAV:inherited-acl-set 29 DAV:owner 15 DAV:principal-collection-set 30 DAV:principal-URL 14 DAV:supported-privilege-set 18
R Reports DAV:acl-principal-prop-set 47 DAV:principal-match 49 DAV:principal-property-search 51 DAV:principal-search-property-set 56 Resource Types DAV:principal 13Authors' Addresses
Geoffrey Clemm IBM 20 Maguire Road Lexington, MA 02421 EMail: geoffrey.clemm@us.ibm.com Julian F. Reschke greenbytes GmbH Salzmannstrasse 152 Muenster, NW 48159 Germany EMail: julian.reschke@greenbytes.de Eric Sedlar Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 EMail: eric.sedlar@oracle.com Jim Whitehead U.C. Santa Cruz, Dept. of Computer Science 1156 High Street Santa Cruz, CA 95064 EMail: ejw@cse.ucsc.edu
Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.