Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS

IF_AND_AUTH: This issue was raised by Geoff.
LOCK_SEMANTICS:  This was apparently raised by the DeltaV design team.

Julian, your recommended solution goes counter to the solution  
recommended by the people who raised these issues, as far as I can  
tell. Both these issues were raised in order to strengthen the  
requirement that authentication is required to use a lock  
token, whereas you suggest loosening that requirement altogether.

So, with conflicting suggestions, we need more discussion and for  
people to indicate which side they fall on.
  1. Authentication is required for lock token usage but the draft is  
clear enough already.
  2. Authentication is required for lock token usage but the draft needs  
clearer text (please suggest where, what text).
  3. Authentication MAY be required for lock token usage (see text  
below).
  4. Other -- please describe your position.

This is a call for consensus -- I'll respond separately with my own  
opinion.

For reference, here are the most salient sections of the existing -bis  
draft:

section 6.3:
"Having a lock token provides no special access rights. Anyone can find  
out anyone else's lock token by performing lock discovery. Locks MUST  
be enforced based upon whatever authentication mechanism is used by the  
server, not based on the secrecy of the token values."

section 7.6 the "authorized" is re-emphasized:
In order to prevent these collisions a lock token MUST be submitted by  
an authorized principal for all locked resources that a method may  
change or the method MUST fail.

Here's some proposed text to consider adding to section 7.6  if we lean  
towards option 3 above (note this would also require changing the text  
in the above quoted paragraphs):

Servers MAY restrict usage of the lock token to exactly the  
authenticated principal who created the lock.  Servers MAY also allow  
other privileged authenticated principals or even unauthenticated  
principals to use the lock token.

Lisa

On Apr 25, 2004, at 8:00 AM, Julian Reschke wrote:

>
> From <http://www.webdav.org/wg/rfcdev/issues.htm>:
>
> IF_AND_AUTH: "The fact that use of authentication credentials with  
> submission of lock tokens is required should be strengthened in the  
> document."
>
> and
>
> LOCK_SEMANTICS: "At present, the WebDAV specification is not  
> excruciatingly explicit that writing to a locked resource requires the  
> combination of the lock token, plus an authentication principal. At  
> one point, the spec. discusses an “authorized” principal, but  
> “authorized” is never explicitly defined."
>
> I'd like to confirm that indeed authentication and the ability to use  
> a given lock token MAY be orthogonal. That is, a server can
>
> - restrict usage of the lock token to exactly the principal that was  
> authenticated when the lock was obtained,
>
> - restrict usage to the creator as above and a group of other  
> principals that are allowed to "break" the lock (WebDAV ACL DAV:unlock  
> privilege, see  
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl- 
> latest.html#PRIVILEGE_unlock>) or
>
> - allow anybody who knows the lock token to use it.
>
> I think right now there are servers implementing each of these  
> schemes, and there doesn't seem to be any problem with that.
>
> Regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>