idnits 2.17.1 draft-ietf-webdav-acl-reqts-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 112 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 118: '...e scenarios that SHOULD be accommodate...' RFC 2119 keyword, line 186: '... Principals MUST be uniquely iden...' RFC 2119 keyword, line 188: '... It MUST be possible to use a...' RFC 2119 keyword, line 197: '... It MUST be possible to grant...' RFC 2119 keyword, line 246: '... Users SHOULD be able to pred...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 37 has weird spacing: '...als for an ac...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9376 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2068 (ref. '2') (Obsoleted by RFC 2616) Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Lisa Lippert 2 Expires: January 1999 Microsoft Corporation 3 August 1998 5 WebDAV Access Control Goals 6 draft-ietf-webdav-acl-reqts-00.txt 8 1. Status of this Memo 10 This document is an Internet draft. Internet drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas and its working groups. Note that other groups may also 13 distribute working information as Internet drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months and can be updated, replaced or obsoleted by other 17 documents at any time. It is inappropriate to use Internet drafts 18 as reference material or to cite them as other than as "work in 19 progress". 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 Distribution of this document is unlimited. Please send comments 29 to the WWW Distributed Authoring and Versioning (WebDAV) mailing 30 list, , which may be joined by sending a 31 message with subject "subscribe" to . Discussions are archived at URL 33 http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/. 35 2. Abstract 37 This document defines goals for an access control system for use 38 with the WebDAV protocol. 40 Access control systems grant or deny rights (such as "read" or 41 "write") to specified principals for individual resources. 43 3. Contents 45 1. Status of this Memo........................................1 46 2. Abstract...................................................1 47 3. Contents...................................................2 48 4. Introduction...............................................3 49 4.1. Problem to be solved..................................3 50 5. Definitions................................................3 51 5.1. Access Control List and Entries.......................3 52 5.2. Principal.............................................3 53 5.3. Scenarios.............................................3 54 5.3.1. Different authors on each document................3 55 5.3.2. Denying to member of a group......................3 56 5.3.3. Delegation........................................4 57 5.4. Interoperability......................................4 58 6. Goals......................................................4 59 6.1. Functionality.........................................4 60 6.2. Specifying principals.................................4 61 6.3. Rights................................................5 62 6.4. Granularity of Objects................................5 63 6.5. Evaluating rights.....................................5 64 6.6. Discovery.............................................5 65 6.7. Security..............................................5 66 7. Recommendations............................................5 67 7.1. Functionality goals...................................5 68 7.2. Achieving predictability..............................6 69 7.2.1. Evaluation Rules..................................6 70 7.2.2. Inheritance.......................................6 71 7.2.3. Ownership.........................................6 72 8. Areas Out of Scope.........................................6 73 8.1. Roles.................................................6 74 9. SECURITY CONSIDERATIONS....................................7 75 10. REFERENCES.................................................8 76 11. Authors' Addresses.........................................8 78 4. Introduction 80 4.1. Problem to be solved 82 In distributed authoring scenarios resources may be accessible by 83 multiple principals. To control how these principals can access 84 and alter a resource a system of access controls is needed. These 85 controls define what actions a particular principals is allowed 86 to exercise on a particular resource. 88 There does not currently exist a mechanism for DAV to be used to 89 grant and deny such access rights. This document outlines the 90 goals for such a method. 92 5. Definitions 94 Most terminology in this document is used in the same way as in 95 the WebDAV specification [1]. 97 5.1. Access Control List and Entries 99 An Access Control List (ACL) usually refers to a collection of 100 Access Control Entries (ACE). Each entry applies to one or more 101 principals and (usually) one object and/or its children. Each 102 entry grants or denies one or more rights to the specified 103 principals on that object. While this is a common model, it is 104 applied differently in various existing stores (see 5.4). 106 It is not required that the DAV access control draft use the 107 model of ACL as defined by existing stores. This draft refers to 108 ACLs and ACEs because many systems use them, and in order to 109 provide examples for some recommendations and goals. 111 5.2. Principal 113 A principal is a user or group of users to whom specific access 114 rights can be granted or denied. 116 5.3. Scenarios 118 These are scenarios that SHOULD be accommodated by an access 119 control mechanism for DAV. These are all possible multi-author 120 and distributed-author scenarios. These scenarios were used to 121 build the goals list. 123 5.3.1. Different authors on each document 125 Jim owns a directory of documents which must be edited by a 126 variety of different people, in fact a different set of people 127 for each document. He must be able to set access permissions 128 individually for each document, so that only the correct editors 129 have write access to each document. 131 5.3.2. Denying to member of a group 132 Lisa administers a bunch of files which can all be read by 133 members of a group. However, one of them contains details about 134 a surprise party for Josh. Lisa must be able to set the 135 permissions on that document such that even though the group is 136 allowed access to the document, Josh cannot read the document. 137 This scenario is best served if new members can be added to the 138 group and be able to read the document automatically. 140 5.3.3. Delegation 142 Jim wishes to delegate some administration of his directory to 143 Rohit. First, Jim must be able to allow Rohit to read ACLs and 144 write resources without being able to write ACLs on those 145 resources. Second, when Rohit is more trusted, Jim must be able 146 to allow Rohit to edit the ACLs on the directory and on all 147 resources in the directory, without giving Rohit the ability to 148 take over entirely from Jim by removing all permissions from Jim. 150 5.4. Interoperability 152 DAV implementations will in some cases be built on top of 153 existing access control implementations, e.g. file systems. Many 154 access permission features can be built on top of the underlying 155 store, however DAV access permissions will be more secure if the 156 store's access permission functionality is used. 158 Some common features of file systems with access control: 160 - Associate each combination of a resource, a principal and a 161 right with a "yes/no" decision whether the principal gets the 162 right on the resource 163 - Offer read, write and execute access to files 164 - Principals include concept of "all users" 165 - Some have more detailed rights such as "set owner", "set ACL", 166 "synchronize" 167 - May offer a different set of rights on directories (as opposed 168 to files) 169 - May allow access to be denied as well as granted 170 - Groups can be principals as well as users 171 - May have an "owner" for resources (the owner can have read or 172 write permission removed, but can never be denied permission to 173 take over the resource, set ACLs and restore permissions). 174 - Has rules for either avoiding conflicting access entries or 175 evaluating access entries in some consistent way to resolve 176 conflict 177 - May have inheritance rules 179 6. Goals 180 6.1. Functionality 182 Principals with the appropriate rights must be able to read and 183 set access control information. 185 6.2. Specifying principals 186 Principals MUST be uniquely identifiable. 188 It MUST be possible to use a the octet strings which are defined 189 by HTTP 1.1 [2] to identify a principal. 191 It must also be possible to specify special types of principals, 192 in particular all authorized principals, all anonymous 193 principals, and all principals. 195 6.3. Rights 197 It MUST be possible to grant or deny the following rights to any 198 principal 200 - to alter the body of a resource 201 - to alter the properties of a resource 202 - to delete a resource 203 - to add a child to a collection 204 - to read the ACL on a resource or collection 205 - to change the ACL on a resource or collection 206 - to delete a child from a collection 207 - to list the contents of a collection 209 6.4. Granularity of Objects 211 It must be possible to set ACLs individually on both collections 212 and resources. 214 6.5. Evaluating rights 216 The protocol draft must provide an algorithm by which conflicts 217 between rights, both granted and denied, for a particular 218 principal on a particular resource are unambiguously settled. 220 6.6. Discovery 222 The protocol draft must specify how clients discover what rights 223 are available on a resource as well as what rights have been 224 assigned to which principals for a particular resource. Discovery 225 is itself subject to access control. 227 6.7. Security 229 It should be acceptable to deny unprotected transactions. 231 7. Recommendations 233 7.1. Functionality goals 235 It is recommended that users be able to add access control 236 information to an object without having to reset all access 237 control settings. This is recommended because certain systems or 238 implementations may allow a user to add certain kinds of access 239 rights but not others (i.e. grant "read" but not grant "delete"). 241 Similarly, it should be possible for users to be able to remove, 242 delete or clear access rights without having to reset all rights. 244 7.2. Achieving predictability 246 Users SHOULD be able to predict what rights another user has, 247 based on looking at the DAV access rights granted and denied. 248 This may be impossible if another user has access to the resource 249 without using DAV, in which case other access control mechanisms 250 may apply. The underlying implementation may have advanced 251 access control which is more restrictive than the DAV access 252 control. 254 There are several issues which much be dealt with carefully in 255 order to maintain as much predictability as possible. 257 7.2.1. Evaluation Rules 259 Precise evaluation rules, with no ambiguity, are needed to 260 achieve predictability. 262 7.2.2. Inheritance 264 If the underlying system uses inheritance, then users of the DAV 265 access control mechanism should still be able to predict its 266 behavior. This could be achieved if the type of inheritance is 267 discoverable, or if the type(s) of inheritance is/are specified 268 by the DAV access control protocol draft. 270 7.2.3. Ownership 272 Systems in which resources have owners also must be treated with 273 care. Predictability can be achieved on systems with owners by 274 including owner functionality in DAV access control. Systems 275 which do not support owner functionality could refuse requests to 276 change or set ownership. 278 There may be other ways to preserve predictability with 279 inheritance and ownership. 281 8. Areas Out of Scope 282 8.1. Groups 284 Modeling groups is out of scope. There is currently no concept 285 of groups to deal with in HTTP [2] or DAV. The protocol draft 286 MAY support specifying (naming) groups which already exist on a 287 given underlying system. It is recommended that the protocol 288 draft avoid issues such as the enumeration of group members or 289 administration of groups. 291 8.2. Roles 293 Those with experience building complex document management or 294 workflow systems on top of stores with simple ACLs know how hard 295 it is to define roles for individuals. For example, the document 296 management system can map the role "author" to grant the rights 297 read/write/delete, but it is more difficult to go the other way. 298 Is an individual with read/write/delete permissions an author, an 299 editor, or somebody with no role and just a list of rights? Many 300 systems employ the concept of assigning roles, more temporary 301 than identities, to more flexibly define access. 303 Roles are important. However, roles would appear to be difficult 304 and not necessarily related to ACLs. The protocol draft MAY 305 define how roles may be assigned. 307 8.3. Certificate-based security 309 Certificates are out of scope for the DAV ACL protocol. 311 8.4. Time-based access control 313 Time-based access control is out of scope for the DAV ACL 314 protocol. 316 9. SECURITY CONSIDERATIONS 318 This document is intended to specify how security can be enhanced 319 in WebDAV systems. Many security considerations have already 320 been discussed in [1]. 322 Authentication mechanisms, which will be used by DAV ACL 323 implementations to identify principals, are defined elsewhere for 324 HTTP 1.1 [2]. The same goals for security identified in [1], 325 such as not using the HTTP Basic authentication scheme, apply 326 even more strongly when access control functionality is 327 considered. 329 Inappropriate implementations or use of access control 330 functionality can make a system less secure in these ways: 332 - by potentially allowing non-administrators to change the 333 access settings for items on a server, 335 - by providing a way for access control information to be read 336 and set (may be snooped), and potentially snooped, hackers may 337 find it easier to discover names of accounts to use in attacks. 339 The "Security" goals section (6.7) includes some goals to 340 counterbalance these insecurities. Also, the ability to specify 341 who has access rights to read and to change the rights themselves 342 (section 6.3) lessens the chance of hackers being able to learn 343 access information or set access levels. 345 Access control functionality also improves security, by giving 346 resource owners much more control and flexibility over who can 347 access their resources in what way. 349 10. REFERENCES 351 [1] Y. Goland, J. Whitehead, A. Faizi, S. Carter, D. Jensen, 353 "Extensions for Distributed Authoring on the World Wide Web", 354 , April 1998. 356 [2] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 357 "Hypertext Transfer Protocol -- HTTP/1.1." RFC 2068. U.C. Irvine, 358 DEC, MIT/LCS. January, 1997. 360 H. Palmer, "Requirements for Access Control within Distributed 361 Authoring and Versioning Environments on the World Wide Web", 362 , November 1997 364 P. J. Leach, Y. Y. Goland, "WebDAV ACL Protocol", November 1997 367 M. Satyanarayanan, "Integrating Security in a Large Distributed 368 System", ACM transactions on computer systems 7(3), August 1989. 370 11. Authors' Addresses 372 Lisa Lippert 373 Microsoft Corporation 374 One Microsoft Way 375 Redmond, WA 98052 376 EMail: lisadu@microsoft.com 378 Expires January 1999