Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]

[Harald Alvestrand <[e-mail]>]

On 10/29/2011 11:37 AM, Hadriel Kaplan wrote:
> On Oct 29, 2011, at 12:06 PM, Harald Alvestrand wrote:
>
>> I considered it when we discussed this last, but I'm not sure it works.
>> If we support SDES, the offer also contains crypto keys. Reusing crypto keys for all created connections would be a huge security vulnerability.
> The SDES key is used in the sending direction, not the receive.  That means everyone receiving the ROAP Offer will get the key and be able to decrypt the Offerer's transmitted media, but only the receivers of the ROAP Answer will be able to decrypt the Answerer's media.  So yes obviously if the ROAP Offer is generated by a Browser and sent to multiple parties, all of those parties would be able to render the media (and possibly spoof it to the others).
>
> But that vulnerability exists with SDES regardless of whether we support ROAP forking or not.  Even if the WebRTC browser only allows one ROAP Answer for any given Offer, if SDES is supported at all then we have to trust the JS and Web server, and trust them not to send the ROAP Offer to multiple parties, or we have to trust all those parties - assuming ROAP contains an SDES key and the Browser ends up using it.  For example, even if we don't support ROAP forking, a benign JS and Web-server might still send the ROAP Offer to multiple Browsers and only send back one ROAP Answer from the first answering Browser, not realizing that doing so introduced a vulnerability.
I don't think I expressed myself clearly....

Consider:
we create PC A, and it creates an offer with key A1
we get answer B1, and give it to PC A. Media flows, encrypted with A1 
from A.
we get answer B2, create a new PC B.
How does PC B know to use key A1 to encrypt media to B?

Two possibilities:
- All PCs created in this script use the same sending key. That seems 
like opening up vulnerabilities when creating PCs that connect to 
different places.
- The creation of PC B gets some special initialization data to tell it 
to use key A1

My earlier note about sending the offer as an initialization parameter 
to the creation of PC B was one possibility for that. Using a factory 
class to hold the information about key A1 is another.

....
> -hadriel
> p.s. draft-wing-srtp-keying-eval-00 discussed this forking issue and recommended re-keying in forking scenarios, for SIP.  No one does that as far as I know, though.
Thanks for the pointer.
>