Re: [secdir] Review of draft-ietf-xcon-common-data-model-27.txt

Tero Kivinen <kivinen@iki.fi> Fri, 27 May 2011 13:11 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C7AE07CF; Fri, 27 May 2011 06:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL2tH3U9yhVR; Fri, 27 May 2011 06:11:18 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185EBE072E; Fri, 27 May 2011 06:11:17 -0700 (PDT)
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 p4RDBCXr018662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 May 2011 16:11:12 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p4RDBBUI028481; Fri, 27 May 2011 16:11:11 +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: <19935.41711.849950.705575@fireball.kivinen.iki.fi>
Date: Fri, 27 May 2011 16:11:11 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Oscar Novo <oscar.novo@ericsson.com>
In-Reply-To: <58E207308662A748A4AC1ECB4E8856140815CDED51@ESESSCMS0355.eemea.ericsson.se>
References: <19935.37953.301024.987227@fireball.kivinen.iki.fi> <58E207308662A748A4AC1ECB4E8856140815CDED51@ESESSCMS0355.eemea.ericsson.se>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 14 min
X-Total-Time: 13 min
Cc: "draft-ietf-xcon-common-data-model.all@tools.ietf.org" <draft-ietf-xcon-common-data-model.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Review of draft-ietf-xcon-common-data-model-27.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 27 May 2011 13:11:19 -0000

Oscar Novo writes:
> 1) The confidentiality is not mandatory even in the cases where the
>    database contains sensitive elements (passwords), it is only
>    SHOULD.
> 
> [ON] In the new version of the draft (28) I have changes the text a bit:
> 
>    "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), and it is RECOMMENDED the
>    database uses encryption mechanisms if the information is stored in
>    long term storage (e.g., disk)." 

I would think that SHOULD (or MAY) is ok if there is no sensitive
elements in the database, but if the database actually do contain
sensitive elements like password do you really think confidentiality
is not needed?

If so in which scenarios it would be ok to not use confidentiality
and not protect the sensitive data from unauthorized users?

Saying that data SHOULD be encrypted when stored to the disk is
actually ok, as I do think SHOULD is acceptable there, as I can see
several valid scenarios where the long term storage access can be
secure enough that encryption is not needed.

I do not see any real scnearios where unauthorized users needs to
given access to the sensitive elements.

> 2) The privacy issues is not covered enough. The current version added
>    specific pointer to the section 11.2 of RFC5239, but that only
>    covers one very small privacy issue, i.e. anonymous access. It does
>    not cover gathering sensitive privacy information in the database,
>    i.e. who participated which conferences and with whom.
> 
> [ON] We don't think this document should solve questions as "who
> participated which conferences and with whom?". And in the working
> group was agree to leave the policy outside this document for future
> documents.

I do not think there is really problem to solve, but I think by nature
this database will have such information, and that information might
be stored to long term storage. I.e. if someone makes conferences
about the "human rights problems in country X", and invites people to
participate such conference, then that information is stored to the
database.

By keeping that information in database this database now contains
sensitive privacy information, which is not pointed out in this draft.

I think security considerations section should point out that some
information stored in the data model might be sensitive in addition to
obious things like passwords and identity of the anonymoys users. This
may include the information about identities of the people
participating specific conferences or who is communicating with who
(i.e. telecommuniations data retentation:
http://en.wikipedia.org/wiki/Telecommunications_data_retention).

The current data model for example is quite vague about how long the
information is stored. I.e. how long will the list of participants
given in the system. When will it be deleted etc. If this only assumes
that all information only covers the currently on-going events then
that is good, but in most cases I think some information might be
stored before the event even starts etc.

I do not think there is need to modify the actual data model, more
likely point out that there might be issues there which some people
might not even see immediately (as can be seen how hard it has been
for me to try to express what my concern is). 
-- 
kivinen@iki.fi