[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 3744

     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]
     

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/