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.

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

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

--Martin

Received on Wednesday, 24 October 2012 16:04:24 UTC