[rtcweb] Security issue: consent refresh

Hadriel Kaplan <HKaplan@acmepacket.com> Fri, 28 October 2011 00:02 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172A811E80AB for <rtcweb@ietfa.amsl.com>; Thu, 27 Oct 2011 17:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.453
X-Spam-Level:
X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5oVPaKTW9rA for <rtcweb@ietfa.amsl.com>; Thu, 27 Oct 2011 17:02:29 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD9311E80AE for <rtcweb@ietf.org>; Thu, 27 Oct 2011 17:02:29 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 27 Oct 2011 20:02:27 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 20:02:27 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Security issue: consent refresh
Thread-Index: AQHMlQTgiHXhZE2WfUyh0p8ZGXLngw==
Date: Fri, 28 Oct 2011 00:02:26 +0000
Message-ID: <3FACD0E9-449A-4897-8997-F76B5A41A34E@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DE2BF62C42DE7C4581624953A637CEE6@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Subject: [rtcweb] Security issue: consent refresh
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2011 00:02:30 -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