Subject: [clue] AD evaluation: draft-ietf-clue-framework-22

From: Alissa Cooper <[email-masked]>
Date: Fri, 3 Jul 2015 11:28:14 -0700

I have reviewed this document in preparation for IETF LC and I have some comments and questions I'd like to see resolved before issuing the last call. I've also listed some nits further below that should be resolved in the next revision of the document.

Overall, the amount of complexity that this framework supports in terms of the number of configuration choices that can be provided and consumed is daunting. I know the WG is already well down the path towards finishing this off so I'm not suggesting changes in this regard, but I do think folks should be prepared for questions about the trade-off between flexibility and implementability that may arise during IETF LC or IESG evaluation.

Substantive comments and questions:

= Section 3 =
Why are these definitions not necessarily consistent with the definitions in RFC 7262 (e.g., Endpoint)? Why not just rely on the definitions in that document for terms being re-used? I know there was a conclusion that strict alignment with the taxonomy doc was not necessary, but it seems like at least the CLUE docs should be internally consistent.

= Section 7.1.1.10 =
I think this section (and to some extent the one that follows) require a more thorough explanation to justify how it is that sending a lot of detailed information about the people involved in a telepresence session actually helps the endpoints decide how to arrange the media in the session. I understand that some (limited) information is useful for display purposes, but this section provides really broad leeway for endpoints to send a lot of information about individual participants without a thoroughgoing justification of how policies are built that act on such detailed information.

On the other hand, there are some data fields I would have expected to possibly be useful for these kinds of policies, like device type or room type or even device name, but it's not clear how endpoints are supposed to communicate those, if at all (stuff them into an xCard somewhow?). What is the story as far as those kinds of attributes go?

= Section 7.2.1.1 =
Just because the syntax of the MaxCaptures definition theoretically allows for it to be set to <=1 does not mean that semantic should necessarily be allowed in the protocol. I don't understand the case where sending <=1 should be considered valid -- why have an MCC with zero captures in it? It seems like =1 and <=N where N>1 are the only valid values here.

= Section 15 =
"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."

The specific documents need to be listed here, assuming RFC 4579 is not the only one to be mentioned.

"Thus
   the security mechanisms recommended for SIP [RFC3261], including
   user authentication and authorization, SHOULD be followed."

Given that implementations will need to be updated to support CLUE, what is the rationale for having user authentication and authorization be optional? What are the cases where allowing an unauthenticated or unauthorized participant to join a telepresence session would be considered acceptable?

"In
   addition, the media is based on RTP and thus existing RTP security
   mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported.
   Media security is also discussed in [I-D.ietf-clue-signaling] and
   [I-D.ietf-clue-rtp-mapping]."

I think it's worth pointing out in this document that DTLS/SRTP is required to use for CLUE-controlled m-lines. Also, I just did a quick skim of draft-ietf-clue-rtp-mapping and didn't see anything in there about media security.

"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.  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."

I don't think it's enough to point out that sensitive data can be sent back and forth with CLUE and that it shouldn't be used for authorization decisions. Is there some guidance that can be given about minimizing the amount and sensitivity of data to be sent? Are there certain xCard fields that endpoints should avoid sending? Some of this is obviously dependent on context and whether the participants in a conference know this information about each other already, but it's still worth mentioning how to mitigate the risks of sharing more data or more sensitive data than is necessary for the purposes of supporting a telepresence session. This might imply additional text in 7.1.1.10 as well.

"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 no details about how the data channel is secured in draft-ietf-clue-datachannel (which should be cited here if it's going to be referenced). Nor are the details in draft-ietf-rtcweb-data-channel, but rather they are in draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-security. 

Furthermore, the details provided in draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-security explain the situation for rtcweb, where the endpoints rely on identity providers to authenticate each others' identities. IdPs are not specifically included in the CLUE architecture and, as noted above, the SIP authentication mechanisms are optional -- so how is it that the CLUE data channel is actually secured against an active MITM?

Nits:
There are a bunch of uses of normative MAY in this document that don't really fit the RFC 2119 usage of the term (i.e., are not actually protocol options). I've pointed them out below along with other nits.

= Section 3 =
"The spatial region represented by a Capture
   Scene MAY correspond to a real region in physical space, such as a
   room."

I don't think normative language is necessary here. s/MAY/may/

s/[RFC4353] like Mixer/[RFC4353]-like Mixer/

= Section 4 =
s/it should be stressed that its use in an implementation/it should be stressed that their use in an implementation/

= Section 5 =
"Also, the Consumer
   MAY use the information provided to tailor the SDP it is going to
   send during any following SIP offer/answer exchange, and its
   reaction to SDP it receives in that step."
   
I don't think normative language is necessary here. s/MAY/may/

"For example, if both sides decide to upgrade the call from a single screen to a
   multi-screen call and more bandwidth is required for the additional
   video channels compared to what was previously negotiated using
   offer/answer, a new O/A exchange is REQUIRED."
   
I don't think normative language is necessary here since this is just an example. s/REQUIRED/required/

= Secton 7.1.1.4 =
s/High dynamic/Highly dynamic/

= Section 7.1.1.11 =
Not everyone considers "chairman" to be a gender-neutral term. You might want to consider "chair" and "vice-chair" instead.

In general it's hard for me to believe that there is much of an interoperability gain from specifying titles in this level of detail, rather than just allowing advertisers to specify all of their own -- is there some compelling need to specify this set of values initially?

= Section 7.1.1.12 =
s/no assumptions regarding relative important/no assumptions regarding relative importance/

= Section 7.1.1.13 =
s/the video Capture MAY contain speech to text information/the video Capture may contain speech to text information/

= Section 7.2.1.1 =
s/MaxCaptures MAY be set to one/MaxCaptures may be set to one/

= Section 10 =
s/Optimized implementations MAY speed up the reaction to the
   offer/answer exchange/Optimized implementations may speed up the reaction to the
   offer/answer exchange/

= Section 10.1 =
s/if the Consumer is an MCU, it MAY choose to receive/if the Consumer is an MCU, it may choose to receive/

s/user choice (for instance, selection of a new layout) MAY result/user choice (for instance, selection of a new layout) may result

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 8 Jul 2015 05:23:55 -0700

Thanks for the feedback Alissa.  I will be a bit slow in responding to all the points, due to other commitments.

Christian, can you respond to questions about section 7.1.1.10 and 7.2.1.1?

Can anybody help with the Security section? as I don't have much expertise in that area.

Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Alissa Cooper
> Sent: Friday, July 03, 2015 2:28 PM
> To: [email-masked]
> Subject: [clue] AD evaluation: draft-ietf-clue-framework-22
> 
> I have reviewed this document in preparation for IETF LC and I have some
> comments and questions I'd like to see resolved before issuing the last call.
> I've also listed some nits further below that should be resolved in the next
> revision of the document.
> 
> Overall, the amount of complexity that this framework supports in terms of
> the number of configuration choices that can be provided and consumed is
> daunting. I know the WG is already well down the path towards finishing this
> off so I'm not suggesting changes in this regard, but I do think folks should be
> prepared for questions about the trade-off between flexibility and
> implementability that may arise during IETF LC or IESG evaluation.
> 
> Why are these definitions not necessarily consistent with the definitions in
> RFC 7262 (e.g., Endpoint)? Why not just rely on the definitions in that
> document for terms being re-used? I know there was a conclusion that strict
> alignment with the taxonomy doc was not necessary, but it seems like at
> least the CLUE docs should be internally consistent.
> 
> = Section 7.1.1.10 =
> I think this section (and to some extent the one that follows) require a more
> thorough explanation to justify how it is that sending a lot of detailed
> information about the people involved in a telepresence session actually
> helps the endpoints decide how to arrange the media in the session. I
> understand that some (limited) information is useful for display purposes,
> but this section provides really broad leeway for endpoints to send a lot of
> information about individual participants without a thoroughgoing
> justification of how policies are built that act on such detailed information.
> 
> On the other hand, there are some data fields I would have expected to
> possibly be useful for these kinds of policies, like device type or room type or
> even device name, but it's not clear how endpoints are supposed to
> communicate those, if at all (stuff them into an xCard somewhow?). What is
> the story as far as those kinds of attributes go?
> 
> = Section 7.2.1.1 =
> Just because the syntax of the MaxCaptures definition theoretically allows
> for it to be set to <=1 does not mean that semantic should necessarily be
> allowed in the protocol. I don't understand the case where sending <=1
> should be considered valid -- why have an MCC with zero captures in it? It
> seems like =1 and <=N where N>1 are the only valid values here.
> 
> = Section 15 =
> Given that implementations will need to be updated to support CLUE, what is
> the rationale for having user authentication and authorization be optional?
> What are the cases where allowing an unauthenticated or unauthorized
> participant to join a telepresence session would be considered acceptable?
> 
> "In
> I think it's worth pointing out in this document that DTLS/SRTP is required to
> use for CLUE-controlled m-lines. Also, I just did a quick skim of draft-ietf-clue-
> rtp-mapping and didn't see anything in there about media security.
> 
> I don't think it's enough to point out that sensitive data can be sent back and
> forth with CLUE and that it shouldn't be used for authorization decisions. Is
> there some guidance that can be given about minimizing the amount and
> sensitivity of data to be sent? Are there certain xCard fields that endpoints
> should avoid sending? Some of this is obviously dependent on context and
> whether the participants in a conference know this information about each
> other already, but it's still worth mentioning how to mitigate the risks of
> sharing more data or more sensitive data than is necessary for the purposes
> of supporting a telepresence session. This might imply additional text in
> 7.1.1.10 as well.
> 
> There are no details about how the data channel is secured in draft-ietf-clue-
> datachannel (which should be cited here if it's going to be referenced). Nor
> are the details in draft-ietf-rtcweb-data-channel, but rather they are in draft-
> ietf-rtcweb-security-arch and draft-ietf-rtcweb-security.
> 
> Furthermore, the details provided in draft-ietf-rtcweb-security-arch and
> draft-ietf-rtcweb-security explain the situation for rtcweb, where the
> endpoints rely on identity providers to authenticate each others' identities.
> IdPs are not specifically included in the CLUE architecture and, as noted
> above, the SIP authentication mechanisms are optional -- so how is it that the
> CLUE data channel is actually secured against an active MITM?
> 
> 
> Nits:
> There are a bunch of uses of normative MAY in this document that don't
> really fit the RFC 2119 usage of the term (i.e., are not actually protocol
> options). I've pointed them out below along with other nits.
> 
> = Section 3 =
> s/it should be stressed that its use in an implementation/it should be
> stressed that their use in an implementation/
> 
> = Section 5 =
> "Also, the Consumer
> Not everyone considers "chairman" to be a gender-neutral term. You might
> want to consider "chair" and "vice-chair" instead.
> 
> In general it's hard for me to believe that there is much of an interoperability
> gain from specifying titles in this level of detail, rather than just allowing
> advertisers to specify all of their own -- is there some compelling need to
> specify this set of values initially?
> 
> = Section 7.1.1.12 =
> s/the video Capture MAY contain speech to text information/the video
> Capture may contain speech to text information/
> 
> = Section 7.2.1.1 =
> s/user choice (for instance, selection of a new layout) MAY result/user choice
> (for instance, selection of a new layout) may result
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christian Groves <[email-masked]>
Date: Tue, 14 Jul 2015 15:57:37 +1000

Hello Alissa and Mark,

Please see my comments below.

Regards, Christian

>> justification of how policies are built that act on such detailed information.
[CNG] Just because xCard format is used it doesn't mean that an endpoint 
has to send data for every field vCard has defined. The usage of the 
xCard was chosen because it is a standard way of sending name, title, 
address information etc and is fairly commonly used. It's up to the 
endpoints to determine how much they send. We didn't want to mandate 
certain fields (other than the mandatory xCard) ones because that may 
limit innovative applications.

Displaying information is certainly one possibility e.g. displaying the 
names of the people in each capture. Being able to view organisational 
information about people e.g. sales manager, CEO is also valuable beyond 
a name.

Another application would being able to browse people's photos provided 
by xCard to associate people faces to names.

Logging is another application - the endpoint logs the contact details 
of who was in the conference which makes it easy to send an email, im, 
voice call to a person.

Capture selection a endpoint could select select to receive captures 
from certain people (e.g. your manager) or a location (e.g. head office).

Communication information - my endpoint could tell me that the person in 
the capture has a preference to talk German based on their xCard 
information.

In face to face meetings exchanging business cards is something that is 
done prior to meetings starting and enhances the interpersonal 
relationships. The intention is that using xCards facilitates a similar 
process for telepresense, i.e. a "being there experience".

>> the story as far as those kinds of attributes go?
[CNG] CLUE has been defined in a device agnostic manner by using 
scenes/captures etc. Rather than saying a device is a tablet, smart 
phone, laptop or dedicated room endpoint, scenes/captures and encodings 
describe the capabilities of the endpoints. A receiving endpoint then 
makes its decisions based on these capabilities.
With respect to room type again CLUE is agnostic, the capture scene 
concept is used to describe the "room". The scene information attribute 
can provide a description.

>> seems like =1 and <=N where N>1 are the only valid values here.
[CNG] The data model defines MaxCaptures as "xs:positiveInteger" which 
excludes zero. So an endpoint can't send "0" as a maxcaptures value. 
"<=1" is allowed because it allows an endpoint to either send a source 
capture (i.e. 1) or not (i.e. 0).

Take the following example:
         | Capture Scene #1      |                                 |
         +-----------------------|---------------------------------+
         | VC1                   | Description=Left                |
         | VC2                   | Description=Centre              |
         | VC3                   | Description=Right               |
         | CSV(VC1,VC2,VC3)      |                                 |
         +=======================+=================================+
         | Capture Scene #2      |                                 |
         +-----------------------|---------------------------------+
         | VC4                   | Description=Left                |
         | VC5                   | Description=Right               |
         | CSV(VC4,VC5)          |                                 |
         +=======================+=================================+
         | Capture Scene #3      |                                 |
         +-----------------------|---------------------------------+
         | MCC1(VC1,VC4)         | SynchronisationID=1             |
         |                       | MaxCaptures=1                   |
         | MCC2(VC2,VC5)         | SynchronisationID=1             |
         |                       | MaxCaptures=1                   |
         | MCC3(VC3)             | SynchronisationID=1             |
         |                       | MaxCaptures<=1 |
MCC3 utilising MaxCaptures<=1 would allow VC3 not to be sent when 
capture related to Capture Scene #1 were sent.

---

From: Ron Even <[email-masked]>
Date: Sun, 19 Jul 2015 11:53:19 +0300

Hi Alissa,
See inline
Roni

On Fri, Jul 3, 2015 at 9:28 PM, Alissa Cooper <[email-masked]> wrote:

> comments and questions I'd like to see resolved before issuing the last
> call. I've also listed some nits further below that should be resolved in
> the next revision of the document.
>
> daunting. I know the WG is already well down the path towards finishing
> this off so I'm not suggesting changes in this regard, but I do think folks
> should be prepared for questions about the trade-off between flexibility
> and implementability that may arise during IETF LC or IESG evaluation.
>
> Why are these definitions not necessarily consistent with the definitions
> in RFC 7262 (e.g., Endpoint)? Why not just rely on the definitions in that

RE: We had a definition document
https://www.ietf.org/archive/id/draft-wenger-clue-definitions-02.txt that
tried to capture the terminology for telepresence systems, we decided that
it should not be a separte document and moved the content to the
framework, the other documents should be consistent with it

>
> = Section 7.1.1.10 =
> I think this section (and to some extent the one that follows) require a
> more thorough explanation to justify how it is that sending a lot of
> detailed information about the people involved in a telepresence session
> actually helps the endpoints decide how to arrange the media in the
> session. I understand that some (limited) information is useful for display
> purposes, but this section provides really broad leeway for endpoints to
> send a lot of information about individual participants without a
> thoroughgoing justification of how policies are built that act on such
> detailed information.
>

RE:  By Christian

> possibly be useful for these kinds of policies, like device type or room
> type or even device name, but it's not clear how endpoints are supposed to
RE: By Christian

> = Section 15 =
RE: wii respond later

> Given that implementations will need to be updated to support CLUE, what
> is the rationale for having user authentication and authorization be
> optional? What are the cases where allowing an unauthenticated or
> unauthorized participant to join a telepresence session would be considered
> acceptable?
>
> "In
> I think it's worth pointing out in this document that DTLS/SRTP is
> required to use for CLUE-controlled m-lines. Also, I just did a quick skim
> of draft-ietf-clue-rtp-mapping and didn't see anything in there about media
> security.
>
> I don't think it's enough to point out that sensitive data can be sent
> back and forth with CLUE and that it shouldn't be used for authorization
> decisions. Is there some guidance that can be given about minimizing the
> amount and sensitivity of data to be sent? Are there certain xCard fields
> that endpoints should avoid sending? Some of this is obviously dependent on
> context and whether the participants in a conference know this information
> about each other already, but it's still worth mentioning how to mitigate
> the risks of sharing more data or more sensitive data than is necessary for
> the purposes of supporting a telepresence session. This might imply
> additional text in 7.1.1.10 as well.
>
> There are no details about how the data channel is secured in
> draft-ietf-clue-datachannel (which should be cited here if it's going to be
> referenced). Nor are the details in draft-ietf-rtcweb-data-channel, but
> rather they are in draft-ietf-rtcweb-security-arch and
> draft-ietf-rtcweb-security.
>
> endpoints rely on identity providers to authenticate each others'
> identities. IdPs are not specifically included in the CLUE architecture
> and, as noted above, the SIP authentication mechanisms are optional -- so
> how is it that the CLUE data channel is actually secured against an active
> MITM?
>
>
> Nits:
> In general it's hard for me to believe that there is much of an
> interoperability gain from specifying titles in this level of detail,
> rather than just allowing advertisers to specify all of their own -- is
> there some compelling need to specify this set of values initially?
>
> = Section 7.1.1.12 =
> s/user choice (for instance, selection of a new layout) MAY result/user
> choice (for instance, selection of a new layout) may result
>