Re: [rtcweb] Security issue: consent refresh

[Hadriel Kaplan <[e-mail]>]

On Oct 28, 2011, at 5:50 AM, Magnus Westerlund wrote:

> On 2011-10-28 02:02, Hadriel Kaplan wrote:
>> 
>> Alternative Proposal: I think one obvious solution is to use a STUN
>> request/response check as a consent refresh.  The STUN check does not
>> need to use SHA-1 stuff, just responding with the same transaction ID
>> as the request should provide enough entropy.  The STUN message could
>> be an existing one from RFC 5389, but it would take a new draft to
>> say "do this" and indicate it in SDP.
> 
> And the reason you are not needing the SHA-1 stuff is that you see no
> need for this consent refresh to continue to verify that the one sending
> the answers echoing the transaction IDs is a node which you provided
> with the credentials? Or which the "evil" webservice has provisioned
> with the credentials from the signalling exchange?

Correct.  Let's assume ICE is used for initial consent.  If you're past the initial consent stage, then some far-end accepted your communication. 

At that point we're at the same stage as if the JS had simply initiated an HTTP connection to another site and it was approved with CORS.  What keeps such an HTTP connection going is simply TCP "consent-refresh" using ACKs and not getting RST/FIN... and we don't need to be stronger than TCP.  Arguably the STUN keepalive would actually be stronger than TCP even without SHA-1, because the STUN 96-bit Transaction-ID is harder to spoof-guess than two 16-bit TCP sequence number fields.

If there is a MitM physically on the path between the Browser and the peer, such a MitM can keep the RTP flowing even if we used RTCP, because it could fake RTCP. (and such a MitM can keep TCP and SCTP going too, fwiw)


>> The downside is any existing RTP devices that already support ICE and
>> RTCP would need to be upgraded in order to talk to WebRTC. I think
>> there's a solution to that too if people think we need to interop
>> with them without upgrading.  One idea is IF RTCP is sufficiently
>> entropic for consent refresh, then we have an escape clause that if
>> the peer doesn't indicate support for this new STUN-based consent
>> refresh, then we allow it to use RTCP as consent refresh.
> 
> If you need this upgrade, why not ensure that they do RTCP? That is more
> useful for also other purpose and may actually ensure that we can
> fulfill some minimal congestion control requirements even in the
> interworking cases. Yes, it is more new code, than tweaking an existing
> ICE stack to do what you suggest.

Because we can't upgrade devices not under our control, as described in draft-kaplan-rtcweb-sip-interworking-requirements-00 section 3.  For some percentage of the WebRTC use-cases, interfacing to deployed SIP devices will need an Inter-Working Function.  Having an IWF system generate fake RTCP is a really bad idea; from a cost, complexity, failure-potential, and architectural basis.  And such an IWF could never remove itself (let media go direct) on a call-by-call basis, because it woul'd never know if the far-end SIP device implements RTCP.

-hadriel