INTERNET-DRAFT Geoffrey Clemm, Rational Software
draft-ietf-webdav-acl-03 Anne Hopkins, Microsoft
Corporation
Eric Sedlar, Oracle Corporation
Jim Whitehead, U.C. Santa Cruz
Expires May 24, 2001 November 24, 2000
WebDAV Access Control Protocol
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies a set of methods, headers, and message
bodies that define the WebDAV Access Control extensions to the
HTTP/1.1 protocol. This protocol permits a client to remotely read
and modify access control lists that instruct a server whether to
grant or deny operations upon a resource (such as HTTP method
invocations) by a given principal.
This document is a product of the Web Distributed Authoring and
Versioning (WebDAV) working group of the Internet Engineering Task
Force. Comments on this draft are welcomed, and should be addressed
to the acl@webdav.org mailing list. Other related documents can be
found at http://www.webdav.org/acl/, and
http://www.ics.uci.edu/pub/ietf/webdav/.
Clemm, Hopkins, Sedlar, Whitehead [Page 1]
INTERNET-DRAFT WebDAV ACL October 16, 2000
Table of Contents
1 INTRODUCTION ............................................3
1.1 Terms .................................................3
1.2 Notational Conventions ................................4
2 PRINCIPALS ..............................................4
3 PRIVILEGES ..............................................5
3.1 DAV:read Privilege ....................................5
3.2 DAV:write Privilege ...................................6
3.3 DAV:read-acl Privilege ................................6
3.4 DAV:write-acl Privilege ...............................6
3.5 DAV:all Privilege .....................................6
4 PRINCIPAL PROPERTIES ....................................6
4.1 DAV:is-principal ......................................6
4.2 DAV:authentication-id .................................6
5 ACCESS CONTROL PROPERTIES ...............................7
5.1 DAV:owner .............................................7
5.2 DAV:supported-privilege-set ...........................7
5.3 DAV:current-user-privilege-set ........................8
5.4 DAV:acl ...............................................8
5.4.1 ACE Principal .....................................8
5.4.2 ACE Grant and Deny ................................9
5.4.3 ACE Protection ...................................10
5.4.4 ACE Inheritance ..................................10
5.5 DAV:acl-semantics ....................................10
5.5.1 first-match Semantics ............................14
5.5.2 all-grant-before-any-deny Semantics ..............14
5.5.3 no-deny Semantics ................................14
5.6 DAV:principal-collection-set .........................10
5.7 Example: PROPFIND to retrieve access control properties11
6 ACCESS CONTROL AND EXISTING METHODS ....................14
6.1 OPTIONS ..............................................15
6.1.1 Example - OPTIONS ................................15
7 ACCESS CONTROL METHODS .................................16
7.1 ACL ..................................................16
7.1.1 ACL Preconditions ................................16
7.1.2 Example: the ACL method ..........................17
7.1.3 Example: ACL method failure ......................17
8 INTERNATIONALIZATION CONSIDERATIONS ....................18
9 SECURITY CONSIDERATIONS ................................19
10 AUTHENTICATION .......................................20
11 IANA CONSIDERATIONS ..................................20
12 INTELLECTUAL PROPERTY ................................20
13 ACKNOWLEDGEMENTS .....................................21
Clemm, Hopkins, Sedlar, Whitehead [Page 2]
INTERNET-DRAFT WebDAV ACL October 16, 2000
14 REFERENCES ...........................................21
15 AUTHORS' ADDRESSES ...................................22
16 STILL TO DO ..........................................22
1 INTRODUCTION
The goal of the WebDAV access control extensions is to provide
an interoperable mechanism for handling discretionary access
control for content in WebDAV servers. WebDAV access control
can be implemented on content repositories with security as
simple as that of a UNIX file system, as well as more
sophisticated models. The underlying principle of access
control is that who you are determines how you can access a
resource. The "who you are" is defined by a "principal"
identifier; users, client software, servers, and groups of the
previous have principal identifiers. The "how" is determined
by a single "access control list" (ACL) associated with a
resource. An ACL contains a set of "access control entries"
(ACEs), where each ACE specifies a principal and a set of
rights that are either granted or denied to that principal.
When a principal submits an operation (such as an HTTP or
WebDAV method) to a resource for execution, the server
evaluates the ACEs in the ACL to determine if the principal
has permission for that operation.
This specification has intentionally omits discussion of
authentication, as the HTTP protocol already has a number of
authentication mechanisms[RFC2617] . Some authentication
mechanism (such as HTTP Digest Authentication, which all
WebDAV compliant implementations are required to support) must
be availableto validate the identity of a principal.
In the interests of timeliness, the following set of security
mechanisms is currently viewed as out of scope of this
document:
* Access control that applies only to a particular property
on a resource, rather than the entire resource.
* Role-based security (where a role can be seen as a
dynamically defined collection of principals)
* Specification of the ways an ACL on a resource is
initialized
* Specification of an ACL that applies globally to a
method, rather than to a particular resource
1.1 Terms
This draft uses the terms defined in HTTP [RFC2616] and WebDAV
[RFC2518]. In addition, the following terms are defined:
Clemm, Hopkins, Sedlar, Whitehead [Page 3]
INTERNET-DRAFT WebDAV ACL October 16, 2000
principal
A "principal" is a distinct human or computational actor that
initiates access to network resources. In this protocol, a
principal is an HTTP resource that represents such an actor.
privilege
A "privilege" controls access to a particular set of HTTP
operations on a resource.
aggregate privilege
An "aggregate privilege " is a privilege that comprises a set
of other privileges.
access control list (acl)
An "acl " is a list of access control elements that define
access control to a particular resource.
access control element (ace)
An "ace " either grants or denies a particular set of
privileges for a particular principal.
inherited ace
An "inherited ace " is an ace that is shared from the acl of
another resource.
1.2 Notational Conventions
The augmented BNF used by this document to describe protocol
elements is described in Section 2.1 of [RFC2616]. Because
this augmented BNF uses the basic production rules provided in
Section 2.2 of [RFC2616], those rules apply to this document
as well.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in [RFC2119].
2 PRINCIPALS
A principal is an HTTP resource that represents a distinct
human or computational actor that initiates access to network
resources. On many implementations, users and groups are
represented as principals; other types of principals are also
possible. Although an implementation MAY support PROPFIND
and PROPPATCH to access and modify information about a
principal, it is not required to do so.
Clemm, Hopkins, Sedlar, Whitehead [Page 4]
INTERNET-DRAFT WebDAV ACL October 16, 2000
A principal resource may or may not be a collection. A
collection principal may only contain other principals (not
other types of resources). Servers that support aggregation
of principals (e.g. groups of users or other groups) MUST
manifest them as collection principals. The WebDAV methods
for examining and maintaining collections (e.g. DELETE,
PROPFIND) MAY be used to maintain collection principals.
Membership in a collection principal is recursive, so a
principal in a collection principal GRPA contained by
collection principal GRPB is a member of both GRPA and GRPB.
Implementations not supporting recursive membership in
principal collections can return an error if the client
attempts to bind collection principals into other collection
principals.
3 PRIVILEGES
Ability to perform a given method on a resource SHOULD be
controlled by one or more privileges. Authors of protocol
extensions that define new HTTP methods SHOULD specify which
privileges (by defining new privileges, or mapping to ones
below) are required to perform the method. A principal with
no privileges to a resource SHOULD be denied any HTTP access
to that resource.
Privileges may be aggregates of other privileges. If a
principal is granted or denied an aggregate privilege, it is
semantically equivalent to granting or denying each of the
aggregated privileges individually. For example, an
implementation may define add-member and remove-member
privileges that control the ability to add and remove an
internal member of a collection. Since these privileges
control the ability to update the state of a collection, these
privileges would be aggregated by the DAV:write privilege on a
collection, and granting the DAV:write privilege on a
collection would also grant the add-member and remove-member
privileges.
The set of privileges that apply to a particular resource may
vary with the DAV:resourcetype of the resource, as well as
between different server implementations. To promote
interoperability, however, WebDAV defines a set of well-known
privileges (e.g. DAV:read and DAV:write), which can at least
be used to classify the other privileges defined on a
particular resource.
3.1 DAV:read Privilege
The read privilege controls methods that return information
about the state of the resource, including the resource's
properties. Affected methods include GET and PROPFIND. The
read privilege does not control the OPTIONS method since the
OPTIONS method returns capabilities rather than state.
Clemm, Hopkins, Sedlar, Whitehead [Page 5]
INTERNET-DRAFT WebDAV ACL October 16, 2000
3.2 DAV:write Privilege
The write privilege controls methods that modify the state of
the resource, such as PUT and PROPPATCH. Note that state
modification is also controlled via locking (see section 5.3
of [WEBDAV]), so effective write access requires that both
write privileges and write locking requirements are satisfied.
3.3 DAV:read-acl Privilege
The DAV:read-acl privilege controls the use of PROPFIND to
retrieve the DAV:acl, and DAV:current-user-privilege-set
properties of the resource.
3.4 DAV:write-acl Privilege
The DAV:write-acl privilege controls use of the ACL method to
modify the DAV:acl property of the resource.
3.5 DAV:all Privilege
The DAV:all privilege controls all privileges on the resource.
4 PRINCIPAL PROPERTIES
Principals are manifested to clients as an HTTP resource,
identified by a URL. A principal MUST have a DAV:displayname
property. This protocol defines the following additional
properties for a principal.
4.1 DAV:is-principal
This property indicates whether this resource is a principal.
A resource MUST have a non-empty DAV:is-principal property if
and only if it is a principal resource. (Note: If we can
just add a DAV:principal element to the DAV:resourcetype
property, then we do not need a DAV:is-principal property.)
<!ELEMENT is-principal (#PCDATA)>
PCDATA value: any non-empty value ("T" is suggested)
4.2 DAV:authentication-id
A property containing the name used to authenticate this
principal (typically typed into a login prompt/dialog).
<!ELEMENT authentication-id (#PCDATA)>
PCDATA value: any string
Clemm, Hopkins, Sedlar, Whitehead [Page 6]
INTERNET-DRAFT WebDAV ACL October 16, 2000
5 ACCESS CONTROL PROPERTIES
This specification defines a number of new properties for
WebDAV resources. Access control properties may be retrieved
just like other WebDAV properties, using the PROPFIND method.
Some access control properties (such as DAV:owner) MAY be
updated with the PROPPATCH method.
HTTP resources that support the WebDAV Access Control Protocol
MUST contain the following properties:
5.1 DAV:owner
This property identifies a particular principal as being the
"owner" of the resource.
<!ELEMENT owner (href prop?)>
<!ELEMENT prop (see [RFC2518], section 12.11)>
An implementation MAY include a list of selected properties of
that principal resource. Which properties (if any) are
included is implementation defined. An implementation MAY
allow the use of PROPPATCH to update the DAV:owner field.
5.2 DAV:supported-privilege-set
This is a read-only property that identifies the privileges
defined for the resource.
<!ELEMENT supported-privilege-set (supported-privilege*)>
Each privilege appears as an XML element, where aggregate
privileges list as sub-elements all of the privileges that
they aggregate.
<!ELEMENT supported-privilege
(privilege, abstract?, description, supported-privilege*)>
<!ELEMENT privilege ANY>
An abstract privilege is used to classify the non-abstract
privilege elements. An abstract privilege of a resource MUST
NOT be used in an ACE for that resource. Servers MUST fail an
attempt to set an abstract privilege.
<!ELEMENT abstract EMPTY>
A description is a human-readable description of what this
privilege controls access to.
<!ELEMENT description #PCDATA>
It is envisioned that a WebDAV ACL-aware administrative client
would list the supported privileges in a dialog box, and allow
the user to choose non-abstract privileges to apply in an ACE.
The privileges tree is useful programmatically to map well-
Clemm, Hopkins, Sedlar, Whitehead [Page 7]
INTERNET-DRAFT WebDAV ACL October 16, 2000
known privileges (defined by WebDAV or other standards groups)
into privileges that are supported by any particular server
implementation. The privilege tree also serves to hide
complexity in implementations allowing large number of
privileges to be defined by displaying aggregates to the user.
5.3 DAV:current-user-privilege-set
This is a read-only property containing a list of privileges
granted to the currently authenticated HTTP user. The current
user has no access privileges to an object protected by an ACL
unless that user matches one or more of the principals
specified in the ACEs.
<!ELEMENT current-user-privilege-set (privilege*)>
<!ELEMENT privilege ANY>
Each element in the DAV:current-user-privilege-set property
MUST identify a privilege from the DAV:supported-privilege-set
property.
5.4 DAV:acl
This property specifies the list of access control entries
(ACEs), which define what principals are to get what
privileges for this resource.
<!ELEMENT acl (ace*)>
Each DAV:ace element specifies the set of privileges to be
either granted or denied to a single principal. If the
DAV:acl property is empty, no principal is granted any
privilege.
<!ELEMENT ace (principal, (grant|deny), protected?,
inherited?)>
An attempt to update the DAV:acl property with a PROPPATCH
MUST fail.
5.4.1 ACE Principal
The DAV:principal element identifies the principal to which
this ACE applies.
<!ELEMENT principal ((href, prop?)
| all | authenticated | unauthenticated
| property | self)>
The current user matches DAV:href only if that user is
authenticated as being (or being a member of) the principal
identified by the URL contained by that DAV:href. An
implementation MAY include a DAV:prop element after the
DAV:href element, containing a list of selected properties of
that principal resource. Which properties (if any) are
Clemm, Hopkins, Sedlar, Whitehead [Page 8]
INTERNET-DRAFT WebDAV ACL October 16, 2000
included in the DAV:prop element is implementation defined.
The DAV:prop element is primarily intended for implementations
that do not support PROPFIND requests on the principal URL.
<!ELEMENT prop (see [RFC2518], section 12.11)>
The current user always matches DAV:all.
<!ELEMENT all EMPTY>
The current user matches DAV:authenticated only if
authenticated.
<!ELEMENT authenticated EMPTY>
The current user matches DAV:unauthenticated only if not
authenticated.
<!ELEMENT unauthenticated EMPTY>
DAV:all is the union of DAV:authenticated, and
DAV:unauthenticated. For a given request, the user matches
either DAV:authenticated, or DAV:unauthenticated, but not
both.
The current user matches a DAV:property principal in a DAV:acl
property of a resource only if the identified property of that
resource contains a DAV:href that identifies a principal, and
the current user is authenticated as being (or being a member
of) that principal. For example, if the DAV:property element
contained <DAV:owner/>, the current user would match the
DAV:property principal only if the current user is
authenticated as matching the principal identified by the
DAV:owner property of the resource.
<!ELEMENT property ANY>
The current user matches DAV:self in a DAV:acl property of the
resource only if that resource is a principal object and the
current user is authenticated as being that principal.
<!ELEMENT self EMPTY>
5.4.2 ACE Grant and Deny
Each DAV:grant or DAV:deny element specifies the set of
privileges to be either granted or denied to the specified
principal. A DAV:grant or DAV:deny element of the DAV:acl of
a resource MUST only contain elements specified in the
DAV:supported-privilege-set of that resource.
<!ELEMENT grant (privilege+)>
<!ELEMENT deny (privilege+)>
<!ELEMENT privilege ANY>
Clemm, Hopkins, Sedlar, Whitehead [Page 9]
INTERNET-DRAFT WebDAV ACL October 16, 2000
5.4.3 ACE Protection
If an ACE contains a DAV:protected element, an ACL request
without that ACE MUST fail.
<!ELEMENT protected EMPTY>
5.4.4 ACE Inheritance
The presence of a DAV:inherited element indicates that this
ACE is inherited from another resource that is identified by
the URL contained in a DAV:href element. An inherited ACE
cannot be modified directly, but instead the ACL on the
resource from which it is inherited must be modified.
Note that ACE inheritance is not the same as ACL
initialization. ACL initialization defines the ACL that a
newly created resource will use (if not specified). ACE
inheritance refers to an ACE that is logically shared - where
an update to the resource containing an ACE will affect the
ACE of each resource that inherits that ACE. The method by
which ACLs are initialized or by which ACEs are inherited is
not defined by this document.
<!ELEMENT inherited (href)>
5.5 DAV:acl-semantics
This is a read-only property that defines the ACL semantics.
These semantics define how multiple ACEs that match the
current user are combined, what are the constraints on how
ACEs can be ordered, and which principals must have an ACE.
Since it is not practical to require all implementations to
use the same ACL semantics, the DAV:acl-semantics property is
used to identify the ACL semantics for a particular resource.
The DAV:acl-semantics element is defined in section 6.
5.6 DAV:principal-collection-set
Often a versioning implementation constrains where a principal
can be located in the URL space. The DAV:principal-
collection-set enumerates which collections may contain
principals.
<!ELEMENT principal-collection-set (href*)>
Since different servers can control different parts of the URL
namespace, different resources on the same host MAY have
different DAV:principal-collection-set values . The
collections specified in the DAV:principal-collection-set MAY
be located on different hosts from the resource.
Clemm, Hopkins, Sedlar, Whitehead [Page 10]
INTERNET-DRAFT WebDAV ACL October 16, 2000
5.7 Example: PROPFIND to retrieve access control properties
The following example shows how access control information can
be retrieved by using the PROPFIND method to fetch the values
of the DAV:owner, DAV:supported-privilege-set, DAV:current-
user-privilege-set, and DAV:acl properties.
>> Request <<
PROPFIND /top/container/ HTTP/1.1
Host: www.foo.org
Content-type: text/xml; charset="utf-8"
Content-Length: xxx
Depth: 0
Authorization: Digest username="ejw",
realm="users@foo.org", nonce="...",
uri="/top/container/", response="...", opaque="..."
<?xml version="1.0" encoding="utf-8">
<D:propfind xmlns:D="DAV:">
<D:owner/>
<D:supported-privilege-set/>
<D:current-user-privilege-set/>
<D:acl/>
</D:propfind>
>> Response <<
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus
xmlns:D="DAV"
xmlns:A="http://www.acl.org/"> <D:response> <D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
<D:prop>
<D:owner>
<D:href>http://www.foo.org/users/gclemm</D:href></D:owner>
<D:supported-privilege-set>
<D:supported-privilege>
<D:privilege> <D:all/> </D:privilege>
<D:abstract/>
<D:description>Any operation</D:description>
<D:supported-privilege>
<D:privilege> </D:read> </D:privilege>
<D:description>Read any object</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege> <D:write/> </D:privilege>
<D:abstract/>
<D:description>Write any object</D:description>
<D:supported-privilege>
<D:privilege> <A:create/> </D:privilege>
Clemm, Hopkins, Sedlar, Whitehead [Page 11]
INTERNET-DRAFT WebDAV ACL October 16, 2000
<D:description>Create an object</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege> <A:update> </D:privilege>
<D:description>Update an object</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege> <A:delete> </D:privilege>
<D:description>Delete an object</D:description>
</D:supported-privilege>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege> <D:read-acl/> </D:privilege>
<D:description>Read the ACL</D:privilege>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege> <D:write-acl/> </D:privilege>
<D:description>Write the ACL</D:privilege>
</D:supported-privilege>
</D:supported-privilege>
</D:supported-privilege-set>
<D:current-user-privilege-set>
<D:privilege> <D:read/> </D:privilege>
<D:privilege> <D:read-acl/> </D:privilege>
</D:current-user-privilege-set>
<D:acl>
<D:ace>
<D:principal>
<D:href>http://www.foo.org/users/esedlar</D:href>
<D:prop>
<D:authentication-id>esedlar</D:authentication-id>
<D:displayname>Eric Sedlar</D:displayname>
</D:prop> </D:principal>
<D:grant>
<D:privilege> <D:read/> </D:privilege>
<D:privilege> <D:write/> </D:privilege>
<D:privilege> <D:read-acl/> </D:privilege></D:grant>
</D:ace>
<D:ace>
<D:principal>
<D:href>http://www.foo.org/groups/marketing/</d:href>
</D:principal>
<D:deny>
<D:privilege> <D:read/> </D:privilege> </D:deny>
<D:ace/>
<D:ace>
<D:principal>
<D:property> <D:owner/> </D:property> </D:principal>
<D:grant>
<D:privilege> <D:read-acl/> </D:privilege>
<D:privilege> <D:write-acl/> </D:privilege></D:grant>
<D:ace/>
<D:ace>
Clemm, Hopkins, Sedlar, Whitehead [Page 12]
INTERNET-DRAFT WebDAV ACL October 16, 2000
<D:principal> <D:all/> </D:principal>
<D:grant>
<D:privilege> <D:read/> </D:privilege> </D:grant>
<D:inherited>
<D:href>http://www.foo.org/top/</D:href></D:inheritied>
</D:ace> </D:acl>
</D:prop>
</D:propstat> </D:response> </D:multistatus>
The value of the DAV:owner property is a single DAV:href XML
element containing the URL of the principal that owns this
resource.
The value of the DAV:supported-privilege-set property is a
tree of supported privileges:
DAV:acl (abstract)
|
+-- DAV:read
+-- DAV:write (abstract)
|
+-- http://www.acl.org/create
+-- http://www.acl.org/update
+-- http://www.acl.org/delete
+-- DAV:read-acl
+-- DAV:write-acl
The DAV:current-user-privilege-set property contains two
privileges, DAV:read, and DAV:read-acl. This indicates that
the current authenticated user only has the ability to read
the resource, and read the DAV:acl property on the resource.
The DAV:acl property contains a set of four ACEs:
ACE #1: The principal identified by the URL
http://www.foo.org/users/esedlar is granted the DAV:read,
DAV:write, and DAV:read-acl privileges.
ACE #2: The principals identified by the URL
http://www.foo.org/groups/marketing/ are denied the DAV:read
privilege. In this example, the principal URL identifies a
group, which is represented by a collection principal.
ACE #3: In this ACE, the principal is a property principal,
specifically the DAV:owner property. When evaluating this ACE,
the value of the DAV:owner property is retrieved, and is
examined to see if it contains a DAV:href XML element. If so,
the URL within the DAV:href element is read, and identifies a
principal. In this ACE, the owner is granted DAV:read-acl, and
DAV:write-acl privileges.
ACE #4: This ACE grants the DAV:all principal (all users) the
DAV:read privilege. This ACE is inherited from the resource
Clemm, Hopkins, Sedlar, Whitehead [Page 13]
INTERNET-DRAFT WebDAV ACL October 16, 2000
http://www.foo.org/top/, the parent collection of this
resource.
6 ACL SEMANTICS
The ACL semantics define how multiple ACEs that match the
current user are combined, what are the constraints on how
ACEs can be ordered, and which principals must have an ACE.
<!ELEMENT acl-semantics ANY>
ANY value: zero or more of the ACL semantic elements
6.1 ACE Combination
The DAV:ace-combination element defines how privileges from
multiple ACEs that match the current user will be combined to
determine the access rights for that user. Multiple ACEs may
match the same user because the same principal can appear in
multiple ACEs, because multiple principals can identify the
same user, and because one principal can be a member of
another principal.
<!ELEMENT ace-combination
(first-match | all-grant-before-any-deny | no-deny)>
6.1.1 DAV:first-match ACE Combination
The ACEs are evaluated in the order in which they appear in
the ACL. If the first ACE that matches the current user does
not grant all the privileges needed for the request, the
request MUST fail.
<!ELEMENT first-match EMPTY>
6.1.2 DAV:all-grant-before-any-deny ACE Combination
The ACEs are evaluated in the order in which they appear in
the ACL. If an evaluated ACE denies a privilege needed for
the request, the request MUST fail. If all ACEs have been
evaluated without the user being granted all privileges needed
for the request, the request MUST fail.
<!ELEMENT all-grant-before-any-deny EMPTY>
6.1.3 DAV:no-deny ACE Combination
All ACEs in the ACL are evaluated. An "individual ACE" is one
whose principal identifies the current user. A "group ACE" is
one whose principal is a collection that contains a principal
that identifies the current user. A privilege is granted if
it is granted by an individual ACE and not denied by an
individual ACE, or if it is granted by a group ACE and not
denied by an individual or group ACE. A request MUST fail if
any of its needed privileges are not granted.
<!ELEMENT no-deny EMPTY>
Clemm, Hopkins, Sedlar, Whitehead [Page 14]
INTERNET-DRAFT WebDAV ACL October 16, 2000
6.2 ACE Ordering
The DAV:ace-ordering element defines a constraint on how the
ACEs can be ordered in the ACL.
6.2.1 DAV:deny-before-grant ACE Ordering
This element indicates that all deny ACEs must precede all
grant ACEs.
<!ELEMENT deny-before-grant EMPTY>
6.3 Required Principals
The required principal elements identify which principals must
have an ACE defined in the ACL.
<!ELEMENT required-principal
(href | all | authenticated | unauthenticated | property |
self)>
For example, the following element requires that the ACE
contain a DAV:owner property ACE:
<D:required-principal xmlns:D="DAV:">
<D:property> <D:owner/> </D:property>
</D:required-principal>
7 ACCESS CONTROL AND EXISTING METHODS
This section defines the impact of access control
functionality on existing methods.
7.1 OPTIONS
If the server supports access control, it MUST return "access-
control" as a field in the DAV response header from an OPTIONS
request on any resource implemented by that server.
7.1.1 Example - OPTIONS
>>REQUEST
OPTIONS /foo.html HTTP/1.1
Host: www.webdav.org
Content-Length: 0
>>RESPONSE
HTTP/1.1 200 OK
DAV: 1, 2, access-control
Clemm, Hopkins, Sedlar, Whitehead [Page 15]
INTERNET-DRAFT WebDAV ACL October 16, 2000
Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL
In this example, the OPTIONS response indicates that the
server supports access control and that /foo.html can have its
access control list modified by the ACL method.
8 ACCESS CONTROL METHODS
8.1 ACL
A DAV:acl property of a resource is modified by the ACL
method. A new DAV:acl value must be written in its entirety,
including any inherited ACEs. Unless the DAV:acl property of
the resource can be updated to be exactly the value specified
in the ACL request, the ACL request MUST fail. If a server
restricts the set of ACEs visible to the current user via the
DAV:acl property, then the ACL request would only replace the
set of ACEs visible to the current user, and would not affect
any ACE that was not visible.
In order to avoid overwriting DAV:acl changes by another
client, a client SHOULD acquire a WebDAV lock on the resource
before retrieving the DAV:acl property of a resource that it
intends on updating.
8.1.1 ACL Preconditions
An implementation MAY enforce one or more of the following
constraints on an ACL request. If the constraint is violated,
a 403 (Forbidden) response MUST be returned and the indicated
XML element MUST be returned in the response body.
<DAV:protected/>: An implementation MAY protect an ACE from
modification or deletion. For example, some implementations
implicitly grant the DAV:owner of a resource DAV:read-acl and
DAV:write-acl privileges, and this cannot be changed by a
client.
<DAV:too-many-aces/>: An implementation MAY limit the number
of ACEs in an ACL. However, ACL-compliant servers MUST
support at least one ACE granting privileges to a single
principal, and one ACE granting privileges to a collection
principal.
<DAV:non-inherited-must-precede-inherited/>: All non-inherited
ACEs MUST precede all inherited ACEs.
<DAV:deny-must-precede-grant/>: All non-inherited deny ACEs
MUST precede all non-inherited grant ACEs.
<DAV:acl-requires-lock-token/>: If a resource is locked, the
lock token MUST be specified in the ACL request.
Clemm, Hopkins, Sedlar, Whitehead [Page 16]
INTERNET-DRAFT WebDAV ACL October 16, 2000
8.1.2 Example: the ACL method
In the following example, user "fielding", authenticated by
information in the Authorization header, grants the principal
identified by the URL http://www.foo.org/users/esedlar (i.e.,
the user "esedlar") read and write privileges, grants the
owner of the resource read-acl and write-acl privileges, and
grants everyone read privileges inherited from the parent
collection http://www.foo.bar/top/.
>> Request <<
ACL /top/container HTTP/1.1
Host: www.foo.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="fielding",
realm="users@foo.org", nonce="...",
uri="/top/container/", response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:acl xmlns:D="DAV:">
<D:ace>
<D:principal>
<D:href>http://www.foo.org/users/esedlar</D:href>
</D:principal>
<D:grant>
<D:privilege> <D:read/> </D:privilege>
<D:privilege> <D:write/> </D:privilege> </D:grant>
</D:ace>
<D:ace>
<D:principal>
<D:property> <D:owner/> </D:property> </D:principal>
<D:grant>
<D:privilege> <D:read-acl/> </D:privilege>
<D:privilege> <D:write-acl/> </D:privilege> </D:grant>
<D:ace/>
<D:ace>
<D:principal> <D:all/> </D:principal>
<D:grant>
<D:privilege> <D:read/> </D:privilege></D:grant>
<D:inherited>
<D:href>http://www.foo.org/top/</D:href> </D:inherited>
</D:ace> </D:acl>
>> Response <<
HTTP/1.1 200 OK
8.1.3Example: ACL method failure
In the following request, user "fielding", authenticated by
information in the Authorization header, attempts to grant
principal identified by the URL
http://www.foo.org/users/esedlar (i.e., the user "esedlar")
read privileges, but fails because an implicit ACE has been
Clemm, Hopkins, Sedlar, Whitehead [Page 17]
INTERNET-DRAFT WebDAV ACL October 16, 2000
omitted (e.g. the ACE granting the DAV:owner DAV:read-acl and
DAV:write-acl privileges).
>> Request <<
ACL /top/container HTTP/1.1
Host: www.foo.bar
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="fielding",
realm="users@foo.org", nonce="...",
uri="/top/container/", response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:acl xmlns:D="DAV:">
<D:ace>
<D:principal>
<D:href>http://www.foo.bar/users/esedlar</D:href>
</D:principal>
<D:grant>
<D:privilege> <D:read/> </D:privilege> </D:grant>
</D:ace>
</D:acl>
>> Response <<
HTTP/1.1 403 Forbidden
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<DAV:cannot-change-implicit-ace/>
9 INTERNATIONALIZATION CONSIDERATIONS
In this specification, the only human-readable content can be
found in the DAV:authentication-id property, found on
principal resources. This property contains the name used to
authenticate a principal, typically by a user entering this
name into a password entry screen. As a result, the
authentication-id must be capable of representing names in
multiple character sets. Since DAV:authentication-id is a
WebDAV property, it is represented on-the-wire as XML [REC-
XML], and hence can leverage XML's language tagging and
character set encoding capabilities. Specifically, XML
processors must, at minimum, be able to read XML elements
encoded using the UTF-8 [UTF-8] encoding of the ISO 10646
multilingual plane. XML examples in this specification
demonstrate use of the charset parameter of the Content-Type
header, as defined in [RFC2376], as well as the XML "encoding"
attribute, which together provide charset identification
information for MIME and XML processors.
For properties other than DAV:authentication-id, it is
expected that implementations will treat the property names
and values as tokens, and convert these tokens into human-
Clemm, Hopkins, Sedlar, Whitehead [Page 18]
INTERNET-DRAFT WebDAV ACL October 16, 2000
readable text in the user's language and character set when
displayed to a person. Only a generic WebDAV property display
utility would display these values in their raw form.
For error reporting, we follow the convention of HTTP/1.1
status codes, including with each status code a short, English
description of the code (e.g., 200 (OK)). While the
possibility exists that a poorly crafted user agent would
display this message to a user, internationalized applications
will ignore this message, and display an appropriate message
in the user's language and character set.
Further internationalization considerations for this protocol
are described in the WebDAV Distributed Authoring protocol
specification [RFC2518].
10 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 specification (discussed
in [RFC2376]) should be considered in a security analysis of
this protocol.
10.1 Increased Risk of Compromised Users
In the absence of a mechanism for remotely manipulating access
control specifications, 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.
10.2 Authentication-id Property and Dictionary Attacks
Every principal has a DAV:authentication-id property defined
on it, which provides the name used to authenticate this
principal, typically the username portion of a
username/password authentication scheme. An attacker can use
the information in this property when attempting either a
brute-force, or a dictionary attack to guess the principal's
identifying password. By providing the username in
DAV:authentication-id, the scope of an attack can be reduced
to a single, valid username. Furthermore, it is possible that
principals can potentially belong to a collection. In this
Clemm, Hopkins, Sedlar, Whitehead [Page 19]
INTERNET-DRAFT WebDAV ACL October 16, 2000
case, it is possible to use the PROPFIND method to retrieve
the DAV:authentication-id property from all of the principals
in a collection, thus providing multiple usernames that can be
the focus of attack.
To reduce this risk, the DAV:authentication-id property should
not be world-readable. Which principals are granted default
read permission for DAV:authentication-id should be carefully
considered in any deployment of this protocol.
10.3 Risks of the read-acl Privilege
The ability to read the access permissions (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-writeable. Once found, this vulnerability can be
exploited by a denial of service attack in which the open
resource is repeatedly overwritten. Alternately, writeable
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
privileges for authenticated principals should be carefully
analysed when deploying this protocol.
11 AUTHENTICATION
Authentication mechanisms defined in WebDAV will also apply to
WebDAV ACL.
12 IANA CONSIDERATIONS
This document uses the namespace defined by [RFC2518] for XML
elements. All other IANA considerations mentioned in
[RFC2518] also applicable to WebDAV ACL.
13 INTELLECTUAL PROPERTY
The following notice is copied from RFC 2026, section 10.4,
and describes the position of the IETF concerning intellectual
property claims made against this document.
The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be
claimed to pertain to the implementation or use other
technology described in this document or the extent to which
any license under such rights might or might not be available;
Clemm, Hopkins, Sedlar, Whitehead [Page 20]
INTERNET-DRAFT WebDAV ACL October 16, 2000
neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11.
Copies of claims of rights made available for publication 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
Secretariat.
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 practice this standard. Please address the
information to the IETF Executive Director.
14 ACKNOWLEDGEMENTS
This protocol is the collaborative product of the WebDAV ACL
design team: Bernard Chester, Geoff Clemm (Rational), Anne
Hopkins (Microsoft), Barry Lind (Xythos), Sean Lyndersay
(Microsoft), Eric Sedlar (Oracle), Greg Stein (Apache.org),
and Jim Whitehead (UC Santa Cruz). 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 WebDAV and HTTP protocols upon which this protocol is
layered, and the invaluable feedback from the WebDAV working
group.
15 REFERENCES
15.1 Normative References
[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels." RFC 2119, BCP 14, Harvard, March, 1997.
[REC-XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen,
"Extensible Markup Language (XML)." World Wide Web Consortium
Recommendation REC-xml-19980210. http://www.w3.org/TR/REC-xml-
19980210.[RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H.
Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1." RFC 2616. U.C.Irvine, Compaq,
Xerox, Microsoft, MIT/LCS, June, 1999.
[RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S.
Lawrence, P. Leach, A. Luotonen, L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication. " RFC
2617. Northwestern University, Verisign, AbiSource, Agranat,
Microsoft, Netscape, Open Market, June, 1999.
Clemm, Hopkins, Sedlar, Whitehead [Page 21]
INTERNET-DRAFT WebDAV ACL October 16, 2000
[RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. R. Carter, D.
Jensen, "HTTP Extensions for Distributed Authoring _ WEBDAV."
RFC 2518. Microsoft, U.C.Irvine, Netscape, Novell, February,
1999.
[UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode
and ISO 10646." RFC 2279. Alis Technologies. January, 1998.
15.2 Informational References
[RFC2026] S.Bradner, "The Internet Standards Process _
Revision 3." RFC 2026, BCP 9. Harvard, October, 1996.
[RFC2396] E. Whitehead, M. Murata, "XML Media Types." RFC
2376. U.C. Irvine, Fuji Xerox Info. Systems. July, 1998. (This
RFC will soon be superseded by <draft-murata-xml-09.txt>,
which has been approved by the IESG as a Proposed Standard,
but not yet issued as an RFC.)
16 AUTHORS' ADDRESSES
Geoffrey Clemm
Rational Software
20 Maguire Road
Lexington, MA 02421
Email: geoffrey.clemm@rational.com
Anne Hopkins
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Email: annehop@microsoft.com
Eric Sedlar
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
Email: esedlar@us.oracle.com
Jim Whitehead
U.C. Santa Cruz
Dept. of Computer Science
Baskin Engineering
1156 High Street
Santa Cruz, CA 95064
Email: ejw@cse.ucsc.edu
17 STILL TO DO
* If we can add more elements to DAV:resourcetype, we can
eliminate DAV:is-principal.
Clemm, Hopkins, Sedlar, Whitehead [Page 22]
INTERNET-DRAFT WebDAV ACL October 16, 2000
* Add back the XML schema if provides info not in the DTD's.
* Consider adding a DAV:matching-principals, which identifies
all ACL principals that match the current user.
* Add DAV:ordering-constraints, DAV:required-principals, and
DAV:ace-combination-semantics as sub-elements of DAV:acl-
semantics.
Clemm, Hopkins, Sedlar, Whitehead [Page 23]
