RE: User media constraint: peerIdentity

Hi Martin,

Something along the lines of what you propose is definitely needed if you want true end-to-end security between the peers. I have some comments on some of the details though. See below.

Regards,

Oscar Ohlsson

P.S. This is my first post on this list.
 
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: den 22 oktober 2012 20:18
> To: public-webrtc@w3.org
> Subject: 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".

[Oscar] You're talking about the identity of the remote peer, right? This requires that the application knows the identity already when getUserMedia is called. Wouldn't it be better if the identity is determined by the PeerConnection object after the SDP offer/answer is received? You could still provide a 'peerIdentity' constraint in the call to getUserMedia but you wouldn't include any identity value.


Once the identity is known the browser would need to ask the user if he agrees to sending the media to that particular remote peer. Or what is your thinking here?


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

[Oscar] The matching becomes unnecessary with the "late binding" mechanism proposed above.

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

[Oscar] This requires some more careful analysis I think. I think it's safe for the browser to re-use the self-generated certificate for which an assertion once was generated provided that:

(1) If the self-generated certificate is re-used in a PeerConnection then the page is not allowed to read or modify any of the media streams (neither the received ones nor the sent ones) i.e. all the streams become tainted.

(2) If a new assertion is created for the self-generated certificate then the identity used must be the same as before.

Or am I missing something here?

> 
> --Martin

Received on Saturday, 27 October 2012 07:32:48 UTC