INTERNET-DRAFT K. Ito Xythos Expires April, 2002 October, 2001 Ticket-Based Access Control Extension to WebDAV Status of this Memo This document is an Internet-Draft and is subject to 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 draft describes an extension to the WebDAV Distributed Authoring Protocol which provides a mechanism for transferring access privileges on a DAV resource through the use of a token shared between multiple principals. This allows a principal to transfer specific privileges to others in a time or usage-limited manner. 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]. Definitions of XML elements in this document use XML element type declarations (as found in XML Document Type Declarations), described in Section 3.2 of [REC-XML]. 1. Overview Tickets are a mechanism for the transfer of specific access Ito [Page 1] Ticket-Based Access Control Extension to WebDAV Oct. 2001 privileges for a limited time or number of uses from one principal to another. Issuing a ticket on a resource provides a principal with a ticket identifier, a token which can then be distributed to other principals. A principal who presents this ticket ID transfers access privileges from the original principal to himself. This can be useful in situations where one wishes to grant access to individuals who are not easily defined within the access control scheme implemented by the server, for example, individuals who do not have accounts on the server on which the resource resides. It can also be used if a principal wishes to grant duration or usage limited access on a specific resource to other users. In any series of transactions involving tickets, there are two roles played by one or more principals. The first role is that of the principal who "issues" the ticket by sending a MKTICKET request to the server, and receives a ticket in the response. This user will be referred to as the "ticket owner". The second role is that of the principal who "uses" the ticket, by sending the ticket as a parameter in another WebDAV request to gain access to the resource. This principal will be referred to as the "ticket user". Note that it is possible for both roles to be played by the same principal, and for multiple distinct principals to play the ticket user role on the same ticket. 1.1 Transfer of access privileges Every ticket MUST define a set of permissions which it will pass from the ticket owner to the ticket user. This set of permissions acts as a mask on the resource permissions. Permissions that the ticket grants on a resource, but which the ticket owner has not been granted will not be granted to the ticket user. Similarly, permissions that the ticket owner has been granted on a resource, but which the ticket does not grant will not be granted to the ticket user. 1.2 Ticket ID Scheme The only condition imposed on ticket IDs is that the ticket ID MUST be unique on a resource at any given time. However, since the ticket ID is used as proof that a principal is in possession of the ticket, a server SHOULD select a ticket ID scheme such that it would be sufficiently difficult for an adversary in a way to guess or predict a ticket ID. 1.3 Ticket Use A ticket can be presented to the server either as a header in the request for a resource or as a parameter in the query component of the Request-URI as described in [RFC2396]. Allowing the ticket to be presented in the URI makes it possible for a ticketed resource Ito [Page 2] Ticket-Based Access Control Extension to WebDAV Oct. 2001 to be accessed using the ticket with a single HTML link. When presented in the query component, the ticket ID should be given as the value of the "ticket" parameter. When presented as a header, the ticket ID should be given as the value of the "Ticket" header. 1.4 Ticket Invalidation A ticket can be invalidated in one of three ways, any of which is sufficient to invalidate the ticket: (1) The ticket times out by existing for longer than the timeout interval determined at ticket creation, (2) the ticket is used to gain access to a resource more times than were specified at ticket creation, (3) the ticket is deleted using the DELTICKET method. In any of these three cases, the server MUST treat any further requests using the invalidated ticket as though the ticket did not exist. 1.5 Ticket Discovery In order for client to determine the tickets that have been issued on a resource, the ticketdiscovery property is provided. The ticketdiscovery property lists all active tickets, their ticket ID's, the time remaining on each ticket, the number of uses remaining on each ticket, the permissions granted by each ticket, and the ticket owner. Any resource that supports the MKTICKET method MUST support the ticketdiscovery property. As the ability to view a ticket's ID also gives the viewer the ability to use the ticket, servers SHOULD restrict the visibility of the ticketdiscovery property to principals that it has determined to have sufficient access privileges on the resource. 2. The MKTICKET Method The following describes the MKTICKET method, which is used to request a ticket on a URI. 2.1. Operation A MKTICKET request creates a ticket on the resource specified in the Request-URI. MKTICKET requests MUST have an XML request body which contains a ticketinfo XML element (see section 4 for XML tag definitions). The ticketinfo element contains subelements specifying how long the ticket is valid for, how many times the ticket may be used, and the permissions that the ticket transfers to the ticket user. The response MUST contain the value of the resource's ticketdiscovery property in a prop XML element. In order to indicate the ID associated with a newly created ticket, a Ticket response header containing the newly created ticket's ID MUST be included in the response for every successful MKTICKET Ito [Page 3] Ticket-Based Access Control Extension to WebDAV Oct. 2001 request. 2.2. Status Codes 200 (OK) - The MKTICKET request succeeded and the value of the ticketdiscovery property for this resource is included in the body. 400 (Bad Request) - The XML body was omitted or not parsable. 403 (Forbidden) - The user does not have proper access privileges on this resource. 404 (Not Found) - The resource specified could not be found. 2.3. Example - Ticket request >>Request MKTICKET /test.txt HTTP/1.1 Host: www.foo.com Content-length: xxx Content-Type: text/xml; charset="utf-8" Authorization: Basic dGVzdHVzZXI6dGVzdHVzZXI= Second-3600 1 >>Response HTTP/1.0 200 OK Ticket: A658B29924F9D39C Content-Type: text/xml; charset=UTF-8 Content-Length: xxx A658B29924F9D39C http://www.foo.com/users/testuser Second-3600 1 Ito [Page 4] Ticket-Based Access Control Extension to WebDAV Oct. 2001 This example shows the successful creation of a one-time use ticket with a lifetime of one hour on the resource http://www.foo.com/test.txt. Since the ticket was requested by the principal identified by "http://www.foo.com/users/testuser", the ticket owner is listed as such. The ticket ID, listed both in the ticketdiscovery property and the Ticket header displays the ID assigned to this ticket, in this case a random 64-bit integer expressed in hexadecimal notation. 2.4. Example - Using a ticket >>Request GET /test.txt?ticket=A658B29924F9D39C HTTP/1.1 Host: www.foo.com >>Response HTTP/1.0 200 OK Content-Type: text/plain Content-Length: xxx In this example, it is assumed that the ticket with ID A658B29924F9D39C is the ticket requested in example 2.3, and that it was valid at the time of use. It is also assumed that the principal http://www.foo.com/users/testuser who issued the ticket has read access privileges on the resource. Since the ticket grants read access, and since the ticket owner has read access on the resource, the request succeeds. 3. The DELTICKET Method The DELTICKET method is used to delete a ticket on a resource. To identify the ticket that is to be deleted, the "Ticket" header MUST be passed with the DELTICKET request. Any resource which supports the MKTICKET method must also support the DELTICKET method. 3.1. Status Codes 204 (No Content) - The DELTICKET request succeeded; the ticket specified has been deleted. 404 (Not Found) - The resource specified could not be found. 412 (Precondition Failed) - The ticket specified does not exist. 3.2. Example - Ticket deletion Ito [Page 5] Ticket-Based Access Control Extension to WebDAV Oct. 2001 >>Request DELTICKET /test.txt HTTP/1.1 Host: www.foo.com Ticket: A658B29924F9D39C >>Response HTTP/1.1 204 No Content 4. XML Element Definitions 4.1. Previously defined XML elements This draft makes use of a number of XML elements that have previously been defined in other documents. DAV:href, DAV:multistatus, DAV:prop, DAV:propfind, DAV:propstat, DAV:response and DAV:status are defined in the WebDAV Distributed Authoring Protocol [RFC2518]. DAV:owner, DAV:privilege, DAV:read, and DAV:write are defined in the WebDAV Access Control Protocol [WACP] internet draft. To avoid a dependency on that draft, the relevant definitions are reproduced in section 5 of this document. 4.2. ticketdiscovery property Name: ticketdiscovery Namespace: DAV: Purpose: Describes the tickets currently valid on a resource Description: The ticketdiscovery property returns a listing of all valid tickets on a resource. The server is free to withhold any or all of this information if the requesting principal does not have sufficient access privileges to see the data. 4.2.1. Example - Retrieving the ticketdiscovery Property >>Request PROPFIND /test.txt HTTP/1.1 Host: www.foo.com Content-type: text/xml; charset=UTF-8 Content-length: xxx Authorization: Basic dGVzdHVzZXI6dGVzdHVzZXI= Ito [Page 6] Ticket-Based Access Control Extension to WebDAV Oct. 2001 >>Response HTTP/1.0 207 MultiPart Response Content-Type: text/xml; charset=UTF-8 Content-Length: xxxx http://www.foo.com/test1.txt 9818B9E6D119A488 http://www.foo.com/users/testuser Second-941 1 6832EAD024B10C97 http://www.foo.com/users/testuser2 Second-3600 100 HTTP/1.1 200 OK The request above is for the ticketdiscovery property on the resource http://www.foo.com/test.txt. Two tickets that are active on this resource are returned. Note that there may be more tickets defined on this resource, but the requesting user may not have permission to view them. 4.3. ticketinfo XML Element Ito [Page 7] Ticket-Based Access Control Extension to WebDAV Oct. 2001 Name: ticketinfo Namespace: DAV: Purpose: Describes a single ticket Description: Contains relevant information about a ticket, including the ticket ID, the owner of the ticket, the amount of time remaining before the ticket expires, the number of visits the ticket can be used for before it expires, and the access privileges defined on the ticket. The ticketinfo element is used both in the MKTICKET request and as a child of the ticketdiscovery property in a PROPFIND request. The id and owner elements should be omitted in a MKTICKET request since the server is responsible for setting both of these properties of the ticket. 4.4. id XML Element Name: id Namespace: DAV: Purpose: Contains the ID of a ticket. See section 1.2 for recommendations on generating the ticket ID. 4.5. visits XML Element Name: visits Namespace: DAV: Purpose: Describes the number of visits that the ticket has remaining on it. Value: 1*DIGIT | "infinity" 5. Definitions From ACL Draft This draft makes use of a number of terms and XML property tags that are defined in the internet draft "WebDAV Access Control Protocol" [WACP]. To avoid making this draft dependent on [WACP], the Ito [Page 8] Ticket-Based Access Control Extension to WebDAV Oct. 2001 following definitions have been copied verbatim from that document, with portions not used in this draft omitted. 5.1 Principals A principal is a network 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. A URI of any scheme MAY be used to identify a principal resource. However, servers implementing this specification MUST expose principal resources at an http(s) URL, which is a privileged scheme that points to resources that have additional properties. So, a principal resource can have multiple URI identifiers, one of which has to be an http(s) scheme URL. Although an implementation SHOULD support PROPFIND and MAY support PROPPATCH to access and modify information about a principal, it is not required to do so. A principal resource may or may not be a collection. If a person or computational agent matches a principal resource that is contained by a collection principal, they also match the collection principal. This definition is recursive, and hence if a person or computational agent matches a collection principal that is the child of another collection principal, they also match the parent collection principal. Membership in a collection principal is also 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. Servers that support aggregation of principals (e.g. groups of users or other groups) MUST manifest them as collection principals. At minimum, principals and collection principals MUST support the OPTIONS and PROPFIND methods. 5.2 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. 5.2.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. Additionally, the read Ito [Page 9] Ticket-Based Access Control Extension to WebDAV Oct. 2001 privilege MAY control the OPTIONS method. 5.2.2 DAV:write Privilege The write privilege controls methods that modify the content, dead properties, or (in the case of a collection) membership of the resource, such as PUT and PROPPATCH. Note that state modification is also controlled via locking (see section 5.3 of [RFC2518]), so effective write access requires that both write privileges and write locking requirements are satisfied. 5.3 Access Control Properties 5.3.1 DAV:owner This protected property identifies a particular principal as being the "owner" of the resource. Since the owner of a resource often has special access control capabilities (e.g., the owner frequently has permanent DAV:write-acl privilege), clients might display the resource owner in their user interface. 6. Security Considerations By providing another means for granting access privileges on resources, tickets increase the risk of unauthorized access to the particular resources that they are issued on. Since the ticket ID is sent in both the response from the server following a MKTICKET request and in the request for a resource using the ticket, there is the risk of the ticket ID being intercepted by an attacker who can then present it to the server and use it to maliciously gain access to the resource on which the ticket is issued. However, this risk is mitigated by several factors. First, as long as the channels used to request, distribute, and use the ticket are secure, there is no added risk in using tickets. Second, since a ticket transfers a limited set of access privileges on a single resource for a limited duration and limited number of accesses, the scope of potential security violations is limited. 7. References [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396. MIT/LCS, Ito [Page 10] Ticket-Based Access Control Extension to WebDAV Oct. 2001 U.C. Irvine, Xerox, August, 1998. [RFC2026] S.Bradner, "The Internet Standards Process - Revision 3." RFC 2026, BCP 9. Harvard, October, 1996. [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. [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. [WACP] G. Clemm, A. Hopkins, E. Sedlar, J. Whitehead, "WebDAV Access Control Protocol." IETF Internet Draft draft-ietf-webdav-acl-06. http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-06.txt Rational, Microsoft, Oracle, U.C. Santa Cruz, June, 2001. 8. Author's Address Keith Ito Xythos 77 Maiden Lane, Suite 200 San Francisco, CA, USA kito@xythos.com This internet draft expires April, 2002. Ito [Page 11]