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

[Oscar Novo <[e-mail]>]

Hello Tero,

Thank you very much for your comments. They're really valuable. 

The authors of this document understand the Security considerations as a general guidelines for the implementers, rather than a set of absolute requirement for this specification. It might be the case in some particular scenarios where the confidentiality can be ignored. For this reason, we decided not to impose confidentiality (using SHOULD instead of MUST) in the document and to leave that decision to the administrator of the conference.  

The same reason applies to the definition in this document of 'private elements'. Privacy is a subjective expectation and the definition of private elements in the conference depends very much on the context of such conference. As you point out, every country, company, association or entity would have a completely different meaning of privacy. For this reason, we just decided to suggest some control and integrity of the data ( by using access control rules) in the security section instead of imposing it:    

   In order to minimize these threats, the
   administrator of the conferencing system MUST ensure that only
   authorized users can connect to this database (e.g., by using access
   control rules).  In particular, the integrity of the database MUST be
   protected against unauthorized modifications.

Cheers,

Oscar

-----Original Message-----
From: Tero Kivinen [mailto:[e-mail]] 
Sent: 3. maaliskuuta 2011 15:06
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Review of draft-ietf-xcon-common-data-model-23.txt

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. 
--
[e-mail]