Re: [clue] Finishing up Security Considerations for protocol

[Alissa Cooper <[e-mail]>]

I agree with Christian’s suggestions.

Personally I would leave out the RBAC paragraph as it seems aspirational and there is nothing specifically in the protocol to support it.

I will do a more thorough review when I get the publication request.

Alissa

> On May 17, 2016, at 5:50 PM, Christian Groves <[e-mail]> wrote:
> 
> 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
> 
> 
> On 14/05/2016 12:27 AM, Paul Kyzivat wrote:
>> 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.
>>> Please comment on that (the Security Section, which is also copy-pasted
>>> below) and on the document as a whole.
>> 
>> 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
>> 
>>> 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 <[e-mail]
>>>> <mailto:[e-mail]>> 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
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/clue
>>>> 
>>> 
>>>                            _\\|//_
>>>                                 ( O-O )
>>>   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>>>                    Simon Pietro Romano
>>>              Universita' di Napoli Federico II
>>>                     Computer Engineering Department
>>>             Phone: [phone] -- Fax: [phone]
>>>                                           e-mail: [e-mail]
>>> <mailto:[e-mail]>
>>> 
>>>    <<Molti mi dicono che lo scoraggiamento è l'alibi degli
>>>    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>>>                                    oooO
>>>  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>>>                 \ (            (   )
>>>                                  \_)          ) /
>>> (_/
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> clue mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/clue
> 
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue