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

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 6 Feb 2014 09:38:28 -0800

Hello Mary,

At the interim meeting I think you said you want to make some edits to your initial security section text, before including it in the framework.  Should I wait for that, before adding this into the Security Considerations in the framework?

Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Sunday, January 19, 2014 8:38 PM
> To: [email-masked]
> Subject: Re: [clue] Ticket #33: Security for Framework document
> 
> 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
> > 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.
> >>
> >> 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.
> >>
> >>
> >>
> >> _______________________________________________
> >> clue mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/clue
> >>
> >
> > _______________________________________________
> > clue mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/clue
> >
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Mary Barnes <[email-masked]>
Date: Fri, 7 Feb 2014 13:20:01 -0600

Below please find, the updated text for the security considerations that
incorporates the comments made by Paul and Christian.   I did not add
anything new with regards to Christian's point about MCUs passing media
with no knowledge of content. That's not unique to CLUE - it's the same for
any middle box that forwards media in the form of video.

I think it's in good enough shape to add the framework now.  We can of
course make additional changes later.

Thanks,
Mary.

   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
   MUST 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.   One other important
consideration for
   the information in the xCard as well as the description field in the
Media Capture
   and Capture Scene Entry 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 SHOULD not be used to make any authorization
decisions
   and the participants in the sessions SHOULD be made aware of this.

   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: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Feb 2014 15:14:31 -0500

This sounds good to me.

	Thanks,
	Paul

On 2/7/14 2:20 PM, Mary Barnes wrote:
> with no knowledge of content. That's not unique to CLUE - it's the same
> for any middle box that forwards media in the form of video.
>
>     default conferencing protocol, thus the security considerations in
> RFC 4579
>     MUST be followed.
>
>     Figure 2 in section 5 provides a basic flow of information exchange
> for CLUE
>     and Capture Scene Entry attributes is that while the endpoints
> involved in the session
>     have been authenticated, there is no assurance that the information
> in the xCard
>     While other information in the CLUE protocol messages does not
> reveal specific
>     Thus, It MUST be possible for the endpoints to establish a channel
> which is

---

From: Christian Groves <[email-masked]>
Date: Mon, 10 Feb 2014 10:39:12 +1100

Hello Mary,

With regards to passing media with no knowledge of the content there is 
an aspect that IS unique to CLUE. CLUE actually indicates metadata about 
the content of the media. Traditional MCUs establish the media without 
asserting any knowledge of the media content. A CLUE MCU establishes the 
media and asserts to know something about the content of the media (i.e. 
through CLUE attributes). In the case of an MCC this will be information 
from the sources. As a consumer of traditional media about all I expect 
is that the media comes from where I think it does. However in a CLUE 
session i'll know the size, language, description, participants etc. 
This data could be manipulated to case "issues" with capture selection 
and rendering etc. An MCU would have to make a decision on whether the 
sources are trusted before passing the content information forward.

This is probably covered in paragraph 6 below where it says " /It might 
also be//
//   possible for an attacker to manipulate the information and disrupt //
//   the CLUE sessions"./ I think that applies to almost any protocol. 
Although I don't think it really highlights the MCU's role as an 
aggregation point for CLUE information in a session.

Regards, Christian

On 8/02/2014 6:20 AM, Mary Barnes wrote:
> Below please find, the updated text for the security considerations 
> that incorporates the comments made by Paul and Christian.   I did not 
> add anything new with regards to Christian's point about MCUs passing 
> media with no knowledge of content. That's not unique to CLUE - it's 
> the same for any middle box that forwards media in the form of video.
>
>    the information in the xCard as well as the description field in 
> the Media Capture