idnits 2.17.1 draft-ietf-webdav-acreq-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 17, 1998) is 9474 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) == Missing Reference: 'WebDAV1' is mentioned on line 61, but not defined ** Obsolete normative reference: RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. 'IDC' == Outdated reference: A later version (-10) exists of draft-ietf-webdav-protocol-04 -- Unexpected draft version: The latest known version of draft-ietf-webdav-requirements is -02, but you're referring to -03. ** Downref: Normative reference to an Informational draft: draft-ietf-webdav-requirements (ref. 'WEBDAV2') Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 WEBDAV Working Group H. Palmer, Netscape 2 INTERNET-DRAFT November 17, 1997 3 5 Expires May 17, 1998 7 Requirements for Access Control within Distributed Authoring 8 and Versioning Environments on the World Wide Web 10 Status of this Memo 12 This document is an Internet draft. Internet drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas and 14 its working groups. Note that other groups may also distribute working 15 information as Internet drafts. 17 Internet Drafts are draft documents valid for a maximum of six months 18 and can be updated, replaced or obsoleted by other documents at any 19 time. It is inappropriate to use Internet drafts as reference material 20 or to cite them as other than as "work in progress". 22 To learn the current status of any Internet draft please check the 23 "lid-abstracts.txt" listing contained in the Internet drafts shadow 24 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East coast) or 26 ftp.isi.edu (US West coast). Further information about the IETF can be 27 found at URL: http://www.ietf.org/ 29 Distribution of this document is unlimited. Please send comments to the 30 WWW Distributed Authoring and Versioning (WebDAV) mailing list, 31 , which may be joined by sending a message with 32 subject "subscribe" to . Discussions are 33 archived at URL: 35 http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/. 37 Abstract 39 To provide a robust model for modifying documents and data within a 40 distributed World Wide Web authoring environment, it is necessary to 41 furnish a methodology which controls access to objects. Access control 42 may include the ability to read an object, modify an object, or perform 43 other more advanced functions upon an object. Access control is 44 necessary to prevent unauthorized access or modification of objects 45 within the authoring environment which could lead to unintended loss, 46 damage or disclosure of data. 48 This document proposes requirements for the support of access control 49 within a Web Distributed Authoring and Versioning (WebDAV) environment. 50 It describes a model for the representation and interpretation of access 51 control policies, and a set of operations needed to manage policies in 52 that form. It is intended that these requirements be supported within 53 the framework of the proposed WebDAV extensions [WEBDAV1] to HTTP 54 [HTTP], in the form of additional protocol operations and compliance 55 requirements for clients and servers 56 1. Introduction 58 This document proposes WebDAV functionality to support access control in 59 a Distributed Authoring and Versioning (DAV) environment, as defined by 60 other specifications produced by the IETF WWW Distributed Authoring and 61 Versioning working group [WebDAV1,WEBDAV2]. Specifically, this 62 functionality would enable a Distributed Authoring Tool to discover 63 access control policies associated with a given resource, to present 64 those policies in a human-readable form to an end-user, and to set or 65 modify such policies, as directed by an authorized user. 67 Although access control policies generally can be formulated in many 68 ways, it is necessary to define a particular framework within which to 69 discuss specific requirements for the expression and application of 70 access control policy information. This document proposes such a 71 framework, and then uses it to describe the requirements for DAV 72 protocol support for the management of access control. 74 2. Rationale 76 The IDC report, "The Intranet's Many Faces" [IDC] points to "Central 77 Administration of user access rights and restrictions" as an essential 78 benefit of Web-based technology. Unfortunately, this fundamental 79 requirement has not been standardized. Existing Web Server and 80 Authoring Tool implementations do not have an interoperable mechanism 81 for assigning access control information to a particular resource or 82 requesting access control information about a particular resource. 84 Access control mechanisms in existing Web Servers, such the "htaccess" 85 mechanism support in NCSA and Apache servers, suggest that Web-based 86 access control requires a level of flexibility that is not common in the 87 access control mechanisms of native operating systems. For example, 88 Web-based access control often supports access control policies based on 89 the client's IP address or DNS name. When user authentication is 90 desired, Web-based access control allows the requirement for 91 authentication to be placed selectively on particular resources or 92 collections of resources, and sometimes supports a choice of user 93 authentication mechanisms. 95 Users who authenticate through Web-based user authentication may or may 96 not have user accounts on the native operating system on which the Web 97 Server runs. In some cases, even when a user does have a native 98 operating system account, it is not used. For example, the native 99 operating system identity associated with the Web Server itself may not 100 enable it to assume the identity of other users for purposes of 101 accessing the native file system. In other cases, native operating 102 system accounts are not created for Web Server users, with the intent to 103 restrict these users to accessing the system only through the Web 104 Server. 106 In spite of the flexibility often provided in formulating Web-based 107 access control policies, mechanisms for viewing and setting access 108 controls from Web clients have been limited to proprietary solutions. 109 In order to realize a standard mechanism for supporting these operations 110 within the framework of the proposed HTTP standard for distributed 111 authoring, there must be a protocol for conveying access control policy 112 information between client and server, and for executing operations to 113 view and set this information. 115 3. Terminology 117 Where there is overlap, usage is intended to be consistent with that in 118 the WebDAV requirements specification [WEBDAV2]. 120 ACE 121 An Access Control Entry. This is the smallest unit of access 122 control policy. It grants or denies a given set of access 123 rights to a set of principals. An ACE is a component of an ACL, 124 which is associated with a resource. 126 ACL 127 An Access Control List. This contains all of the access control 128 policies which are directly associated with a particular 129 resource. These policies are expressed as ACEs. 131 Client 132 A program which issues HTTP requests and accepts responses. 134 Collection 135 A collection is a resource that contains other resources, either 136 directly or by reference. 138 Distributed Authoring Tool 139 A program which can retrieve a source entity via HTTP, allow 140 editing of this entity, and then save/publish this entity to a 141 server using HTTP. 143 Entity 144 The information transferred in a request or response. 146 Hierarchical Collection 147 A hierarchical organization of resources. A hierarchical 148 collection is a resource that contains other resources, 149 including collections, either directly or by reference. 151 Principal 152 A loosely-defined term which is normally used to refer to a user 153 identity that has been associated with a user agent as a result 154 of some unspecified authentication protocol exchange between a 155 server and the user agent. 157 Principal Attribute 158 A characteristic of a user agent, or of a request to a server 159 made by a user agent, which has a particular value that can be 160 determined by the server at the time of such a request. In this 161 context, a principal attribute is assumed to be significant in 162 the formulation of access control policy on the server. 164 Principal Description 165 A description of a set of principal identities, formulated in 166 terms of assertions about the values of the principal 167 attributes. A given principal identity will match a given 168 principal description, or not, depending on whether the 169 principal attribute assertions in the principal description 170 evaluate to "true" or "false" with respect to the principal 171 attribute values of the principal identity, and also depending 172 on how the Boolean results of such evaluations are logically 173 combined in the principal description. 175 Principal Identity 176 A specific set of corresponding values for a given set of 177 principal attributes. A server determines these values at the 178 time of an access, and a unique set of values defines a unique 179 principal identity for purposes of access control. 181 Property 182 Named descriptive information about a resource. 184 Resource 185 A network data object or service that can be identified by a 186 URI. 188 Server 189 A program which receives and responds to HTTP requests. 191 User Agent 192 The client that initiates a request. 194 4. Access Control Framework 196 This section proposes a conceptual framework to serve as a context for 197 describing the operation of access control provisions of the WebDAV 198 protocol. The main focus of this model are the abstractions used to 199 describe access control policies, as the main protocol requirement is to 200 convey access control policy specifications in a form that is meaningful 201 to compliant clients and servers. The meaning of an access control 202 policy specification is defined by how a server interprets it in 203 determining whether to grant or deny a particular request. The model 204 also describes how resources and access control policies are related. 206 4.1. Access Rights 208 Access rights are names for types of access to resources. A given 209 request to a server may require access to one or more resources, and 210 potentially different types of access to different resources. For 211 example, a server-based "copy" operation would require "read" access to 212 the resource being copied, and "modify" access to the collection in 213 which the copy will be created. Access rights may be categorized as 214 generic, that is, those which apply to most or all types of resources, 215 or specialized, that is, those which apply to a particular type of 216 resource. For example, generic access rights might include "read", 217 "modify", and "delete". For a hypothetical type of resource that 218 represents a bank account, specialized access rights, such as "deposit" 219 and "withdraw", might be defined. 221 This specification defines a set of generic access rights that must be 222 implemented by compliant clients and servers. WebDAV protocol 223 specifications should include descriptions of which generic rights are 224 required to which resources for each defined operation that may be 225 requested of a server. The server evaluates the access control policies 226 associated with referenced resources in order to determine whether the 227 necessary access rights are granted or denied for a given access. 229 4.2. Principals 231 The term, "principal", is often used in security-related discussions to 232 refer to the identity of an entity involved in some communication. It 233 can refer to a person, a program acting as an agent for a person, or a 234 program with its own associated identity. It usually seems to abstract 235 the notion of "who". 237 In this context, we will normally use the term "principal identity" to 238 express a related concept. Specifically, each access to a server has an 239 associated principal identity, which is usually associated with the user 240 agent, and which may require the user agent to provide the server with 241 some kind of authentication credentials. However, unlike the normal 242 usage of "principal", we use "principal identity" to refer to a set of 243 attributes and associated values. There may be various mechanisms 244 through which a server obtains values for these attributes. For 245 example, a user identity attribute may be obtained through some 246 authentication protocol, or an IP address of the client may be obtained 247 from the server's connection state for the client, or some other 248 attribute may be obtained from an HTTP header. That is, a principal 249 identity abstracts not only "who" the client represents, but also other 250 conditions that may exist at the time of an access, that is, conditions 251 which are considered relevant to access control policy. 253 Exactly what is relevant to access control policy is expressed in terms 254 of "principal attributes". Each principal attribute has a name that 255 refers to a particular type of relevant information. For example, a 256 principal attribute, "IP", might refer to the IP address of the user 257 agent, or "user" might refer to an authenticated user name. 259 In some cases, the value of one principal attribute may be derived from 260 the value of another. For example, the value of a principal attribute, 261 "DNS", representing the DNS name of the user agent, might be determined 262 via a reverse DNS lookup, using the value of the "IP" attribute. 263 Similarly, the value of a principal attribute, "group", might be 264 determined by using the value of the "user" attribute to access a 265 database which defines the groups to which users belong. 267 A set of principal identities is described by a "principal description". 268 The simplest form of a principal description would assert that a 269 particular principal attribute must have a certain specified value, 270 e.g.: 272 isEqual("user", "fred") 274 More complex principal descriptions may involve several principal 275 attributes, with more sophisticated assertions about the values of these 276 attributes, combined in a logical expression, e.g.: 278 OR(isMatch("DNS", "*.foo.com"), 279 AND(isEqual("user", "fred"), isMatch("DNS", "*.bar.com"))) 281 [Note that the syntax used here to represent principal descriptions is 282 intended only to demonstrate the desired level of expressive capability, 283 and nothing more.] 285 This specification defines a set of principal attributes, types of 286 principal attribute assertions, and the mechanisms for combining 287 principal attribute assertions to form principal descriptions. 289 4.3. Access Control Entry (ACE) 291 An Access Control Entry is the most fundamental unit of access control 292 policy. An ACE contains a list of access rights, a principal 293 description, and an indication of whether the specified access rights 294 are to be granted or denied for principal identities which match the 295 principal description. An ACE has no applicability to principal 296 identities which do not match its principal description. 298 4.4. Access Control List (ACL) 300 An Access Control List is an ordered list of ACEs which are directly 301 associated with a given resource. When policies expressed by the ACEs 302 in a given ACL are in conflict, the policies expressed by ACEs nearer 303 the beginning of the list have precedence. Conflicts can easily arise 304 when some principal descriptions are very specific, and others more 305 general. For example, a principal description that matches a certain 306 user name, and a principal description that matches a certain group name 307 may both apply to that user name. In this case, one would expect the 308 ACE for the user to be placed before the ACE for the group, on the 309 assumption that the policy expressed by the user ACE is an exception to 310 the policy expressed by the group ACE. 312 The relative specificity of ACEs may not always be well-defined, 313 depending on the principal attributes being used in their principal 314 descriptions. Even if some precedence were assigned to each principal 315 attribute, the precedence of a principal description involving several 316 attributes would be problematic to compute at best. Precedence based on 317 simple ordering of the ACEs in an ACL is more intuitive, and thus is 318 less likely to lead to erroneous policies. 320 Given that ACEs are ordered within an ACL, they are evaluated in that 321 order. Evaluation stops either when all requested access rights have 322 been granted by one or more ACEs, or when any one of the requested 323 access rights has been denied by one of the ACEs. ACEs containing 324 principal descriptions that do not match the current principal identity 325 have no effect on the outcome of the evaluation. 327 4.5. Inheritance 329 An ACL which is directly associated with a collection resource may also 330 apply to the member resources of the collection, in various ways. The 331 ACL may be applied only when a new member resource is created in the 332 collection, not to control the operation of resource creation, but to 333 assign an initial ACL to the new resource. This will be known as 334 "static inheritance". Alternatively, a collection ACL may apply on 335 every access to a member resource, supplementing any ACL associated 336 directly with the member resource, in specifying access control policies 337 for the resource. We will refer to this as "dynamic inheritance". 339 Static and dynamic inheritance are not mutually exclusive, although if 340 both are supported, it would generally be more useful to allow a 341 collection to have one statically inherited ACL and one dynamically 342 inherited ACL, rather than a single ACL that is inherited both 343 statically and dynamically. If neither of these ACLs applies to 344 operations on the collection resource itself, there may be a third ACL 345 associated with the collection. Since this third ACL would be like an 346 ACL associated with a non-collection resource, it will be known as a 347 "resource ACL". So a collection may have a "static ACL" and/or a 348 "dynamic ACL", and all resources, including collections, may have a 349 resource ACL. If a static or dynamic ACL is maintained separately from 350 the resource ACL, it is said to be "inherit-only". 352 Inheritance may also have the property of being recursive with respect 353 to the collection hierarchy, meaning that a member resource inherits 354 ACLs from all collections up from the collection which contains it to 355 the root of the collection hierarchy. 357 A server may also support "user-based" inheritance. That is, if the 358 server is able to associate user identities with user agents, based on 359 authentication or some other means, it may also allow an inherit-only 360 ACL to be associated with a user identity. The most useful form of 361 this, from the end-user's perspective, is an ACL that is inherited by 362 any resource created by that user, that is, a static, inherit-only ACL. 363 One could also conceive of dynamic, inherit-only ACLs being associated 364 with user identities. These might be used to restrict a user's access 365 rights to all resources, on a per user, rather than per resource basis. 367 Whether a compliant server supports inheritance (of any form) or not is 368 beyond the scope of this standard. However, there are some requirements 369 which must be met when inheritance is supported, described in the 370 sections below. 372 4.5.1. Discovery 374 It must be possible for a client to discover if a server supports 375 inheritance, and if so, what kinds of inheritance it supports. 376 Specifically, the discovery mechanism should make the distinctions in 377 the type of inheritance supported that have been described above. 379 4.5.2. Conflict Resolution 380 Just as the ACEs within an ACL may specify conflicting policies, ACLs 381 which are applied to a resource via inheritance may conflict with each 382 other or with an ACL associated directly with the resource. As the 383 potential conflict between ACEs within an ACL was resolved by specifying 384 that ACEs are ordered, potential conflict between inherited ACLs, the 385 resource ACL, and user-based ACLs is also resolved by specifying a 386 logical ordering or precedence. 388 In the case of static inheritance, the ACL for a new resource would be 389 created by copying, in order, ACEs from any user-based ACL, and then 390 from any static ACL on the collection in which the resource is created, 391 and then from any static ACL on the collection containing that 392 collection, and so on, up to the collection root. The result would be a 393 single resource ACL for the new resource. 395 The order is different for dynamic inheritance. First, any dynamic, 396 user-based ACL is evaluated, then any dynamic ACL on the collection 397 root, and so on, down to any dynamic ACL on the collection containing 398 the resource being access, and finally, any resource ACL on the resource 399 itself. 401 The reason for using a different ordering of ACLs for static and dynamic 402 inheritance is based on assumptions about who would be likely to be able 403 to modify each type ACL. For static inheritance, the resulting resource 404 ACL would probably be subject to subsequent modification by the user who 405 created the resource. The ordering for static inheritance therefore 406 attempts to reflect the most likely desires of that user. That is, it 407 assumes that static ACLs on resources lower in the collection hierarchy 408 are more likely to have been set or influenced by the user than ACLs 409 higher towards the root of the collection hierarchy. 411 For dynamic inheritance, the assumption is that dynamic ACLs at 412 different levels of the collection hierarchy may be administered by 413 different people. It is further assumed that dynamic ACLs placed higher 414 towards the root of the collection hierarchy are administered by the 415 people who have the most authority to set access control policy, and 416 therefore the ordering favors ACLs set on higher-level collections. 418 4.5.3. Distinction of Inherited ACLs 420 The protocol should include a mechanism for inherited ACLs to be 421 retrieved and set separately from resource ACLs. A compliant server 422 which supports inheritance should use these mechanisms. Servers should 423 interpret operations to retrieve and set the ACL of a resource as 424 applying only to the resource ACL on that resource, and not to any 425 inherited ACLs. 427 In general, it should be possible for a compliant client to have no 428 support for dealing with inheritance. In this case, the client would 429 have access only to resource ACLs. Nevertheless, the actual access 430 control policies in effect for the client's accesses to server resources 431 would include any policies expressed in the form of inherited ACLs. 433 4.6. Access to ACLs 435 A mechanism is required to enforce access control on the retrieval and 436 modification of ACLs themselves. Whether this mechanism and a means to 437 manage it should be within the scope of this specification is currently 438 unresolved. 440 4.7. Other Access Control 442 A compliant server may support other kinds of access control, which are 443 outside the scope of this protocol. For example, the access control 444 policy in effect when no ACLs are present or no ACEs are applicable is a 445 server implementation decision. Similarly, a server may implement other 446 mechanisms which supplement the ACL-specified policies of this 447 specification. These mechanisms may be implemented with higher or lower 448 precedence than the ACL-specified mechanism. However, to the extent 449 that such alternate mechanisms are used to exclusion of ACLs, the 450 usefulness of this protocol with respect to managing access control on 451 such a server will be diminished. 453 5. Requirements 455 This section describes the WebDAV requirements to enable a client to 456 manage access control policies on a server. 458 5.1. Discovery 460 The protocol must provide a way for a client to discover any optional or 461 extended functionality that may be implemented on a server, without 462 side-effects. Compliant servers must be able to respond meaningfully to 463 discovery operations. 465 5.1.1. Rationale 467 It is intended that the access control protocol be extensible with 468 respect to types of ACEs, principal attributes, and access rights, at 469 least. The discovery mechanism is needed so that a client and server 470 can determine what extensions both of them support. 472 5.2. Operations 474 The protocol must enable a client to perform a number of operations with 475 respect to access control policies which are stored on a server. These 476 operations are described in the sections below. 478 If inheritance is supported, then any of these operations that refer to 479 the ACL of a resource need to also specify whether the resource ACL, a 480 static, inherit-only ACL, or a dynamic, inherit-only ACL is the target. 482 5.2.1. ACL Retrieval 484 An operation to retrieve an ACL for a given resource must be supported. 485 This operation must return an ACL in such a way that the contents of the 486 individual ACEs that comprise an ACL can be interpreted by the client, 487 and in such a way that the ordering of the ACEs within the ACL can be 488 determined by client. 490 5.2.1.1. Rationale 492 Access control policies are represented in the form of ACLs, and clients 493 need to be able to retrieve them, either to present the access control 494 policies to a person, or in preparation for making a modification to 495 them. It is not necessary to be able to retrieve individual ACEs from 496 an ACL. 498 5.2.2. ACL Creation 500 An operation to create a new ACL for a given resource must be supported. 501 This operation may allow the specification of an initial list of ACEs to 502 be included in the new ACL. 504 5.2.2.1. Rationale 506 A separate operation is needed to explicitly create an ACL, because an 507 empty ACL may have different semantics than no ACL. 509 5.2.3. ACL Deletion 511 An operation to delete an ACL for a given resource must be supported. 512 The ACL and any ACEs it contains are deleted. 514 5.2.3.1. Rationale 516 A separate operation to delete an ACL is needed because empty ACLs can 517 exist. 519 5.2.4. ACE Insertion 521 An operation to insert a specified ACE into the ACL of a given resource 522 must be supported. This operation must allow the ACE to inserted at any 523 position relative to any ACEs already present in the ACL. 525 5.2.4.1. Rationale 527 An operation to insert an ACE into an ACL is needed because the access 528 control policies which apply to operations on ACLs will quite likely be 529 at a granularity that specifies for what access rights the current 530 principal identity is permitted to change access control policy. This 531 would effectively restrict the current principal to inserting or 532 deleting ACEs that contain only the access rights they are allowed to 533 modify. If the only way to modify an ACL was to rewrite the entire ACL, 534 it would be difficult to apply access control at that level of 535 granularity. 537 The order of the ACE in the ACL must be specified, because it is 538 significant in resolving conflicts between ACEs. 540 5.2.5. ACE Deletion 541 An operation to delete a specified ACE from the ACL of a given resource 542 must be supported. The ACE must be specified in a way that uniquely 543 identifies it. For example, such a specification might consist of the 544 complete contents of the ACE and its position in the ACL. This is 545 necessary to avoid deleting the wrong ACE in the case where an ACE 546 insertion operation is performed between the time a client retrieves an 547 ACL and initiates an ACE deletion operation. 549 5.2.5.1. Rationale 551 See 5.2.4.1. 553 5.2.6. Test Access 555 An operation to test the access of a specified principal identity to a 556 given resource must be supported. The operation includes a list of 557 access rights, a set of principal attributes and values, and the 558 resource for which the access rights are to be tested. The results of 559 the operation indicate, for each specified access right, whether the 560 right is granted, denied, or unspecified. If inheritance is supported, 561 the results of this operation include its effects. 563 5.3. ACE Contents 565 The contents of an ACE must include a list of access rights, a principal 566 description, and an indication of whether the rights are granted or 567 denied for matching principal identities. The protocol may provide for 568 defining additional types of ACEs. 570 5.3.1. Rationale 572 ACEs allow flexibility in describing a principal identity because this 573 has proven useful in many existing Web servers. 575 ACEs may contain multiple access rights because it is common to grant or 576 deny a multiple access rights to the same set of principal identities. 578 ACEs do not combine granting and denying because that can be achieved 579 more simply by taking advantage of ACE ordering. 581 5.4. Principal Description Semantics 583 The form in which the protocol conveys a principal description must be 584 capable of expressing arbitrary Boolean expressions involving terms in 585 the form of principal attribute assertions. The Boolean operators, AND, 586 OR, and NOT, must be supported. The arguments of these operators are 587 ordered for evaluation purposes, and only as many as necessary are 588 evaluated in order to determine the result of the operator. That is, 589 Boolean operators explicitly employ short-circuiting. 591 5.4.1. Rationale 592 Many existing Web servers enable principal attribute assertions to be 593 combined in making access control policy. Using Boolean operators 594 provides a uniform, flexible, and predictable way to combine principal 595 attribute assertions. 597 Short-circuiting of Boolean operators improves efficiency, and also 598 helps support deferred authentication. This concept, which many 599 existing servers support, is that user authentication is postponed until 600 it has been established that the access control policy which applies to 601 the current principal cannot be determined without an authenticated user 602 identity. It is a common practice to create access control policies 603 based solely on IP addresses or DNS names, and thus avoid the need for 604 user authentication. 606 5.5. Principal Attribute Assertions 608 The protocol must provide a way to represent assertions about principal 609 attributes in the context of a principal description. The types of 610 assertions that must be supported for each of the required principal 611 attributes are described below. The protocol specification should 612 define a mechanism for extending the protocol with additional types of 613 principal attribute assertions. 615 5.5.1. Equality Assertion 617 It must be possible to encode an assertion that any given principal 618 attribute is equal to a specified value. The exact interpretation of 619 what constitutes "equality" may vary with the type of principal 620 attribute involved. For example, string-valued attributes may be 621 specified to be case-sensitive or case-insensitive. 623 5.5.2. Matching Assertion 625 It must be possible to encode an assertion that any given principal 626 attribute matches a specified pattern. The format of a valid pattern 627 may vary with the type of principal attribute involved. The protocol 628 may define several different types of patterns, such as lists or regular 629 expressions. Possibly the functionality of asserting equality and of 630 asserting a match could be captured in a single mechanism. 632 5.6. Principal Attributes 634 The protocol must be able to encode attribute assertions involving the 635 principal attributes specified in the following sections. It should 636 provide a mechanism for defining additional principal attributes. 638 In all cases, it should be possible for a compliant client to present 639 attribute assertions in a form in which they can be reasonably 640 understood by a person. It should also be possible for a client to 641 encode attribute assertions in the protocol, based on input entered by a 642 person. 644 5.6.1. IP Address 645 It must be possible to express an attribute assertion using the client 646 IP address as the principal attribute. Such an assertion might involve 647 a pattern consisting of an IP address and subnet mask, a list, or a 648 regular expression. 650 5.6.1.1. Rationale 652 IP addresses are supported by many Web servers as a way to describe 653 principals for access control purposes, and this feature is widely used. 655 5.6.2. DNS Name 657 It must be possible to express an attribute assertion using the client 658 DNS name as the principal attribute. Such an assertion might involve a 659 pattern consisting of a list or a regular expression. 661 5.6.2.1. Rationale 663 DNS names are supported by many Web servers as a way to describe 664 principals for access control purposes, and this feature is widely used. 666 5.6.3. User Name 668 It must be possible to express an attribute assertion using a user name 669 as the principal attribute. It must be possible for the server to 670 interpret values or patterns which are part of such an assertion in 671 terms of authenticated user identities. 673 All compliant servers must support an encoding of a user name in a 674 simple text form that can be directly presented to, or entered by, a 675 person. The protocol may also provide for other encodings of a user 676 name that assume that the client has access to a user database or 677 directory, in which case it should also provide a mechanism to ensure 678 that a client and server are using a given such encoding in a consistent 679 manner. 681 5.6.3.1. Rationale 683 User agents may or may not have access to the Directory service (or user 684 database) used by a server, but if a server supports user 685 authentication, it always has access to some kind of Directory service, 686 or at least to an authentication authority which has such access. If a 687 client does not have access to the server's Directory service, it is 688 likely that a person would have to enter text in order to specify a user 689 identity in a principal description. All compliant servers need to be 690 able to handle such text, as literally entered by a person, as a 691 specification of a user identity. Likewise, regardless of how a user 692 identity is represented internally, a compliant server must be able to 693 send user identities in a principal description in a form suitable for 694 presentation to a person, since the client may have no way to translate 695 an opaque user identifier into such a form. 697 On the other hand, some clients and servers may share a common Directory 698 service, and should have some way to discover that. Assuming that the 699 Directory service can translate user identifiers into a form suitable 700 for human presentation, the client and server could communicate user 701 identifiers in whatever form is suitable for accessing the Directory. 702 For example, a client and server which are both LDAP-capable might 703 convey user identities in the form of LDAP Distinguished Names or LDAP 704 URLs. 706 5.7. Access Rights 708 The protocol should provide for an extensible set of access rights. In 709 particular, some resource types or operations may define access rights 710 which are specialized in applicability to those resource types or 711 operations. However, the formulation of access control policies can 712 often be simplified through the use of a generic access rights, which 713 are applicable to a broad range of resource types and operations. 714 Therefore the following sections define a required set of generic access 715 rights that must be support by compliant clients and server. 717 It is acceptable if some implementations wish to treat different access 718 rights as synonymous (e.g., a change to the right controlling "list" 719 access may simultaneously change both "list" and "read"). However, this 720 may be done only as specified in the following descriptions of the 721 generic access rights. 723 5.7.1. Rationale 725 The set of access rights needs to be extensible because generic access 726 rights will not necessarily apply in any intuitive way to all types of 727 resources and operations. 729 A generic set of access rights is necessary because it would too 730 burdensome to require a separate set of access rights to be defined and 731 used for each new resource type or operation. Since there is a standard 732 set of operations which can be applied to many different resource types, 733 it is consistent to have a generic set of access rights which control 734 those operations. 736 Some server implementations may perform mappings between WebDAV access 737 rights and native file system access rights. However, in some cases, 738 not all of the generic rights described here will have distinct, 739 intuitive mappings to access rights used in the native file system. 740 Therefore, it is permitted to merge some generic rights with others in 741 order to facilitate such mappings. 743 5.7.2. List 745 A generic access right, known as the "list" access right, determines 746 whether a particular request to list the contents of a collection 747 resource will be allowed. More generally, the "list" right determines 748 whether a particular request to discover whether a particular resource 749 exists will be allowed. 751 The "list" access right may be merged with the "read" access right, 752 defined below. When a server does this, the granting or denying of 753 "read" access also grants or denies "list" access. If a client attempts 754 to create an ACE containing the "list" right, but not the "read" right, 755 such a server should return an error indicating that "list" is not 756 supported as an independent right. 758 5.7.2.1. Rationale 760 Experience with file systems has shown that unauthorized access or 761 attempts at circumventing security policies increase when users have 762 more information about the contents of the file system. Therefore, it 763 is helpful to define an access right that controls whether a user can 764 obtain this information about a particular resource. 766 5.7.3. Read 768 A generic access right, known as the "read" access right, determines 769 whether a particular request to view the contents of a particular 770 resource will be allowed. 772 The "read" access right may also subsume the meaning of the "list" 773 access right, as specified in section 5.7.2. 775 5.7.3.1. Rationale 777 Some resources may contain confidential or sensitive information. It 778 should be possible to limit whether a particular user is allowed to read 779 the contents of a resource. 781 5.7.4. Modify 783 A generic access right, known as the "modify" access right, determines 784 whether a particular request to modify the contents of a particular 785 resource will be allowed. 787 The "modify" access right may also subsume the meaning of the "delete" 788 access right, as specified in section 5.7.5. 790 5.7.4.1. Rationale 792 Experience with a wide number of information systems has shown that 793 different users need the ability to modify different resources. 795 5.7.5. Delete 797 A generic access right, known as the "delete" access right, determines 798 whether a particular request to delete a particular resource will be 799 allowed. 801 The "delete" access right may be merged with the "modify" access right, 802 defined above. When a server does this, the granting or denying of 803 "modify" access also grants or denies "delete" access. If a client 804 attempts to create an ACE containing the "delete" right, but not the 805 "modify" right, such a server should return an error indicating that 806 "delete" is not supported as an independent right. 808 5.7.5.1. Rationale 810 Experience with file systems has shown that it is sometimes preferable 811 to permit certain users to modify a particular resource without allowing 812 them to delete it. 814 5.7.6. Change Access 816 A generic access right, known as the "change access" access right, 817 determines whether a particular request to change an access control 818 policy will be allowed. 820 5.7.6.1. Rationale 822 Experience with file systems has shown that there is a significant 823 desire to separate the management of information content (what is 824 contained within the resources when a user reads it) from the manage of 825 access control structure. Often, different people in different roles 826 are responsible for these capabilities, and it may compromise the 827 intended security plan to allow users to change access control 828 information about a resource even if they are normally allowed to change 829 or delete it. 831 5.8. Security Considerations 833 Transfer of access control policies between a client and server over an 834 open network creates the potential for those policies to be modified or 835 disclosed without proper authorization. The requirements for the access 836 control protocol discussed in this document do not include cryptographic 837 protection of access control policy information, because it is assumed 838 that this protection can be provided through an implementation of HTTP 839 over TLS 1.0 or SSL V3. 841 The use of client IP addresses or DNS names in formulating access 842 control policies is subject to spoofing attacks. This risk should be 843 carefully considered when implementing such policies. The Web presents 844 somewhat of a dilemma in that most users have an expectation of 845 relatively anonymous read access to servers, leaving IP addresses and 846 DNS names as the only information about clients available to servers to 847 be used for controlling read access. 849 It may also be necessary to require other WebDAV protocol operations to 850 utilize HTTP over a secure transport protocol, in order to fully enforce 851 access control policies. If entities are transferred between a client 852 and server over an open network without cryptographic protection, those 853 entities are subject to unauthorized disclosure or modification, 854 regardless of what access control policies are in effect for the 855 associated resources, and regardless of whether the access control 856 policies themselves are protected when in transit over the network. 858 6. Copyright 860 Copyright (C) The Internet Society October 13, 1997. All Rights 861 Reserved. 863 This document and translations of it may be copied and furnished to 864 others, and derivative works that comment on or otherwise explain it or 865 assist in its implementation may be prepared, copied, published and 866 distributed, in whole or in part, without restriction of any kind, 867 provided that the above copyright notice and this paragraph are included 868 on all such copies and derivative works. However, this document itself 869 may not be modified in any way, such as by removing the copyright notice 870 or references to the Internet Society or other Internet organizations, 871 except as needed for the purpose of developing Internet standards in 872 which case the procedures for copyrights defined in the Internet 873 Standards process must be followed, or as required to translate it into 874 languages other than English. 876 The limited permissions granted above are perpetual and will not be 877 revoked by the Internet Society or its successors or assignees. 879 This document and the information contained herein is provided on an "AS 880 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 881 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 882 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 883 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 884 FITNESS FOR A PARTICULAR PURPOSE. 886 7. Acknowledgments 888 Parts of this draft were taken from a working draft edited by Jon 889 Radoff. Input from the following people has been instrumental in 890 bringing this document to its current state of completion, although it 891 does not necessarily reflect a consensus at this time: 893 Jim Davis, Xerox PARC, jdavis@parc.xerox.com 894 Yaron Y. Goland, Microsoft, yarong@microsoft.com 895 Paul Leach, Microsoft, paulle@microsoft.com 896 Larry Masinter, Xerox PARC, masinter@parc.xerox.com 897 Jon Radoff, NovaLink, jradoff@novalink.com 898 Judith Slein, Xerox, slein@wrc.xerox.com 899 Jim Whitehead, UC Irvine, ejw@ics.uci.edu 901 8. References 903 [HTTP] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and 904 T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, 905 U.C. Irvine, DEC, MIT/LCS, January 1997. 907 [IDC] T. Julian, R. Villars, "The Intranet's Many Faces," 908 Report 11344, International Data Corporation, April 1996. 910 [WEBDAV1] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. 911 Jensen. "Extensions for Distributed Authoring and Versioning on 912 the World Wide Web - WEBDAV", Internet Draft, work-in-progress, 913 draft-ietf-webdav-protocol-04.txt, October 1997. 915 [WEBDAV2] J. A. Slein, F. Vitali, E. J. Whitehead, Jr., D. Durand, 916 "Requirements for Distributed Authoring and Versioning on the 917 World Wide Web." Internet-draft, work-in-progress, 918 draft-ietf-webdav-requirements-03.txt, September 1997. 920 8. Author's Address 922 Howard Palmer 923 M/S MV061 924 Netscape Communications Corp. 925 501 E. Middlefield Rd. 926 Mountain View, CA. 94043 928 EMail: hep@acm.org 930 Expires May 17, 1998