Subject: [clue] Ticket #33: Security for Framework document

From: Mary Barnes <[email-masked]>
Date: Mon, 13 Jan 2014 11:53:28 -0600

HI all,

I've had the longstanding action item to write some security text for the
framework. Below is what i have concocted.  Please review and post any
comments/concerns to the list, along with suggested text to address your
comments/concerns.

Mark will fold this into the next version of the framework document.

Thanks,
Mary.

   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.

   A middle box 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 [RFC 6503].
   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 a middle box 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
   default conferencing protocol, thus the security considerations in RFC
4579 SHOULD be
   followed.

   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 middle boxes.
   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 [RFC 3261], including user authentication and
authorization,
   SHOULD be followed. In addition, the media is based on RTP and thus
   existing RTP security mechanisms, such as DTLS/SRTP, MUST be supported.

   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, which is represented by an XML schema for this
information
   defined in the CLUE data model [ref]. Some of the information which
could possibly
   introduce privacy concerns is the xCard information as described in
section x.
   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 Entry (7.3.2) attributes.
   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: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Jan 2014 15:24:53 -0500

This seems pretty good. I expect there will be questions (somewhere) on 
the choice of SHOULD vs. MUST, so we should be very careful to have 
justification for such choices.

Also, requiring the value of attacking the clue channel, while the 
things you describe are obvious points of high interest, even the more 
basic information could provide useful information to some attackers. If 
nothing else, that information provides a very detailed "footprint" that 
can be used to narrow down the identity of the endpoint. For instance, 
it will probably be very easy to look at an advertisement and discern 
the manufacturer and particular configuration of equipment at that 
endpoint. That could be helpful to narrow down the identity of the 
participants.

Of course the same precautions that protect the vcards protect all this 
other stuff too.

	Thanks,
	Paul

On 1/13/14 12:53 PM, Mary Barnes wrote:
> HI all,
>
> I've had the longstanding action item to write some security text for
> the framework. Below is what i have concocted.  Please review and post
> any comments/concerns to the list, along with suggested text to address
> your comments/concerns.
>
>     necessary to support CLUE, follow the security recommendations
> specified in the
>     default conferencing protocol, thus the security considerations in
> RFC 4579 SHOULD be
>     followed.
>
>     apply to endpoint to endpoint sessions, as well as sessions
> involving multiple
>     Figure 2 in section 5 provides a basic flow of information exchange
> for CLUE
>     As described in section 5, CLUE uses SIP/SDP to establish the
> session prior to
>     A separate data channel is established to transport the CLUE
> protocol messages.
>     It might also be possible for an attacker to manipulate the
> information and disrupt
>     Thus, It MUST be possible for the endpoints to establish a channel
> which is
>     secure against both message recovery and message modification.
> Further details
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Christian Groves <[email-masked]>
Date: Mon, 20 Jan 2014 12:38:28 +1100

Hello Mary,

This looks pretty good. Maybe one thing to note is the user is 
authenticated (i.e. the UA) any information provided about the 
participants in the conference described by CLUE may not be. For 
example: as a participant I may provide my xCard information which is 
carried by CLUE and assert that I'm the president. There may not be any 
sanity check of such information.

In the case of an MCU it may pass on CLUE information regarding the 
contents of the media in good faith. It has no knowledge of what is 
actually depicted by the media.

Regards, Christian

On 14/01/2014 7:24 AM, Paul Kyzivat wrote:
> This seems pretty good. I expect there will be questions (somewhere) 
> on the choice of SHOULD vs. MUST, so we should be very careful to have 
> basic information could provide useful information to some attackers. 
> If nothing else, that information provides a very detailed "footprint" 
> that can be used to narrow down the identity of the endpoint. For 
> instance, it will probably be very easy to look at an advertisement 
> and discern the manufacturer and particular configuration of equipment 
> at that endpoint. That could be helpful to narrow down the identity of 
> the participants.
>
> Of course the same precautions that protect the vcards protect all 
> this other stuff too.
>
>     Thanks,
>     Paul
>