User media constraint: peerIdentity

For motivation, see
http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0165.html

When getUserMedia returns a stream, permissions for that stream are
bound to the page origin.  This gives the page origin complete control
over the contents of the stream.

The current security model
<http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch> defines a
model where an untrusted domain is able to mediate the establishment
of a trusted session between peers.  No API exists to support this.
This attempts to redress this shortcoming.

In this solution, any page is able to to acquire user media that is
bound to a specific peer.  The page could be untrusted, even a
cleartext HTTP page, because the page cannot gain access to media.

Peers can be identified in two ways:
 - "at" identities - user.id@domain.example.com - identifies a
specific peer that is identified using a certificate fingerprint that
is bound to a user identity using an identity provider
 - "non-at" identities - domain.example.com - identifies a peer that
is identified by an end-entity certificate that chains to a domain
trust anchor

This binding is made by applying a 'peerIdentity' constraint to
getUserMedia.  The value of this constraint is the single peer
identity, either "at" or "non-at".

Omitting 'peerIdentity' results in default behavior: the page can do
as it pleases with the MediaStream.  This includes the ability to use
security descriptions, as opposed to this DTLS-SRTP thing, which has
nice security properties but poor latency and interoperability
properties.

A MediaStream that is acquired using a 'peerIdentity' constraint
cannot be recorded, sampled or otherwise accessed by the current page.
 It can only be added to an RTCPeerConnection.  That RTCPeerConnection
instance MUST NOT send media originating from that MediaStream unless
it successfully authenticates the peer with an identity that matches
the 'peerIdentity' constraint.  Matching is based on the rules defined
in the IdP draft for "at" identifiers or RFCs 6125 & 5280 for "non-at"
identifiers (yes this isn't strictly RFC 6125, but the basic rules are
transferable).

An RTCPeerConnection that could be authenticated by a remote peer
(i.e., one for which an identity assertion has been generated) MUST
NOT allow for the mixing of MediaStreams that could originate from
non-user sources.  The simplest approach would be to restrict inputs
to tainted MediaStream instances, but it should also be possible to
include untainted streams as long as they haven't been modified (I
don't care which we choose, but we need to pick one so that we get a
consistent user experience).  This stops users from observing
"authenticated" media that has been mixed with media that is
controlled by an untrusted intermediary (i.e., the current page).

A browser MUST NOT reuse credentials offered for an authenticated
RTCPeerConnection that generates an identity assertion.  This prevents
peers from falsely "authenticating" sessions against a previously
valid identity assertion.  ... The alternative is to have some sort of
binding to the current session so that identity assertions aren't
generically reusable.

--Martin

Received on Monday, 22 October 2012 18:18:07 UTC