Subject: [rtcweb] Review of draft-ietf-rtcweb-security-02 and draft-ietf-rtcweb-security-arch-01 documents

From: "DRUTA, DAN" <[email-masked]>
Date: Tue, 29 May 2012 14:26:55 +0000

I reviewed the latest version of the drafts and below are my comments/suggestions/corrections (not as comprehensive as Mark's).
In general I think the documents are well written with good references and paint a rather comprehensive picture of the issues to be addressed for rtcweb.

Draft-ietf-rtcweb-security-02

1.Introduction -  second paragraph after the diagram: 
"Each of their browsers exposes standardized JavaScript calling APIs which are used by the Web server to set up a call between Alice and Bob."
 This statement can be a bit more clear in that the APIs are executed locally (in the user agent) as  java script downloaded from the Web Server. The next paragraph eludes to the fact that logic is controlled by the calling service but I think it will be important to distinguish between APIs implemented by the user-agent and APIs/functions implemented by the calling service.

4.1 Access to Local Devices. 
Since this describes the threat I think is important to point out the fact that even when the user provides consent it is difficult for them to determine the real reason they give the consent to a site. Take the scenario in which a site obtains consent from the user for an app that captures a clip and saves it on the user's hard drive. Later on, if the user gave permanent consent to the site, the site can obtain access to the camera for the purpose of streaming without the user knowing that. This can be confusing for users even if they trust the site.

4.2 IP location Privacy
"Note that as soon as the callee sends their ICE candidates, the callee learns the callee's IP addresses." 
This must be "the caller learns the callee's IP address"

4.3.2.3. Third Party Identity
"It is possible (see[I-D.rescorla-rtcweb-generic-idp]) to use systems of this type to authenticate RTCWEB calls, linking them to existing user notions of
identity (e.g., Facebook adjacencies). Calls which are authenticated in this fashion are naturally resistant even to active MITM attack by the calling site."

Not to get too much into semantics, I think it is important to make the distinction that users are authenticated (using whatever IdP) and calls are authorized based on the assertions provided by the Idp for the authenticated user.

Draft-ietf-rtcweb-security-arch-01

1.Introduction
"The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers."

While there's nothing inaccurate about the statement, I would like to make it more generic because it is more than just communication between web browsers. In my opinion the WEB part in the acronym is all about using the web technologies to enable real time communications.

A proposed edited definition would be "... standardization protocols for enabling real-time communications within user-agents using web technologies (e.g JavaScript)".

6.2 Privacy

I have been trying to identify the appropriate section for a rather controversial requirement:  Lawful Intercept. It is expected that service providers for RTCWeb/WebRTC will be required to provide support to lawful intercept and I think we need to capture these requirements so we can map them to the security architecture. 

Thanks,
Dan

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Tue, 29 May 2012 16:47:31 +0200

> I have been trying to identify the appropriate section for a rather controversial requirement:  Lawful Intercept. It is expected that service providers for RTCWeb/WebRTC will be required to provide…

IETF Policy on Wiretapping
http://tools.ietf.org/html/rfc2804

Fabio

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 29 May 2012 13:36:22 -0400

Yes, but Dan's proposal surely takes this into consideration as I read it.

To this end, I think we need to ensure that the requirements that we 
develop do not interfer with Lawful Intercept requirements that 
providers must implement. (And to effect that we don't have to touch the 
LI requirements per se.)

Igor

On 5/29/2012 10:47 AM, Fabio Pietrosanti (naif) wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 May 2012 12:41:47 -0700

> I reviewed the latest version of the drafts and below are my comments/suggestions/corrections (not as comprehensive as Mark's).

:)  (see From: header)

> Since this describes the threat I think is important to point out the fact that even when the user provides consent it is difficult for them to determine the real reason they give the consent to a…

Once a site has your camera, there's no fundamental difference between
still frame capture and video streaming (for example).  Streaming is
just an optimization of the recording interface already present.  A
site can acquire still images and upload them (using JSONP, HTTP form
post, whatever) one by one.  Streaming just means that they can do so
without clogging up my network connection with 30 JPEGs per second.

I had to think about this one a bit before understanding why this
isn't a problem.  Maybe that can be rectified by adding text.

The more challenging interface problem deals with the presentation of
permissions dialogs for specific remote users, not the browser.  The
security architecture draft hints that this might be necessary, but it
offers a far more challenging UI design problem than the above.

> This must be "the caller learns the callee's IP address"

addresses :)

> I have been trying to identify the appropriate section for a rather controversial requirement:  Lawful Intercept. It is expected that service providers for RTCWeb/WebRTC will be required to provide…

Every time I think of this, I am more convinced that there is nothing
that needs to be specified.  Interestingly, the IdP proposal
potentially moves the onus for meeting these requirements to the IdP,
... impersonation being the key.