RE: WEBDAV Security

At 12:03 AM 4/16/97 -0700, Yaron Goland wrote:
>[Larry Masinter wrote]
>> I agree you should try to limit the scope of what you handle to
>> be "the minimum needed to build interoperable clients", but I believe
>> taht the minimum exceeds what has been done so far for DAV-less HTTP.
>
>I agree that there are certain requirements that are specific to DAV,
[...]
>However, those needs should be addressed within the context of a working
>group tasked to solve the general ACL problem.

Sorry, I agree with Larry. First, there is no group presently constituted
to solve the "general ACL problem". I doubt there will be or that it would
achieve results in time for this group to use them. Second, I have a hard
time understanding why "requirements specific to DAV" should be dealt with
in some other group. 

>We should not try to come
>up with a solution that only meets our needs and we should not presume
>to dictate a solution to meet needs outside the scope of this group.

We should not try to develop an entire security architecture that meets
only our needs. However, I think that our needs can be met with already
existing mechanisms, such as DIGEST authentication, SSL, etc. All servers
I know of already have mechanisms for governing access. What we have to
do is specify a way for clients to read and write that sort of info in
a server-independent fashion. The servers will have the job of converting
between the server-independent protocol and their particular access
control mechanisms.

Security concerns were one of the issues raised at the Memphis meeting.
At least some of the questions that people wanted answered were:
  1) How does an author get permission to modify a document?
  2) How does an author establish the permissions on a new document?
  3) How does an author or administrator change the permissions on a
     document?
    
These are all reasonable questions that an interoperable protocol for
DAV has to answer. Furthermore, I don't think you can declare them
"out of scope" since several people at the meeting were concerned about
this problem. IMHO, this is MANDATORY functionality and the only way
it will interoperate is if we specify it. Any draft DAV spec with such a
glaring ommission will be pummeled mercilessly during last call. (And I
will be one of the people doing the pummeling. :-)

Finally, I think we can achieve a solution to those questions without
too much grief. For example, here is one possible solution, off the top
of my head.

  1) How does an author get permission to modify a document?

     To edit a resource, the author does a GET on the URI of the source
     of the resource. Existing HTTP authentication mechanisms may be used
     to limit access to the resource. To check the resource in, existing
     mechanisms can be used to restrict access to the PUT method. If an
     author does not have permission to GET and/or PUT a resource, see
     question 3.  (Use of BASIC authentication is strongly discouraged,
     the spec should say that clients and servers MUST support digest
     authentication if they are to claim DAV-compliance. This is because
     of the IAB's explicit repudiation of clear passwords in future
     protocols).
     
  2) How does an author establish the permissions on a new document?

     By default, PUTs to a new URI inherit the permissions already on
     the server for that portion of the namespace. (e.g. a PUT to
      http://www.foo.com/papers/1997/bar.html might use the permissions
     set in the papers/1997/.htaccess file). If the author wishes
     special permissions to be established for their resource, those
     permissions MUST be established before the resource is PUT to the
     server. See question 3 for how those permissions are established.
     
  3) How does an author or administrator change the permissions on a
     document?

     There are two means for administering the ACL for a resource - local
     and remote. Local administration is outside the scope of the DAV spec.
     It is specific to a particular brand of server, but might be as simple
     as "edit the .htaccess file". One means for an author to get the
     permissions on a resource changed or established is for them to use
     out-of-band means to contact their server administrator and let it be
     done locally.

     More useful, but more difficult to secure, is remote editing of the
     permissions. The most straightforward way to do this would be to
     define a new media type that contains a URI and some specification
     of the permissions for various groups and users. Use POST to a
     well-known URI to have that media type processed by the server and
     the permissions set. (People who represent vendors that don't use
     NCSA-style .htaccess files should comment on the difficulty of
     processing that syntax to meet their needs). DIGEST authentication
     must be used for such an operation, and it would be best if the
     permission info was encrypted during transfer.

I make no claims that these are great approaches to the problem, but its
a starting point for further discussion on this topic. I do claim that
this topic must be handled in this group. 

Cheers,

Ron Daniel Jr.              voice:+1 505 665 0597
Advanced Computing Lab        fax:+1 505 665 4939
MS B287                     email:rdaniel@lanl.gov
Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545

Received on Wednesday, 16 April 1997 12:29:00 UTC