Comments on Access Control Goals

In preparation for the access control breakout at the Orlando IETF, I read
through the Access Control Goals document, and, while we never ended up
discussing the goals document during the breakout, I did want to pass along
my comments on the document.

In general, I thought it was a good document, which goes a long way towards
capturing group consensus on access control goals for WebDAV.  But, I also
suspect it can be improved with some diligent review.  I'd appreciate it if
members of the list would read through this draft
<draft-ietf-webdav-acl-reqts-00> and send out detailed comments.

Detailed comments below:

Section 5, definitions
  - The concept of a "right" needs to be defined.
  - It would be helpful to separate out the definitions of ACL, and ACE, and
also to have an example, in English, of an ACL and an ACE.
  - The concept of "ownership" needs to be defined.

Section 5.2, definition of Principal -- A principal is also intended to
model a computational process, like a Web crawler, whose access needs to be
controlled, but which doesn't map neatly onto the concept of "user", which
typically impies a human. Also, it might be useful to have a brief
discussion of the interaction between authentication mechanisms and the
notion of a principal.

Section 5.3. Scenarios -- this should be a separate, top-level section (it
doesn't really fit under "definitions", the heading for section 5.

Section 5.4, "Interoperability" -- This should also be its own, top-level
section.  It should also include the discussion from the breakout session on
the issue of mapping access control protocol semantics into the access
control semantics of the underlying repository, and the possible pitfalls.

Section 6, "Goals"
 - A general comment on the entire section is that each goal needs to have
at least a paragraph of rationale associated with it.  This rationale serves
many functions: 1) it provides a new reader the information they need to
assess whether the goal makes sense, 2) it provides a check to the author on
whether the goal is correct -- if the rationale is difficult to provide, it
may indicate a problem, 3) it provides a starting point for discussion on
the goal.

Section 6.2, "Specifying Principals":

          It must also be possible to specify special types of principals,
          in particular all authorized principals, all anonymous
          principals, and all principals.

I'm not sure what is meant by "special types of principals" here.  I'd like
to see some rationale.

Section 6.3, "Rights":

 - to alter the properties of a resource  -- "alter all the properties"
might be slightly better wording here

 - None of the rights discussed in this section map to the HTTP methods
"HEAD" or "OPTIONS".  Does it make sense to have an access right for these
too?
 - None of the access rights map onto HTTP POST either (an "execute" right?)
 - The following rights need to be added:
   - Read the body of a resource
   - Read the properties of a resource

Section 6.7, "Security":

  "It should be acceptable to deny unprotected transactions."

  I don't understand what is meant by an "unprotected transaction" in this
context.

Section 7.1:

          It is recommended that users be able to add access control
          information to an object without having to reset all access
          control settings.

I agree with this.

          This is recommended because certain systems or
          implementations may allow a user to add certain kinds of access
          rights but not others (i.e. grant "read" but not grant "delete").
          Similarly, it should be possible for users to be able to remove,
          delete or clear access rights without having to reset all rights.

However, this rationale seems to be too implementation-oriented.  Why did
the original stores implement the feature this way?

7.2.2.    Inheritance

          If the underlying system uses inheritance, then users of the DAV
          access control mechanism should still be able to predict its
          behavior.  This could be achieved if the type of inheritance is
          discoverable, or if the type(s) of inheritance is/are specified
          by the DAV access control protocol draft.

Even if the goals don't take a stand on the inheritance issue, I think they
should still lay out the decision space for which kinds of inheritance are
possible.  It seems like more work needs to be done to factor out the
underlying goals for inheritance.  For example, the goals might be something
like, "a new resource should receive a default ACL, and this default ACL may
depend on its URL."

       7.2.3.    Ownership

          Systems in which resources have owners also must be treated with
          care.  Predictability can be achieved on systems with owners by
          including owner functionality in DAV access control.  Systems
          which do not support owner functionality could refuse requests to
          change or set ownership.

          There may be other ways to preserve predictability with
          inheritance and ownership.

Similarly, the goals are sidestepping the issue of ownership.  For document
authoring, I think having a special principal for each resource, known as
the owner, can be justified.  The protocol can make ownership actions a
SHOULD if the repository mapping issues are too hard, but having ownership
seems like a reasonable goal.

Section 8.2, "Roles"

          Those with experience building complex document management or
          workflow systems on top of stores with simple ACLs know how hard
          it is to define roles for individuals. For example, the document
          management system can map the role "author" to grant the rights
          read/write/delete, but it is more difficult to go the other way.
          Is an individual with read/write/delete permissions an author, an
          editor, or somebody with no role and just a list of rights?  Many
          systems employ the concept of assigning roles, more temporary
          than identities, to more flexibly define access.

          Roles are important. However, roles would appear to be difficult
          and not necessarily related to ACLs.  The protocol draft MAY
          define how roles may be assigned.


I'm pretty convinced we do not want roles in the protocol.  However, the
above paragraph doesn't do roles justice.  Roles can be very helpful in
helping to administer access control across a repository.  Plus, roles can
be orthogonal to an ACL/ACE mechanism, and hence a role based system could
be built to use what we're proposing.

      8.3. Certificate-based security

          Certificates are out of scope for the DAV ACL protocol.

Why?  Some rationale is needed here.

       8.4. Time-based access control

          Time-based access control is out of scope for the DAV ACL
          protocol.

I agree, although I feel that a brief description of time-based access
control, as well as some rationale for not supporting it, is needed here.

Also, what is our stance on IP-based access control?

      9.   SECURITY CONSIDERATIONS

This section should reference the new, soon to be Draft Standard
authentication document (descendant of RFC 2069).


Nits:

Section 4.1:

          These
          controls define what actions a particular principals is allowed
          to exercise on a particular resource.

"principals" -> "principal"

Section 6.2:

It MUST be possible to use a the octet strings --> delete "a" after "use"

References:

[1] Y. Goland, J. Whitehead, A. Faizi, S. Carter, D. Jensen,
          "Extensions for Distributed Authoring on the World Wide Web",
          <draft-ietf-webdav-protocol-08>, April 1998.

This should be updated.

         H. Palmer, "Requirements for Access Control within Distributed
          Authoring and Versioning Environments on the World Wide Web",
          <draft-ietf-webdav-acreq-01.txt>, November 1997

This can be deleted.

          P. J. Leach, Y. Y. Goland, "WebDAV ACL Protocol", <draft-ietf-
          webdav-acl-00.txt> November 1997

          M. Satyanarayanan, "Integrating Security in a Large Distributed
          System", ACM transactions on computer systems 7(3), August 1989.

These should actually be referenced someplace.  Or, perhaps the last one
could be put in a "recommended reading" section.

- Jim

Received on Thursday, 7 January 1999 14:08:39 UTC