Last Call Review of draft-ietf-xcon-common-data-model-
review-ietf-xcon-common-data-model-secdir-lc-kivinen-2011-03-03-00

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 at iki.fi