Subject: Re: RFC-2518 LOCK-TOKEN: header

From: [email-masked]
Date: Wed, 26 Jan 2000 12:33:34 -0500

Geoff,
Some corrections and comments below in <jra> tags, but in summary, the
owner element is not sufficient to identify the owner of a lock, and is not
used by the server in any way. It is purely a mechanism for clients to
provide some more meaningful indication of the owner of a lock.

The authentication mechanisms are not specified by HTTP (although WebDAV
does specify Digest and Basic for secured connections), but the
authentication header is used by WebDAV to identify the user agent making
the request, and it is this header that is used to determine if the
requestor is the owner of the lock. The lock discovery element does not
contain this information.

"Geoffrey M. Clemm" <[email-masked]>@w3.org on 01/25/2000
01:10:24 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:

Subject:  Re: RFC-2518 LOCK-TOKEN: header

   From: [email-masked]

   If the lock token isn't returned in the header, there's no way for you
to
   get the lock token of the lock you just created.

Section 6.3 of RFC-2518 states that you can get the lock token
through the lock discovery property:

"A lock token is a type of state token, represented as a URI, which
identifies a particular lock.  A lock token ... can also be found
through lock discovery on a resource."
<jra>
Yes, but you can't figure out which ones are yours.
</jra>

   That's because the active
   lock element of the lock discovery property does not contain the
   authentication id of the principal owning the lock.

I can find no authentication id defined or required by RFC-2518.

In fact, RFC-2518  explicitly states that an authentication id is not
part of the WebDAV protocol:

"Locks MUST be enforced based upon whatever authentication mechanism
is used by the server, not based on the secrecy of the token values."

and:

"User agent authentication has previously occurred via a mechanism
outside the scope of the HTTP protocol, in an underlying transport
layer."
<jra>
Its this user agent, identified by the authentication header, that is used
to actually enforce locks. As far as the server is concerned, the lock
token just goes on for the ride. It has to be specified, and the user agent
has to own the lock, but otherwise the lock token isn't used.
</jra>

   The lock tokens are in
   the lock discovery, but you can't figure out which ones you own.

This information is provided by the DAV:owner element in the
lockdiscovery property.
<jra>
This is not the owner information used by the server to identify the owner
of the lock. Rather it is client information used to provide a more
meaningful indication of the owner of the lock for contact information. Use
of this element for identifing lock ownership would create an
interoperability problem because the actual contents are not specified in
the WebDAV spec.
</jra>

   I continue to believe this is an open issue that requires clients to
   persist their lock  tokens outside the WebDAV repository. Lock tokens
are a
   pain enough for the rare case where they are actually useful.

How else do you handle the situation where the same principal has
several clients acting against the same resource?  I believe this will
be a common scenario.
<jra>
Yes, and lock tokens will be marginally useful for this situation. The only
thing that can be done is a client can know if it got the lock from a LOCK
request, or by some other means (IPC, reading from a file, from the
DAV:lockdiscovery element, etc.). A client obtaining the lock from some
other means can only assume that there might be other clients operating
concurrently under the same principal, and can offer a warning before
overwriting the resource.
</jra>

Cheers,
Geoff

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 26 Jan 2000 23:57:22 -0500

From: [email-masked]

   Some corrections and comments below in <jra> tags, but in summary, the
   owner element is not sufficient to identify the owner of a lock,

It is sufficient if it is just information that a client wants to
present to the user to help her decide whether she wants to cancel
(UNLOCK) an existing lock.

   and is not used by the server in any way.

I agree.

   It is purely a mechanism for clients to
   provide some more meaningful indication of the owner of a lock.

I agree.

   requestor is the owner of the lock.

I have found no reference to an "authentication header" in rfc2518,
neither in terms of defining it, nor in terms of using it.

I have made this point in several postings ... and will continue
to do so until acknowledged or refuted (:-).

   The lock discovery element does not contain this information.

Which should come as no surprise, since the authentication header
is not defined (:-).

   <jra>

For the purposes of the user deciding whether to cancel an
existing lock, the DAV:owner information should be sufficient.

   <jra>

Yes, for authenticated access control, a lock token is pointless -
one indication that the WebDAV locks are not the appropriate protocol
mechanism to support authenticated access control.

      The lock tokens are in

   <jra>

As long as this information is just presented to the user, there is
no need for detailing the actual contents.

   <jra>

A lock-token is not used by a client because it discovers it on a
resource ... it is only used if that client obtained that lock-token
through a LOCK request.  This guarantees that you will not have a
merge conflict amoung cooperating clients, which makes it very useful.
A client that wants to "steal" a lock, does so by unlocking the resource
and then requesting its own lock with a new LOCK request.

You could require that only the principal issuing a LOCK can "steal"
the lock, but this should be a client-controlled ACL issue, *not*
something hard-wired into the protocol.

Cheers,
Geoff

---

From: Greg Stein <[email-masked]>
Date: Thu, 27 Jan 2000 01:33:53 -0800 (PST)

On Wed, 26 Jan 2000, Geoffrey M. Clemm wrote:
>...

Section 6.3, last paragraph. It mentions that the use of the lock token
must also be enforced through the server's authentication mechanism.

That mechanism may or may not be a header, but the RFC is quite clear (in
my mind) that simply holding a token is not enough. You must have the
token and you must have the same authentication as that used when the lock
was created. Given these two pieces of state, you are allowed to operate
on the target resource.

> existing lock, the DAV:owner information should be sufficient.

Many clients may not set that field. I don't think that you can
necessarily depend upon it. But: I tend to agree that there is nothing
better, and that field *is* intended for human consumption (and,
therefore, for asking whether a lock should be cancelled).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 27 Jan 2000 08:38:23 -0500

From: Greg Stein <[email-masked]>

Yes, authentication is mentioned in various places in the protocol,
but there is no mention of an "authentication header" (neither a
definition of its value nor how it is to be used).

   was created.

I agree that this is made stated in the protocol, but this is of
limited value to a client since no interoperable mechanism for doing
so is specified.  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.

There are different to address this current problem in the protocol.
One would be to beef up the authentication associated with locks.  I
believe this is the wrong approach, since I believe that token-based
namespace-protecting "locks" are only appropriate as a merge avoidance
mechanism, while long-term access control should be neither
token-based, nor should it involve any URL protection.

Another approach is to provide a principal-based access control mechanism,
to complement the locking mechanism.  Whether or not locks require some
level of authentication for use would be controlled by the client, based
on ACL's of the locked resource.  That is an approach I would support.

Yes, if a client decides to store no information there, then that is
the clients choice.  But I believe the DAV:owner field is a good
interoperable mechanism for addressing the problem of how to let a
client present information to its user about the principal that
requested the lock.

Cheers,
Geoff

---

From: Jim Whitehead <[email-masked]>
Date: Thu, 27 Jan 2000 15:13:43 -0800

Geoff Clemm writes:
> Yes, authentication is mentioned in various places in the
> protocol, but there is no mention of an "authentication
> header" (neither a definition of its value nor how it is
> to be used).

The "Authorization" header is defined in RFC 2617, "HTTP Authentication:
Basic and Digest Access Authentication"
<http://www.ics.uci.edu/pub/ietf/http/rfc2617.txt>.  This is the Draft
Standard version of the Basic authentication information from RFC 2068, and
the Digest authentication information from RFC 2069.  Both of these
documents (RFC 2068 and RFC 2069) are normatively referenced from RFC 2518
(see especially section 17.1).  Furthermore, 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.

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

Greg Stein writes:
> That mechanism may or may not be a header, but the RFC
> is quite clear (in my mind) that simply holding a token
> is not enough. You must have the token and you must have
> the same authentication as that used when the lock was
> created. Given these two pieces of state, you are allowed
> to operate on the target resource.

This is correct.

Geoff Clemm writes:
> I agree that this is made stated in the protocol, but
> this is of limited value to a client since no interoperable
> mechanism for doing so is specified.

Section 17.1 states that, at minimum, Digest authentication must be
supported by all WebDAV applications, thus ensuring there exists at least
one interoperable mechanism for authentication.

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.  There are good arguments either way: requiring them would make
locking more consistent, but allowing "anonymous" locking would enable
WebDAV clients to interact anonymously with a service, which could be a plus
for publically writeable pages.

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.

- Jim

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 27 Jan 2000 23:20:42 -0500

From: Jim Whitehead <[email-masked]>

   ... 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.

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

   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.

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

---

From: Jim Whitehead <[email-masked]>
Date: Fri, 28 Jan 2000 11:39:02 -0800

> to be friendly, amusing sarcasm, not bitter, vicious sarcasm :-).

Actually, the ambiguity here is intentional.  If you look at RFC 2068, the
one aspect that looks the most dated after just a few years is the Basic
authentication information.  Since Basic is not secure, and while Digest is
better, but still not perfect, we felt that hardwiring the WebDAV
specification to any particular authentication mechanism would be a poor
design.  In particular, we did not want to mandate use of the Authorization
header (we mandate *support* for Digest, but not *use* of Digest), since it
seemed quite reasonable that some connection-layer security mechanism might
be developed that would handle authentication.  If this happened, it would
cause people to ignore a requirement in the WebDAV spec. to use some other
authentication mechanism.

Furthermore, looking into the future we saw technologies like smart cards,
fingerprint readers, retinals scans, etc., all of which could change how
authentication was performed in the protocol.  It really seemed like a
losing proposition to tightly specify the kind of authentication that was
used.  That's why the requirement to have both authentication information,
and the lock token submitted, was phrased that way it is at the bottom of
section 7.6.  I'll grant you that, looking at this section with a critical
eye, the wording could be improved, but I'll defend not explicitly stating
we should use the Authorization header all the time.

> when creating (LOCK) and deleting (UNLOCK) a lock.

Thanks for playing! :-)  Actually, by my count there are only four examples
in the specification where the If header is use in a full HTTP request:

Section 7.6.1: This example clearly states that authentication was performed
in the transport layer (via some SSL-like technology that performs
authentication)

Section 8.9.6: Also states the authentication was performed in the transport
layer.

Section 8.10.9: This example uses the Authorization header.

Section 9.4.2.1: In this case, no mention is made of authentication,
primarily because it is being used to describe the use of the If header
itself.  But, since this is a COPY operation, and the lock token is being
submitted for the source resource, there actually is no need to provide
authentication information, since the state of the source isn't modified on
a copy.

> with lock tokens.

I agree that access control should be an orthogonal issue to locking.

> If a given principal is authorized to do something,

Just to make sure we're violently agreeing, lock tokens shouldn't be used
for access control, but should be used for merge avoidance.  Furthermore,
submission of authentication information (different from access permissions)
with a lock token is important, since it allows the server to ensure that
only the principal that took out a lock is permitted to modify a locked
resource.

> What matters is that

OR, if it uses lock tokens issued to other clients operated by the same
principal, it does so with full knowledge that it could be causing an
overwrite conflict. This presumably involves informing the user of this
behavior (although the user probably already knows they're about to
overwrite their own work).  One driving scenario for this was to make sure
that someone could work on a document at work, then go home, decide they
want to work on that same document from home, and be able to.  Sure their
application will tell them they're about to overwrite their work, but this
is OK. It's what they want to do.

> reason to have the complexity of lock-tokens in the protocol.

You need lock tokens to identify the lock.  If a lock disappears underneath
a client, and then another client (operated by the same principal) takes out
a lock on the resource, then without lock tokens, the first client wouldn't
know that it would cause an overwrite if it wrote to the locked resource.
Using lock tokens, the client will be informed that the lock token isn't
valid, even though the resource is locked, and by the same principal.

> lock-token.  Perhaps there is some other reason I haven't heard yet?

There are no other reasons I can think of.

> principals while closed to non-trusted principals.  Lock-tokens are

This scheme would work, but has several drawbacks.

You either:
(a) Allow everyone in the write set to have access to the resource, and they
negotiate out-of-band to prevent overwrite conflicts.  But, since DAV allows
people to be widely geographically dispersed, perhaps over several time
zones, I don't think its reasonable to assume that people in the write set
will always have perfect information about what their collaborators are
doing.  As soon as the information is incomplete, it leads either to
overwrites, or the need to merge.

(b) Dynamically alter the write set.  So, if, before I start work, Jane,
Fred, and I have access to a resource, I'll change the ACL list so that only
I have access to the resource, and I'll persistently store that Jane and
Fred used to have write access.  I'll do my work, and then once I'm done,
I'll re-add Jane and Fred back.  But, what happens if my client crashes, and
loses this information? Or, what happens if I leave work in the middle of an
edit session, get ill overnight, and then don't come into work for two days?
Or, even worse, what happens if the ACls are set by some kind of
administrative policy, and I don't even have permission to change the ACL
list?  These drawbacks, combined with the fact that it conflates the issues
of overwrite avoidance with access permissions (two separate issues), are
why I don't like this approach.

> - Locking with lock tokens is a good thing, and provides merge avoidance

Agreed.

> malicious or unauthorized clients.

Agreed.

> welcome to steal it if you are the principal that requested the lock).

Agreed (I think - devil's in the details :-).

- Jim