Re: v6: don't use Authorization in examples

>Where as
>
>LOCK and UNLOCK use the lock-token header
>
>and
>
>without authentication information an unauthorized principal could perform a
>PROPFIND on the lockdiscovery property and obtain a lock token in use by
>another principal

You are assuming that the authentication information is being exchanged
within the HTTP protocol and not within some underlying protocol.

>and 
>
>the unauthorized principal could then perform actions they are not allowed
>to perform
>
>and
>
>the only way to prevent this is to authenticate that the principal is who
>they say they are

You are assuming that there is a need to prevent this in all cases.

>Therefore
>
>The examples include the use of authentication information in order to make
>absolutely clear that digest is MANDATORY and REQUIRED in circumstances such
>as LOCK/UNLOCK.

This would be a *very* big mistake.  Extensions to HTTP survive only
when they can coexist with other, orthogonal extensions to HTTP.  WebDAV
is not dependent on strong authentication when used within a strongly
authenticated environment, and support for Digest is not necessary for
both secure environments and intentionally non-secure (anonymous
collaboration) environments.

WebDAV should only require strong authentication when it is appropriate
for the application using WebDAV.  Strong authentication (of which Digest
is only one example) should only be listed as required for WebDAV
applications when performing principal-specific operations using a
transport layer that does not already provide an authenticated principal.

If I implement and deploy an SSH-based authenticating server, or even an
SSH-based AA mechanism in HTTP, should WebDAV be considered obsolete?

....Roy

Received on Saturday, 24 January 1998 21:30:42 UTC