Subject: [rtcweb] Security issue: consent refresh

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Oct 2011 00:02:26 +0000

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 (2) if RTCP wasn't entropic enough for initial consent, why is it for consent refresh?

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.

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.

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. 

-hadriel

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 28 Oct 2011 11:50:58 +0200

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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Oct 2011 18:24:01 +0000

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

> 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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 31 Oct 2011 06:22:40 -0700

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

[BA] Agree with Hadriel that forcing an IWF to "manufacture" RTCP is a bad idea, and that the focus should be on an off-path attacker. 

Also agree that we need "continuing consent" and can't rely on a "source quench" approach which has proven unworkable in other
contexts. There are situations where a receiver might have "gone away" for one reason or another, or where the receiver is being 
overwhelmed, where it might not have the ability or context to tell the sender to stop.  For example, if key state has been lost, 
putting out a secured "Bye" may not be possible.