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

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Jul 2016 14:32:39 -0400

Simon,

Can we get this done now? I believe Alissa is simply waiting for the 
remaining few changes we already discussed. Then we can wrap this up.

	Thanks,
	Paul

On 5/13/16 12:20 PM, Paul Kyzivat wrote:
> On 5/13/16 12:12 PM, Simon Pietro Romano wrote:
>>> 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.
>
> Lets wait and see what others (including Alissa) think.
>
>     Thanks,
>     Paul
>
>> Thanks,
>>
>> Simon
>>
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>> 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]
>>>>> <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.
>>>>>
>>>>> 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] <mailto:[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]
>>>> <mailto:[email-masked]>
>>>>
>>>>    <<Molti mi dicono che lo scoraggiamento è l'alibi degli
>>>>    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>>>>                                    oooO
>>>>  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>                 \ (            (   )
>>>>                                  \_)          ) /
>>>>                                                                       (_/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>                                            _\\|//_
>>                                              ( 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~~~~~~~~~~~~~~~~~~~~~~~
>>                                      \ (            (   )
>>                                               \_)          ) /
>>                                                                       (_/
>>
>>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue