Re: RFC-2518 LOCK-TOKEN: header

   From: Jim Whitehead <ejw@ics.uci.edu>

   ... the locking examples in section
   8.10.8, 8.10.9, and 8.10.10 use the Authorization header in the request
   message to highlight the fact that authentication credentials must be
   supplied.

Hmmm.  Specification by example ... leaving the reader to inductively
derive the protocol from the examples.  (Note: this is intended
to be friendly, amusing sarcasm, not bitter, vicious sarcasm :-).

OK, I'll play along.  Then since the Authorization header is only used
in the LOCK and UNLOCK examples, but never used in any of the
(several) examples that specify the lock-token in an If header, a
naive reader would conclude that authentication via the Authorization
header is *not* required for use of the lock token, but rather only
when creating (LOCK) and deleting (UNLOCK) a lock.

   There is no reference to a header named "authentication" in RFC 2518.

Thankyou.  I will now stop beating that particular dead horse (:-).

   Geoff Clemm writes:
   > In addition, no authentication is required if no
   > authentication was performed when the lock was
   > created, so a client cannot count on any authentication
   > taking place.

   Well, at present RFC 2518 is silent on whether a server is allowed to create
   a lock if no authentication credentials were presented during the lock
   request.

In the past (e.g. the "atomic deletion" discussion), the principle of
"it is allowed unless it is explicitly forbidden" has been the general rule.
Applied here, silence would imply that it is acceptable to create a lock
with no authentication credentials.

   There are good arguments either way: requiring them would make
   locking more consistent,

"consistent" with ... ?

   but allowing "anonymous" locking would enable
   WebDAV clients to interact anonymously with a service, which could be a plus
   for publically writeable pages.

Yes.  And to emphasize, I am 100% in favor of authentication and ACL's,
I just believe the ACL's should be on *resources* and not associated
with lock tokens.  If a given principal is authorized to do something,
it's client shouldn't have to pointlessly gather up lock tokens for use
in an If header, since this provides no additional security.

   But, if the server grants a lock to a specific authenticated principal, the
   fact that it might also allow anonymous locking on that resource is
   irrelevant.  Other principals will not be able to modify the resource while
   the lock is being held by authenticated principal.  Any other behavior is an
   error.

As is made clear in rfc2518, restricting use of a lock-token to the
principal that requested the lock does not provide overwrite protection,
since a principal can have *multiple* clients acting on his behalf.
The only reason for having lock-tokens is to provide overwrite protection,
and overwrite protection requires that a lock-token be only used by
the *client* (not the principal) that created the lock-token.
So the fact that your client is acting on behalf of a certain principal
is irrelevant to the proper use of lock-tokens.  What matters is that
a client only uses lock-tokens that it has issued.

Alternatively, if clients aren't going to restrict themselves to using
the lock tokens that they created via LOCK, but will grab any
lock-token that was created by their principal, then there is no
reason to have the complexity of lock-tokens in the protocol.

Note: Overwrite protection is the only reason I've ever heard for a
lock-token.  Perhaps there is some other reason I haven't heard yet?

Now there is a completely different question of how you deal with
malicious or non-cooperating clients.  My answer would be with ACL's,
since you need to keep the resource open for editing by trusted
principals while closed to non-trusted principals.  Lock-tokens are
totally irrelevant here.

So to summarize my position:
- Locking with lock tokens is a good thing, and provides merge avoidance
for cooperating clients.
- ACL's on resources is a good thing, and provides protection against
malicious or unauthorized clients.
- using locks to "fake" acl's on resources produces confusion, since
a client doesn't know whether a lock is there to prevent merge avoidance
(i.e. it shouldn't steal it), or is there to fake an ACL (it is
welcome to steal it if you are the principal that requested the lock).

I'm not sure how much farther we can converge via email ... perhaps a
conference call would be in order (in all our copious spare time :-).

Cheers,
Geoff

Received on Thursday, 27 January 2000 23:20:45 UTC