Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)

[Magnus Westerlund <[e-mail]>]

Hi Cullen,

Sorry this took longer than expected to get the IPR disclosure prepared
and submitted.

The claims define the scope of the invention.  There is much case law
regarding how the claims terms are to be interpreted.  For WebRTC, the
first below mentioned invention's purpose is to address a weakness in
that the signaling messages to establish peer connections. And the main
embodiment shown uses CSP, which does not appear to be described in
WebRTC. When it comes to PERC at least one of the claims could be
interpreted to apply on the part of how the Key Distributor knowns which
identities that the Endpoint has and which to allow into the conference.
Therefore we have made an IPR declaration on draft-ietf-perc-dtls-tunnel
and draft-jones-perc-dtls-tunnel.

https://datatracker.ietf.org/ipr/3580/

https://datatracker.ietf.org/ipr/3586/


Cheers

Magnus


On 2019-05-16 08:21, Cullen Jennings wrote:
>
>> On May 14, 2019, at 3:15 PM, Magnus Westerlund via Datatracker <[e-mail]> wrote:
>>
>>
>> A significant security vunerability in PERC that should be made more explicit
>> and is totally missing is the risks with compromised endpoints. Beyond the very
>> evident thing that this endpoint can decrypt all media it receives there are
>> far more sinister risk here. Namely the potential for injection of media that
>> attempts to impersonate another endpoints media stream. Most of SRTP's cipher
>> suits only use symmetric crypto functions, thus enabling anyone with the key to
>> send a packet with any SSRC, and have that being accepted as that source. Where
>> it is has no practical usage in point to point communication, in conferencing
>> it becomes an issue. It allows the usage of media level replay or deep fakes to
>> be used to create media streams that are injected into the media distributors
>> using an SSRC of another endpoint.
>>
>> The mitiagations that are missing from this document. The fact that a media
>> distributor that is not compromised or collaborating with the compromised
>> endpoint could actually prevent such media injection by applying source
>> filtering of SSRCs and drop all that aren't associated with the endpoint. The
>> other potential mitigation is to introduce another cipher suit that uses a non
>> symmetric integrity protection mechanism, such as TESLA to prevent this type of
>> injection.
> And the related issue that the main way this can happen is attacker manipulation of the fingerprint so the providing ways to protect that along with SSRC based signalling or TELSA  is the obvious solution space to this. And just to frame the discussion, let me point out the issue you raise is not so much about an SSRC but binding the identity of a member of the group to the audio received. 
>
> As other have pointed out, which member inside the conference the media is from is not something PERC provides any information about. Many existing conference systems have existing approaches to solve this problem and they can add PERC as a tool with out breaking theses so it to be specified here. Something that used TESLA could work fine with PERC as well. I do think future work can look at what we need for rosters and active speakers and how to use things like STIR and fingerprints and SDP to tie identity to the media. However, I think that problem is fairly separable from the issue of making sure the operator of the media switch does not have access to the media content. 
>
> But just to explore what solutions could be build on top of PERC to solve this, let me cary on. 
>
> Early on the WG did consider one an Ericssons proposal that used SSRC based signalling for many things but the WG moved away from that at least partially over concerns of Ericsson IPR in this space. In trying to refresh some of the state on possible solutions to this I came across. 
>
> https://patentimages.storage.googleapis.com/07/b2/6a/f34fd49f38a5a4/US20180205720A1.pdf
>
> which has the following claim 
>
> 39) A method for a server for enabling setting up a secure peer - to - peer connection between a first peer and a second peer , wherein at least one of the first peer and the second peer is a web browser , the method comprising : receiving a request for a web application from the first peer ; sending a directive to the first peer requesting a fingerprint of a certificate of the first peer ; receiving a first fingerprint from the first peer ; and sending the first fingerprint to the second peer .
>
> So just to make sure I understand this, if we have a case where a webapp sends an SDP offer that goes to the first peer, this requests the certificate and of the first peer and sends it in the SDP answer to the webapp that then sends that answer on to the second peer. It seems this claim surely covers a bunch stuff we are doing in WebRTC as well as PERC and needs to be disclosed. You agree ?
>
> One thing that would work well is an approach like the CSP protection in the above patent mixed with the ability for the KD to bind the client to the web conference application as described in 
>
> https://patentimages.storage.googleapis.com/d0/de/1a/5cbafd9903417b/WO2018063041A1.pdf
>
> Actually claim 1 seems like that is pretty much perfect for solving this. Claim 1 reads 
>
> 1. A method for a server to bind a device application to a web service, wherein Web Real Time Control, WebRTC, functionality is provided to the server, the method comprises:
> -receiving a request for the web service from the device application, wherein communication between the server and the device application is done via https and WebRTC and the device application has generated WebRTC credentials comprising a private key, certificate of the private key and a fingerprint of the certificate,
> -receiving  the fingerprint and fingerprint generation algorithm of the certificate,
> -storing  the fingerprint and fingerprint generation algorithm and associating the fingerprint with the device application, and
> -using Datagram Transport Layer Security, DTLS, providing the certificate of the device application, in combination with the stored fingerprint to identify the device application to bind the device application to the web service.
>
> So to walk thorough the parts of this claim. When a user joins the web conference that uses PERC, the request and responses for the fingerprints are send via the SDP offer and answers over HTTPS, the website learns the fingerprint for the user and then when the DTLS connection to the KD is formed, the way the KD correlates to the user to make sure they are the right one to authorize into the conference is by using that same fingerprint. Let me know if I am misunderstanding this or if a disclosure is needed. 
>
> I think you should propose this stuff to dispatch as way to solve the problem of knowing who in a conference the media is coming from. Please let me know if I am misunderstanding theses claims and if disclosures need to be made. 
>
>
>
>
>
>

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------