Confidentiality of lock information (BugZilla issue 260), was: [Fwd: Gen-art last call review of draft-ietf-webdav-rfc2518bis-17.txt]

Julian Reschke schrieb:
>> Potential security implications of lockdiscovery:  s6.8 requires a
>> compliant server to support lockdiscovery and expects the response to
>> this request to include the names of principals and potentially the lock
>> tokens for locks being held on a resource.  The privacy implications of
>> this are discussed in the Security Considerations but it does not appear
>> to be allowed to restrict or deny this request purely on security
>> grounds.  It is likely that some organizations might consider the
>> ability to determine who holds locks is a sensitive matter beyond just
>> issues of privacy, and the responses to lockdiscovery might be mediated
>> by access controls.
> 
> I agree that this is a problem. The change in RFC2518bis has been done
> in an early draft; I don't recall any discussion related to this, nor is
> this mentioned in the Changes section.
> 
> Opened issue:
> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=260>
> ...

RFC2518 says in 
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.13.8>:

"The lockdiscovery property returns a listing of who has a lock, what 
type of lock he has, the timeout type and the time remaining on the 
timeout, and the associated lock token. The server is free to withhold 
any or all of this information if the requesting principal does not have 
sufficient access rights to see the requested data."

This was changed in RFC2518bis between drafts 1 and 2, and I'm not aware 
of any discussion about this, nor is this change recorded in the Changes 
section. Thus, it probably was unintentional, and I would recommend to 
restore the old text.

Best regards, Julian

Received on Saturday, 17 February 2007 19:04:55 UTC