Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS

So for the record, I lean towards option 1 (no change) because I can't  
recall any interoperability problems in this area.  Without any known  
interoperability problems, it seems safest to leave the spec unchanged.

Lisa

On Apr 28, 2004, at 11:00 AM, Lisa Dusseault wrote:

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