[secdir] Review of draft-ietf-xcon-common-data-model-23.txt

Tero Kivinen <kivinen@iki.fi> Thu, 03 March 2011 13:05 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 0A7373A69DD; Thu, 3 Mar 2011 05:05:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Level:
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 AmRSCaPMYOlk; Thu, 3 Mar 2011 05:05:05 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2A4E93A699F; Thu, 3 Mar 2011 05:05:04 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p23D68w4029413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2011 15:06:08 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p23D67lj010594; Thu, 3 Mar 2011 15:06:08 +0200 (EET)
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: <19823.37439.966900.314499@fireball.kivinen.iki.fi>
Date: Thu, 3 Mar 2011 15:06:07 +0200
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: 18 min
X-Total-Time: 20 min
Cc: draft-ietf-xcon-common-data-model.all@tools.ietf.org
Subject: [secdir] Review of draft-ietf-xcon-common-data-model-23.txt
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: Thu, 03 Mar 2011 13:05:07 -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 contains xml data model description for conference
information. As this is data model and does not list any actual
protocols to transmit those xml files its security considerations
section is quite generic.

It does say that database access must be authorized (access control
rules) and that integrity of the database MUST be protected against
unauthorized modifications. How this is done is left to the actual
protocol documents.

It does NOT require confidentiality of the database, but instead says:

   The confidentiality of the database SHOULD be protected from
   unauthorized users, given that the data model contains a set of
   sensitive elements (e.g., passwords).  

I do not agree on that comment. If the data model contains sensitive
elements like passwords I think the confidentiality MUST be protected
from unauthorized users.

If it is possible that the data model does not contain any sensitive
elements then I think the SHOULD could be enough. Also it does not
specify what data in the data model is sensitive.

Also the security considerations section completely fails to address
the fact that the database most likely also contain data that has
privacy issues. For example the list of users participating the
specific conference could be quite big privacy issue (for example some
group of human rights people discussing issues about their own
goverment). Note, that this also might require some discussion about
the lifetime of the data in the database. I.e. when is the list of
participants removed from the database and how long it is stored
there.

In most countries there are specific laws protecting such information,
so those might require preventing unauthorized access to the database.

Also as there is fields like provide-anonymity in the database which
tells which user is mapped to which "anonymous" name for users to see,
but if someone gets read access to the database that person can
directly map those anonoymous users to their real identities.

I think the security consideation sections should include text about
the privacy issues, and most likely mandate support for
confidentiality of the database, and preventing unauthorized read
access to it. 
-- 
kivinen@iki.fi