[secdir] secdir review of draft-ietf-webdav-bind-23

Tero Kivinen <kivinen@iki.fi> Tue, 02 June 2009 10:52 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D253A6A09; Tue, 2 Jun 2009 03:52:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euH38dT0OBsa; Tue, 2 Jun 2009 03:52:36 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 807793A6866; Tue, 2 Jun 2009 03:52:36 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n52AqW02020503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jun 2009 13:52:32 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n52AqVY2009177; Tue, 2 Jun 2009 13:52:31 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <18981.1135.241220.933349@fireball.kivinen.iki.fi>
Date: Tue, 02 Jun 2009 13:52:31 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org, secdir@ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 16 min
X-Total-Time: 17 min
Cc: webdav-chairs@tools.ietf.org, draft-ietf-webdav-bind@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-webdav-bind-23
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2009 10:52:37 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document adds binding extensions to the WebDAV. Binding
extensions seem to be like hard links on unix file system i.e.
providing multiple bindings for same resource (and resource is freed
only when the last binding goes away).

Security considerations section refers to the "HTTP/1.1 and the WebDAV
Distributed Authoring Protocol specification" and says that all
security considerations of them also applies to this document, but it
does not give explicit references to the documents containing those
security considerations.

Bindings adds some new security concerns (privacy, loops, denial of
service etc.), and those issues seem to be adequately covered by the
security considerations section.

One of the things I am not sure if it is really applicable here, but
which is not covered by the security considerations section is that
bindings might confuse administrator about access permissions. I.e.
even when administrator revokes all change permissions from certain
collection (i.e the user cannot change the data any more), if that
collection has binding pointing to some other collection or resource
where user still has permissions, the user might still be able to
change resources in the first collection even when administrator
believes he already removed permissions.

I am not familiar enough with the WebDAV authorization model to know
if this kind of attacks are possible or not, i.e. I do not know if the
permissions are set per resource basis or for per collection or what.
-- 
kivinen@iki.fi