Subject: Re: [clue] Finishing up Security Considerations for protocol

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 13 May 2016 13:59:51 +0200

Dear Paul and others, 

I just submitted a revised version of the protocol draft, in which I tried to sketch a thorough Security Considerations section.
Please comment on that (the Security Section, which is also copy-pasted below) and on the document as a whole.

Thank you once again for your input and comments,

Simon

***************************************** START OF SECURITY CONSIDERATIONS SECTION **********************************************
As a general consideration, we remark that the CLUE framework (and
   related protocol) has been conceived at the outset by embracing the
   security-by-design paradigm.  This entails that a number of
   requirements have been identified and properly standardized as
   mandatory within the entire set of documents associated with the CLUE
   architecture.  Among such requirements we mention the following: (i)
   always leave space for criptography and authentication; (ii) get sure
   that all sensitive fields can be protected; (iii) envisage mutual
   authentication between CLUE endpoints; (iv) envisage the presence of
   authorization mechanisms; (v) envisage the presence of native defense
   mechanisms against malicious activities such as eavesdropping,
   selective modification, deletion, replay (and related combinations
   thereof).  Hence, security of the single components of the CLUE
   solution cannot be evaluated independently of the integrated view of
   the final architecture.

   Coming to the details of the CLUE protocol, this is an application-
   level protocol allowing a Media Producer and a Media Consumer to
   negotiate a variegated set of parameters associated with the
   establishment of a telepresence session.  This unavoidably exposes a
   CLUE-enabled telepresence system to a number of potential threats,
   most of which are extensively discussed in the framework document
   [I-D.ietf-clue-framework].  The security considerations section of
   the mentioned document actually discusses issues associated with the
   setup and management of a telepresence session both in the basic case
   involving two CLUE endpoints acting, respectively, as MP and MC, and
   in the more advanced scenario envisaging the presence of an MCU.

   The framework document also mentions that the information carried
   within CLUE protocol messages might contain sensitive data, which
   SHOULD hence be accessed only by authenticated endpoints.  Security
   issues associated with the CLUE data model schema are discussed in
   [I-D.ietf-clue-data-model-schema].

   There is indeed some piece of extra information carried by the CLUE
   protocol which is not associated with the standard data model and
   which exposes information that might be of concern.  This is
   primarily what gets exchanged during the options negotiation phase.
   From the Clue Participant state machine, we know that in the OPTIONS
   state both parties agree on the version and on the options to be used
   in the subsequent CLUE messages exchange phase.  A malicious
   participant might either try to retrieve a detailed footprint of a
   specific CLUE protocol implementation during this initial setup
   phase, or force the communicating party to stick to a non-up-to-date
   version of the protocol which they know how to break.  Indeed,
   exposing all of the supported versions and options could conceivably
   leak a bit of information about the specific implementation of the
   protocol.  In theory an implementation could choose not to announce
   all of the versions it supports if it wants to avoid such leakage,
   though at the expenses of interoperability.  With respect to the
   above considerations, we nonetheless remark that the OPTIONS state is
   only reached after the CLUE data channel has been successfully set
   up.  This ensures that only authenticated parties can exchange
   OPTIONS and related OPTIONS RESPONSE messages and hence drastically
   reduces the attack surface which is exposed to malicious parties.

   Coming to the content of the protocol messages themselves, the CLUE
   framework clearly states the requirement to protect against threats
   deriving from the presence of a malicious agent capable to gain
   access to the CLUE data channel.  Such a requirement is met by the
   CLUE data channel solution described in [I-D.ietf-clue-datachannel],
   which ensures protection from both message recovery and message
   tampering.  With respect to this last point, we once again remark
   that any implementation of the CLUE protocol which claims to be
   compliant with the CLUE specification MUST rely on the exchaning of
   messages which flow on top of a reliable and ordered SCTP over DTLS
   transport channel connecting two CLUE Participants.

   As a final consideration, we remark that policy-based management of a
   CLUE-compliant telepresence architecture, though not in the scope of
   the CLUE WG charter, can easily be realized.  To the purpose, common
   Role-Based Access Control (RBAC) approaches can be leveraged.  In
   RBAC, the following elements are identified: (i) Users; (ii) Roles;
   (iii) Objects; (iv) Operations; (v) Permissions.  For all of the
   above elements, a direct mapping exists onto the main CLUE entities.
   As an example, RBAC objects map onto CLUE data model objects and RBAC
   operations map onto CLUE protocol operations.  Future documents can
   define an RBAC framework for CLUE, by first focusing on the
   definition of roles and then specifying the needed permission policy
   sets and role policy sets (used to associate policy permission sets
   with specific roles).  With these policies in place, access to
   information compliant with the CLUE data model can be appropriately
   controlled.  As far as assigning users to roles, the Users in the
   RBAC model relate directly to the <people> element in the CLUE
   object.  The <people> element is comprised of <person> elements
   representing a specific user in the telepresence system.  Each
   <person> element contains a 'personID' attribute acting as a unique
   identifier and a <personType> element describing their role in the
   CLUE session ("presenter", "timekeeper", "attendee", "minute taker",
   "translator", "chairman", "vice-chairman") .  Thus, each authorized
   user can be associated with a well-defined role in the RBAC model.

***************************************** END OF SECURITY CONSIDERATIONS SECTION **********************************************

> On 19/apr/2016, at 20:07, Paul Kyzivat <[email-masked]> wrote:
> 
> The protocol needs to have a Security Considerations section before it can progress. That is the main gating item at this point.
> 
> This should be pretty simple. The following are my thoughts about what should be in it:
> 
> - it should reference the security considerations in the framework. They cover many important issues and those probably don't need to be restated as long as they are referenced.
> 
> - it should reference the security considerations in the data model. That document has most of the critical data to be concerned with.
> 
> - a reference to the security considerations in the clue-datachannel draft will cover the protection of the content of the protocol messages.
> 
> - There probably should be a brief discussion of the extra data in the protocol (not in the data model) that exposes information that might be of concern. I think this is primarily in the options negotiation: exposing all the versions and options supported could conceivably leak a bit of info about the specific software. In theory an implementation could choose not to announce all the versions it supports if it wants to avoid such leakage, though it would reduce interoperability. And of course it will only be relevant when there are multiple versions and options.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
> 

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 May 2016 10:27:26 -0400

On 5/13/16 7:59 AM, Simon Pietro Romano wrote:
> Dear Paul and others,
>
> I just submitted a revised version of the protocol draft, in which I
> tried to sketch a thorough Security Considerations section.

I saw it. This seems to cover the need to address security in the document.

Where did the last paragraph (re RBAC) come from? ISTM that this is 
speculative - not anything that the WG has discussed. I'd like to hear 
what others think about this.

	Thanks,
	Paul

> ***************************************** START OF SECURITY
> CONSIDERATIONS SECTION **********************************************
> ***************************************** END OF SECURITY CONSIDERATIONS
> SECTION **********************************************
>
>
>
>
>
>> On 19/apr/2016, at 20:07, Paul Kyzivat <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> The protocol needs to have a Security Considerations section before it
>> can progress. That is the main gating item at this point.
>>
>> - it should reference the security considerations in the framework.
>> They cover many important issues and those probably don't need to be
>> restated as long as they are referenced.
>>
>> - it should reference the security considerations in the data model.
>> That document has most of the critical data to be concerned with.
>>
>> - a reference to the security considerations in the clue-datachannel
>> draft will cover the protection of the content of the protocol messages.
>>
>> - There probably should be a brief discussion of the extra data in the
>> protocol (not in the data model) that exposes information that might
>> be of concern. I think this is primarily in the options negotiation:
>> exposing all the versions and options supported could conceivably leak
>> a bit of info about the specific software. In theory an implementation
>> could choose not to announce all the versions it supports if it wants
>> to avoid such leakage, though it would reduce interoperability. And of
>> course it will only be relevant when there are multiple versions and
>> options.
>>
>> Thanks,
>> Paul
>>
>> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 May 2016 11:33:28 -0400

Simon,

idnits returns 4 errors and 8 warnings. Some are bogus, but some are 
valid. Nothing should be hard to fix.

	Thanks,
	Paul

---

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 13 May 2016 18:12:28 +0200

> Where did the last paragraph (re RBAC) come from? ISTM that this is speculative - not anything that the WG has discussed. I'd like to hear what others think about this.

You’re right. This actually comes from far away in the past! It digs its roots in the disucssions we had at the time of the XCON WG and is in fact something that I added to the CCMP document, too. 
I personally bend towards role-based access control when it comes to policy-based managament and I thought this might be a useful piece of information for an interested reader. Though, I agree with
you that we never discussed this within CLUE (which is btw clearly stated in the document). If you deem it useless, we can just remove that paragraph.

Thanks,

Simon

                   				        _\\|//_
                          			       ( O-O )

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
              			                     oooO
 ~~~~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                      (_/

---

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 13 May 2016 18:13:59 +0200

You’re right. I’ll make a careful check with idnits before submitting version -09 of the document (which will happen after we receive WG comments and suggestions).

Cheers,

Simon

> On 13 May 2016, at 17:33, Paul Kyzivat <[email-masked]> wrote:
> 
> Simon,
> 
> idnits returns 4 errors and 8 warnings. Some are bogus, but some are valid. Nothing should be hard to fix.
> 
> 	Thanks,
> 	Paul
> 

                   				        _\\|//_
                          			       ( O-O )

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 May 2016 12:20:14 -0400

> you that we never discussed this within CLUE (which is btw clearly stated in the document). If you deem it useless, we can just remove that paragraph.

Lets wait and see what others (including Alissa) think.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 18 May 2016 10:50:58 +1000

Hello Simon and Paul,

In general the text looks OK to me. I've proposed some editorial updates 
below mainly to remove things like "we".

1st Paragraph replace sentence starting with "Among such 
requirements..." with

"Requirements include: (i) the use of cryptography and authentication; 
(ii) protection of all sensitive fields; (iii) mutual authentication 
between CLUE endpoints; (iv) the presence of authorization mechanisms; 
(v) the presence of native defence mechanisms against malicious 
activities such as eavesdropping, selective modification, deletion, 
replay (and related combinations thereof).

2nd paragraph 1st sentence reword: "The CLUE protocol is an 
application-level protocol allowing a Media Producer and a Media 
Consumer ..."

4th paragraph proposed reword:

There is extra information carried by the CLUE protocol which is not 
associated with the CLUE data model schema and which exposes information 
that might be of concern.  This information is primarily exchanged 
during the options negotiation phase. In the Clue Participant state 
machine "Option State", both parties agree on the version and on the 
options to be used in the subsequent CLUE messages exchange phase.  A 
malicious participant might either try to retrieve a detailed footprint 
of a specific CLUE protocol implementation during this initial setup 
phase, or force the communicating party to use a non-up-to-date version 
of the protocol which they know how to break.  Indeed, exposing all of 
the supported versions and options could conceivably leak information 
about the specific implementation of the protocol.  In theory an 
implementation could choose not to announce all of the versions it 
supports if it wants to avoid such leakage, though at the expenses of 
interoperability.  With respect to the above considerations, it is noted 
that the OPTIONS state is only reached after the CLUE data channel has 
been successfully set up.  This ensures that only authenticated parties 
can exchange OPTIONS and related OPTIONS RESPONSE messages and hence 
drastically reduces the attack surface which is exposed to malicious 
parties.

5th paragraph proposed reword:

The CLUE framework clearly states the requirement to protect CLUE 
protocol messages against threats deriving from the presence of a 
malicious agent capable to gain access to the CLUE data channel. Such a 
requirement is met by the CLUE data channel solution described in 
[I-D.ietf-clue-datachannel], which ensures protection from both message 
recovery and message tampering.  With respect to this last point, any 
implementation of the CLUE protocol compliant with the CLUE 
specification MUST rely on the exchange of messages which flow on top of 
a reliable and ordered SCTP over DTLS transport channel connecting two 
CLUE Participants.

Last paragraph: With respect to the last paragraph I'm abit ambivalent 
on it. It doesn't seem to hurt but if we do leave it in then we should 
probably add something about the aspect of an endpoint. I assume that 
its the endpoint generating protocol messages not a user. The owner of 
an endpoint may in fact not be one of the <people> in a conference.

Regards, Christian