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

From: Tero Kivinen <[email-masked]>
Date: Thu, 3 Mar 2011 15:06:07 +0200

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. 
-- 
[email-masked]

---

From: Oscar Novo <[email-masked]>
Date: Thu, 3 Mar 2011 15:24:11 +0100

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:[email-masked]] 
Sent: 3. maaliskuuta 2011 15:06
To: [email-masked]; [email-masked]
Cc: [email-masked]
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.

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. 
--
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 4 Mar 2011 12:36:35 +0200

Oscar Novo writes:
> 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.

I can understand that, and I agree that on some scenarios the
confidentiality can be ignored. But I do think that is the case when
the database actually holds confidential information like passwords. I
would be happy for text saying that if database has no confidential
information then confidentiality may be ignored, but if in most cases
I think it does include confidential information and then it needs to
be protected.

Anyways I think this is to point the fact out to iesg, they can decide
whether it is appropriate or not. Usually protocols have required
confidentiality when there are tihngs like passwords to be protected.

> 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:

The current security considerations section does not say anything
about the privacy issue, and I think this is big omission.

I am not sure if any real world requirement can be given, but I think
the security considerations section should point out that the database
has privacy related information stored in it and that should be taken
in to consideration when deciding how the database is protected, and
who has access to it.

The privacy issue also brings up new topic, namely the lifetime of the
data in the database. I do not know whether the entry stays in
database only during the conference, or whether it stays there
forever. For privacy information storing it long times can cause
problems. 
-- 
[email-masked]