Subject: [rtcweb] More on authorization and endpoint authentication

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Aug 2011 09:46:49 -0700

I wanted to follow up to something I said at the microphone last week
with regard to Cullen's presentation
(http://www.ietf.org/proceedings/81/slides/rtcweb-13.pdf) and in
particular slide 9, which argues that using a first-class signaling
protocol for the actual signaling has better security properties.  I
got on Cullen pretty hard about this, but in retrospect I think I may
have been a bit hasty.

The basic imperative for securing the camera and microphone in RTCWeb
is that you be able to determine who the media will go to (e.g., you
are talking to Ford.) What I had in my head in my slides was that we
would do this by restricting access to the JavaScript APIs. I.e., that
you would grant www.ford.com the right to use the WebRTC APIs. I.e.,
the policy would be:

  P1: Allow any script coming from www.ford.com to call anywhere.

The way (or at least a way) you use this to get a call is that
DoubleClick brings up an IFRAME on Ford's site that loads up JS
calling the right location at Ford. And since the browser has
direct access to the origin, it can evaluate this policy
directly. If you're not willing to have a hosted IFRAME like
this, then the permissions reduces to letting DC call alyone.

The model in slide 9, however, is different: instead of restricting
access to the APIs to a given site, it instead allows anyone to
invoke the APIs, but *calls* are restricted to a given site. So,
in this case, the access control policy would be:

  P2: Allow anyone to place a call provided that it goes to
  [email-masked].

The browser evaluates this (in the simplest case) by connecting to
ford.com's SIP server and verifying that it is indeed ford.com.

My (rather loud) argument at the microphone was that P1 and P2 have
similar security properties and I was trying to push back on Cullen's
claim that P2 was better. In either case, ford.com gets to capture
your audio and video and send it wherever it wants. And obviously, if
it just wants to turn on your camera and send it to your ex-wife it
can. However, thinking about it more, I think that claim is
too strong; there are two differences, one technical and one social.

The technical difference is simply that in one case Ford has to stand
up a bunch of new technical infrastructure to serve/service the WebRTC
code that establishes its origin and initiates the call [0]. By contrast,
the solution Cullen proposes allows reuse of all the existing calling
technical infrastructure (whether SIP or Jingle) that Ford already
has.

The social difference is about the assertion that Ford is making.
In the former case, Ford is saying "I'll do something with this call,
and you'll like it." In the second they are saying "you are making
a call to someone at Ford." So, while from a technical security
guy perspective, they are equally able to screw you over in either
case by lying, if they *aren't* lying then the policy your browser
is enforcing on your behalf is a lot clearer: "only call people
who have Ford addresses."

At a higher level, I think we've been failing to draw the distinction
between two cases which are socially (and arguably technically) very
different:

1. The calling service is permitted to place a call but all the
   information about who you are actually calling is accessible
   only to the JS provided by the calling service.

2. The calling service is permitted to place a call but the
   browser has independent information about who you are
   actually talking to. [and could at least in principle render
   it to the user.]

Matthew's UI document and Cullen's presentation both point towards
the notion that #2 is valuable as well, with Cullen's presentation
being more oriented towards signaling and Matthew's more oriented
towards the media-level security, but in both cases suggesting
that we may not just want to authorize the calling service and
let it call wherever with no other independent security mechanisms.

I'm not sure whether this concept covers all the relevant cases, since
at least conceptually it depends on the notion that everyone has an
actual name that is somehow qualified by a universally meaningful name
and there are probably cases where I just want to phone home to the
Web site. However, it seems like it's at least plausibly a useful
piece of functionality in addition to what I had been thinking of as
an origin-based API restriction.

-Ekr

[0] It can of course outsource that with <script src="..."> or
Akamai, but then it loses control of the interaction.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 4 Aug 2011 17:13:50 -0700

Eric Rescorla said: 

> ford.com's SIP server and verifying that it is indeed ford.com

These two statements are *not* equivalent.  The first statement relates to the To: field; 
the second relates to authentication of the identity of the server to which the browser connects.
These elements are orthogonal and should not be conflated. 

As an example, if a BOSH connection manager is configured to route stanzas to domains other than
its own, a browser can use a BOSH connection manager to send XMPP stanzas to any
XMPP user.   Authenticating the BOSH connection manager (e.g. via TLS) imposes no
restriction whatsoever on who can be "called" via Jingle using that BOSH connection manger.   
That restriction would only be implemented within the BOSH connection manager, *not* within the 
browser.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 05 Aug 2011 08:41:14 +0200

>     actually talking to. [and could at least in principle render
I do not like the thought of going down the case #2 road.

The reason is that in case 2, the concept of remote identity gets 
hardwired into the browser, and the API becomes useful only for 
applications that subscribe to the particular identity model that is 
hardwired into the browser.

In case #1, the API can be used with any (or no) concept of "remote 
identity", and the JS provider (who has a kind of "identity" by virtue 
of the Same Origin Policy definition, so it's already wired into the 
browser) gets to hold the responsibility.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 Aug 2011 06:41:52 -0700

> These elements are orthogonal and should not be conflated.

Yes, you're right that I've elided some steps here.

In order for the browser to meaningful enforce a restriction on who you can
call, it needs to either (a) directly verify the endpoint, at least as
far as the
domain or (b) trust that the adjacency it is connected to will route messages
correctly. So, what I had in mind here (again, in the simplest case) was
that the browser would connect to ford.com *and* use To: [email-masked],
thus having confidence that the message is routed correctly. Another alternative
would be to connect to some trusted SIP proxy and use To: [email-masked].
Yet another alternative would of course be RFC 4474 Identity.

However, the point I was trying to make is that this is distinct from letting
the Web server that provided the page route the messages itself. You
might imagine not trusting the page but nevertheless be willing to allow
it to provide you with an address which you can independently verify
and derference.

Best,
-Ekr

---

From: Ted Hardie <[email-masked]>
Date: Fri, 5 Aug 2011 10:38:00 -0700

> it to provide you with an address which you can independently verify

Do you really mean "an address" which you can independently verify and
dereference, or an identity you can verify?

Let's take the poker site example.  The web site owner wants to embed
video streams in the poker application, so that the players are
reasonably assured that they are not playing a bot (or, at least, that
the player using a bot must be physically present during the game).
The poker players are likely put into groups based on arrival time,
maximum bid, etc.  in one mode; in another mode, a group of friends
may come and play together.  In the first mode, the players likely do
not want to share any identifying information with each other.  In the
second mode, the first player might invite the other players to a
room, by sharing a URI provided by the web server, or he might pass
their identities to the web server, so it can limit access to those
signing in with those identities.

In neither case, do we really want the web server to pass the video.
It serves as the initial signaling path for the messages among
players, but that's really it for the audio/video streaming part.

I've been assuming that the website would provide an identity in this
case, if one were needed (e.g. [email-masked]), but that
the primary reason for that identity would be outside the connectivity
model (so you know if you're playing the same player again, for
example, and can react if the picture looks different, or you don't
want to play with someone who is better than you).  Anyone in model
one (using a URI to join a specific game) would be assigned an
identity.  Anyone in model two (where the website locks down the game
to specific players) has to know what the player identities are to
invite.

In neither case does this seem to me to map well to SIP identity, and
I'm concerned that if we start with SIP identity as a mental model,
we're going to have softphones in browsers that can't do any of the
more web-based things that we actually want to enable.

regards,

Ted

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 05 Aug 2011 14:05:40 -0400

There are many interesting points here (as there are elsewhere on this 
thread).

Just to pick one, I wonder if it is an appropriate time to start zeroing 
in on acceptable identities as well as on the way of mapping them to a 
specific "person" (including bots).
There are two aspects to it. One is authentcation (i.e., a sort of a 
transitive closure reliance: if I know that A and B are different 
identities of P, and I have authenticated P based on A, I may , in 
certain circumstances, trust what comes from B), and the other is 
actually the choice of identifier.

Of course, I realize that this question sort of strays off the thread...

On the identifer choice, in direct response to Ted's last point, I would 
think that using SIP identities has much merit in several deployments. 
One is mobile telecom, where incidentally an end-point device is always 
sufficiently authenticated, with a  straight-forward extension to the 
person's authentication as the next step.

(By the way, when I read the quoted paragraph from Eric, I did assume 
that he meant "identity." )

Igor

On 8/5/2011 1:38 PM, Ted Hardie wrote:
> On Fri, Aug 5, 2011 at 6:41 AM, Eric Rescorla<[email-masked]>  wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb