Subject: [clue] proposed text for the security section of the framework document

From: "Roni Even" <[email-masked]>
Date: Tue, 8 Sep 2015 15:55:53 +0300

Hi,

This is my proposed text for section 15 of the framework document.

As for authenticating users note that the  a teleconference call starts with
SIP and the SIP mechanisms MUST be supported.

As for the xcard information content and what is sent to each participant
this is an application policy that can be based on an application level
authentication of the participant for example by asking the use to provide
his own credentials, (and not the endpoint)

Roni

15. Security Considerations

   There are several potential attacks related to telepresence, and
   specifically the protocols used by CLUE, in the case of conferencing
sessions, due to the natural involvement of multiple
   endpoints and the many, often user-invoked, capabilities provided
   by the systems.

   An MCU involved in a CLUE session can experience many of the same
   attacks as that of a conferencing system such as that enabled by
   the XCON framework [RFC5239]. Examples of attacks include the
   following: an endpoint attempting to listen to sessions in which
   it is not authorized to participate, an endpoint attempting to
   disconnect or mute other users, and theft of service by an
   endpoint in attempting to create telepresence sessions it is not
   allowed to create. Thus, it is RECOMMENDED that an MCU
   implementing the protocols necessary to support CLUE, follow the
   security recommendations specified in the conference control
   protocol documents.  In the case of CLUE, SIP is the conferencing
   protocol, thus the security considerations in [RFC4579] MUST be
   followed. . Other security issues related to MCUs are discussed in the
XCON framework [RFC5239]. 

The conference wide information including conference roster are similar to
the xCard information in CLUE 

and CLUE based implementations MUST considers those issues and the proposed
solutions in [RFC5239] security section.  

One primary security concern, surrounding the CLUE framework
   introduced in this document, involves securing the actual
   protocols and the associated authorization mechanisms.  These
   concerns apply to endpoint to endpoint sessions, as well as
   sessions involving multiple endpoints and MCUs. Figure 2 in
   section 5 provides a basic flow of information exchange for CLUE
   and the protocols involved.

   As described in section 5, CLUE uses SIP/SDP to establish the
   session prior to exchanging any CLUE specific information. Thus
   the security mechanisms recommended for SIP [RFC3261], including
   user authentication and authorization, MUST be supported. In
   addition, the media is based on RTP and thus existing RTP security
   mechanisms SHOULD be used, and DTLS/SRTP MUST be supported. 
   Media security is also discussed in [I-D.ietf-clue-signaling] and
   [I-D.ietf-clue-rtp-mapping]. Note that SIP call setup in done before any
CLUE specific information is available 

so the authentication and authorization are based on the SIP mechanisms. The
entity that will be authenticated may use the Endpoint identity or the
endpoint user identity; this is an application issue and not a CLUE specific
issue. 

   A separate data channel is established to transport the CLUE
   protocol messages. The contents of the CLUE protocol messages are
   based on information introduced in this document.  The CLUE data
   model [I-D.ietf-clue-data-model-schema] defines through an XML
   schema the syntax to be used. Some of the information which could
   possibly introduce privacy concerns is the xCard information as
   described in section 7.1.1.11 The decision about which xCard information
to send in the CLUE channel 

is an application policy for pint to point and multipoint calls base on the
authenticated identity that can be the endpoint identity or the user of the
endpoint, 

for example the telepresence multipoint application can authenticate a user
before starting a CLUE exchange with the telepresenec system and have a
policy per user. 

In addition, the (text)
   description field in the Media Capture attribute (section 7.1.1.7)
   could possibly reveal sensitive information or specific
   identities. The same would be true for the descriptions in the
   Capture Scene (section 7.3.1) and Capture Scene View (7.3.2)
   attributes.   One other important consideration for the
   information in the xCard as well as the description field in the
   Media Capture and Capture Scene View attributes is that while the
   endpoints involved in the session have been authenticated, there
   is no assurance that the information in the xCard or description
   fields is authentic.  Thus, this information MUST NOT be used to
  make any authorization decisions.

   While other information in the CLUE protocol messages does not
   reveal specific identities, it can reveal characteristics and
   capabilities of the endpoints.  That information could possibly
   uniquely identify specific endpoints.  It might also be possible
   for an attacker to manipulate the information and disrupt the CLUE
   sessions.  It would also be possible to mount a DoS attack on the
   CLUE endpoints if a malicious agent has access to the data
   channel.  Thus, it MUST be possible for the endpoints to establish
   a channel which is secure against both message recovery and
   message modification. Further details on this are provided in the
   CLUE data channel solution document.

   There are also security issues associated with the authorization
   to perform actions at the CLUE endpoints to invoke specific
   capabilities (e.g., re-arranging screens, sharing content, etc.).
   However, the policies and security associated with these actions
   are outside the scope of this document and the overall CLUE
   solution.

---

From: Christian Groves <[email-masked]>
Date: Wed, 9 Sep 2015 14:27:42 +1000

Hello Roni,

On 8/09/2015 10:55 PM, Roni Even wrote:
> As for authenticating users note that the  a teleconference call 
> starts with SIP and the SIP mechanisms MUST be supported.
>
> As for the xcard information content and what is sent to each 
> participant this is an application policy that can be based on an 
> application level authentication of the participant for example by 
> asking the use to provide his own credentials, (and not the endpoint)
>
> Roni
>
>    specifically the protocols used by CLUE, in the case of 
> conferencing sessions, due to the natural involvement of multiple
>    followed. . *Other security issues related to MCUs are discussed in 
> the XCON framework [RFC5239]. *
>
> *The conference wide information including conference roster are 
> similar to the xCard information in CLUE *
>
> *and CLUE based implementations MUST considers those issues and the 
> proposed solutions in [RFC5239] security section. *
>
> **
>
>
Would it be sufficient simply to leave the first sentence? The second 
sentence is confusing because RFC5239 doesn't use the term "conference 
wide" and xCard may be for a singe participant not conference wide. 
Actually do we need the text at all as the paragraph above refers to 
RFC5239 and recommendations specified in the conference control protocol 
documents? If we want to specifically capture xcard could we say 
something like "The use of xCard with potentially sensitive provides 
another reason to implement recommendations of section 11/[RFC 5239]."?

The other changes listed are OK. There's a few typos but Mark will 
probably pick those up.

Regards, Christian

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 14 Sep 2015 14:28:15 -0700

I agree with Roni's proposal for improvements to the security section, and Christian's suggestion to change a sentence from Roni's.  So with Christian's proposed change, the end of that paragraph would be, I think:

"In the case of CLUE, SIP is the conferencing  protocol, thus the security considerations in [RFC4579] MUST be followed. Other security issues related to MCUs are discussed in the XCON framework [RFC5239]. 
The use of xCard with potentially sensitive information provides another reason to implement recommendations of section 11/[RFC 5239]."

Do I have that right?

Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Wednesday, September 09, 2015 12:28 AM
> To: Roni Even; [email-masked]
> Subject: Re: [clue] proposed text for the security section of the framework
> document
> 
> Hello Roni,
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christian Groves <[email-masked]>
Date: Tue, 15 Sep 2015 09:36:58 +1000

Hello Mark,

That looks good to me.

Regards, Christian

---

From: "Roni Even" <[email-masked]>
Date: Wed, 16 Sep 2015 08:45:15 +0300

OK for me
Roni

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Tuesday, September 15, 2015 2:37 AM
To: Duckworth, Mark; Roni Even; [email-masked]
Subject: Re: [clue] proposed text for the security section of the framework
document

Hello Mark,

That looks good to me.

Regards, Christian

On 15/09/2015 7:28 AM, Duckworth, Mark wrote:
> I agree with Roni's proposal for improvements to the security section, and
Christian's suggestion to change a sentence from Roni's.  So with
Christian's proposed change, the end of that paragraph would be, I think:
>
> "In the case of CLUE, SIP is the conferencing  protocol, thus the security
considerations in [RFC4579] MUST be followed. Other security issues related
to MCUs are discussed in the XCON framework [RFC5239].
> The use of xCard with potentially sensitive information provides another
reason to implement recommendations of section 11/[RFC 5239]."
>> Subject: Re: [clue] proposed text for the security section of the 
>> framework document
>>
>> Hello Roni,
>>
>>>     followed. . *Other security issues related to MCUs are discussed 
>>> in the XCON framework [RFC5239]. *
>>>
>> sentence is confusing because RFC5239 doesn't use the term 
>> "conference wide" and xCard may be for a singe participant not conference
wide.
>> RFC5239 and recommendations specified in the conference control 
>> protocol documents? If we want to specifically capture xcard could we 
>> say something like "The use of xCard with potentially sensitive 
>> provides another reason to implement recommendations of section 11/[RFC
5239]."?