Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS

I fully support option 3.  A server should do whatever it can to
ensure that the lock token is being used only by the client that
created the lock, but for a server that allows unauthenticated
clients to take out locks (and I believe that should be allowed),
there's nothing the server can do beyond checking
that the lock token corresponds to that on the locked resource.

Cheers,
Geoff

Julian wrote on 04/28/2004 02:23:52 PM:

> 
> 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 Sunday, 2 May 2004 16:37:36 UTC