Re: [rtcweb] Security issue: consent refresh

[Magnus Westerlund <[e-mail]>]

On 2011-10-28 02:02, Hadriel Kaplan wrote:
> Howdy, per the request made by the Chairs for threads on the security
> daft, I'm starting this one on the topic of media-stream consent
> refresh.  This is related to section 4.2.3 of
> draft-ietf-rtcweb-security.
> 
> The concern here is to make sure the other side wants to keep
> receiving RTP, since a malicious JS can prevent the Browser learning
> the far-end no longer wants to communicate via the high-path.  It
> also provides protection against certain non-malicious failure cases,
> especially with automated systems like media servers.
> 
> Receipt of RTP cannot be used for consent refresh since the session
> may be in sendonly/recvonly mode, and RTP can be easily spoofed.  One
> proposal was to use receipt of RTCP as consent refresh.
> 
> ISTM the problem with using RTCP is (1) some deployed devices don't
> do RTCP and faking it in a gateway is bad mojo, and

The question is if non RTCP sender will be able at all to interact with
WEBRTC peers at all due to congestion control reasons. I think we will
come back to this issue several times.

 (2) if RTCP
> wasn't entropic enough for initial consent, why is it for consent
> refresh?

The issue is that as RTCP contains only a limited amount of entropy it
takes long time to provide consent that it isn't feasible. The question
is if the same is true for consent refresh. This as one can look over a
window of the last 30 seconds and see if a sufficient number of correct
RTCP Report blocks has been received that matches the RTCP SR that the
media sender sent.

> 
> 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?

> 
> The benefits of this are that it doesn't rely on RTCP entropy, or
> even RTCP period.  It is easier to implement in a gateway than fake
> RTCP generation.  And it allows interworking gateways to get out of
> the way (not be in the media-plane) because they can know both sides
> do the consent refresh, which they don't know about just RTCP.

Well, interworking gateways that have peers that terminates their ICE
connectivity check capabilities after session establishment and only
send STUN indication will not work as you stated. And in the case the
peer are not ICE capable and you anyhow need the media plane gateway
function to answer the ICE exchanges you get more work in this gateway.

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

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------