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
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.
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
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.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
[REC-XML-INFOSET] Cowan, J. and R. Tobin, "XML Information Set
(Second Edition)", W3C REC REC-xml-infoset-
20040204, February 2004,
[REC-XML-NAMES] Bray, T., Hollander, D. and A. Layman, "Namespaces
in XML", W3C REC REC-xml-names-19990114, January
[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
[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,
<!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
<!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 (
<!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.
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.
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
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 firstname.lastname@example.org.
Funding for the RFC Editor function is currently provided by the