RE: User media constraint: peerIdentity



> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: den 24 oktober 2012 18:04
> To: Oscar Ohlsson
> Cc: public-webrtc@w3.org
> Subject: Re: User media constraint: peerIdentity
> 
> Hi Oscar,
> 
> Glad to have your input.
> 
> On 24 October 2012 00:34, Oscar Ohlsson <oscar.ohlsson@ericsson.com>
> wrote:
> > [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?
> 
> There is a subtle difference between these two scenarios:
> 
>  a) talking to an unidentified entity, getting an identifier for that
> entity and asking if that identifier is ok
>  b) identifying an entity, seeking that entity and failing if that
> identity is not obtained
> 
> The former is what you are suggesting, the latter is more consistent
> with TLS server authentication (RFC 6125, etc...).  The primary
> differences are in how the user experience plays out, particularly with
> respect to things like phishing.  For example, it is far more likely
> that a user will be caught out by confusable characters in the first
> instance than the second.

[Oscar] I don't see why the user would be more easily confused in (a). The application can match the identity returned in (a) with the identity that would have been used as constraint value in (b). And if a malicious application wants to fool the user with confusable characters, then that can be done just as easily in the (b) model.

> 
> Now, I'm interested in what applications you would have in mind where
> you don't know who you are talking to at the application layer.  I can
> see some scenarios where identity is necessarily hidden from the site,
> but those scenarios can still be accommodated with the identity provider
> arrangement (though I just now see a shortcoming with this proposal,
> which I will need to ponder a little more...)


[Oscar] No, I didn't have any application in mind. In the SIP world the responder could very well change due to forking or call diversion. But perhaps forking and call diversion do not exist (or is handled differently) in webrtc applications?


> 
> >> 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?
> 
> No, that sounds about right.  A simpler method would be to ensure that a
> particular certificate is bound to a specific peer identity.
> 
> On the other hand, the cost of generating a new self-signed certificate
> is much lower than the complexity of getting that sort of logic right.
> It might also be possible to reuse the certificate outside of the
> validity window of any previous identity assertion, etc...  In the end
> it might be easier to make a new certificate every time (as Firefox
> does).

[Oscar] I agree. Just wanted to see some more motivation for the "MUST NOT".

> 
> --Martin

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