Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS

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.

Correct.

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

I agree with this statement in that the server has to ensure that the 
principal submitting the lock token indeed has the "right" to do that. 
However I disagree that locks *must* be tied to an authenticated user.

That requirement IMHO simply doesn't make sense. It would mean that a 
WebDAV server can't offer locking on resources with anonymous access. 
Why would we want to *forbid* that?

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

Emphasis here (read previous paragraph) is not "authenticated" but 
"submitted".

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

I think this is what is currently being implemented; and there doesn't 
seem to be any reason to forbid unauthenticated usage of locks. If a 
server chooses to do that, why should that be forbidden?

Generally, locking and authentication are separate concepts. Of course 
servers *can* tie lock ownership to particular principals, but there 
doesn't seem to be a compelling reason to require that.

Maybe Geoff (who raised one of the issues) could explain?


Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 28 April 2004 14:24:32 UTC