[rtcweb] draft-rescorla-rtcweb-security

Bernard Aboba <bernard_aboba@hotmail.com> Thu, 08 September 2011 08:03 UTC

Return-Path: <bernard_aboba@hotmail.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 DD3C521F8B4B for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 01:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 0zMgwUaGsAvY for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 01:03:02 -0700 (PDT)
Received: from blu0-omc3-s8.blu0.hotmail.com (blu0-omc3-s8.blu0.hotmail.com [65.55.116.83]) by ietfa.amsl.com (Postfix) with ESMTP id DF85521F8B35 for <rtcweb@ietf.org>; Thu, 8 Sep 2011 01:03:01 -0700 (PDT)
Received: from BLU152-W54 ([65.55.116.74]) by blu0-omc3-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 01:04:52 -0700
Message-ID: <BLU152-W54CEF0D1B390D7326BB98F931E0@phx.gbl>
Content-Type: multipart/alternative; boundary="_07c49ff5-42e0-463a-bad0-e1935d4d3c0c_"
X-Originating-IP: [70.88.131.169]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <rtcweb@ietf.org>
Date: Thu, 8 Sep 2011 01:04:51 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Sep 2011 08:04:52.0585 (UTC) FILETIME=[FD026D90:01CC6DFD]
Subject: [rtcweb] draft-rescorla-rtcweb-security
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: Thu, 08 Sep 2011 08:03:03 -0000

Much of this document is very good, but the sections on ICE and masking aren't quite right.

The security properties attributed to ICE only exist under a very carefully circumscribed set of conditions.  Unfortunately, Sections 4.2.1 and 4.2.2 aren't clear about this.

The ICE exchange is fine for verifying willingness to accept a particular stream, assuming that the receiver provides an indication of willingness to receive.   In part, this works because the specific characteristics of the stream are negotiated in SDP offer/answer simultaneous with ICE.  However, Section 4.2.1 isn't specific enough about what guarantees are provided by ICE and under what conditions.  An ICE exchange doesn't enable "traffic";  at best it enables media with characteristics specified in SDP offer/answer to be sent.   

Section 4.2.2 says that masking is not necessary for UDP, but the logic behind the statement needs more elaboration. There are lots of potentially nasty things that can be done if a browser can send arbitrary datagrams to a receiver, even if we postulate a STUN exchange.  Things like:

* Sending a datagram that might be mistaken for a DNS response, potentially poisoning the cache. 
* Sending an SNMP set to a device.
* Sourcing a routing packet (e.g. RIPv2). 

It strikes me that Section 4.2.2 is needs to be more specific about the specific threats and the conditions under which they are mitigated via ICE, SDP offer/answer, etc.


4.2.1.  ICE

   Verifying receiver consent requires some sort of explicit handshake,
   but conveniently we already need one in order to do NAT hole-
   punching.  ICE [RFC5245] includes a handshake designed to verify that
   the receiving element wishes to receive traffic from the sender. 

[BA] I believe that the requirement needs to be stronger -- that
the receiver has agreed to specific traffic offered
by the sender.  So if the receiver agrees to receive audio and gets
video instead, that isn't ok.  Similarly, the guarantee shouldn't
permit a browser to DoS a public STUN server, that merely by responding
to a STUN request, hasn't indicated a willingness to receive any
media at all.  Overall, it's important that we get into the specific
conditions under which ICE provides the security guarantees we need. 
More on this later. 

   It is important to remember here that the site initiating ICE is
   presumed malicious; in order for the handshake to be secure the
   receiving element MUST demonstrate receipt/knowledge of some value
   not available to the site (thus preventing it from forging
   responses).  In order to achieve this objective with ICE, the STUN
   transaction IDs must be generated by the browser and MUST NOT be made
   available to the initiating script, even via a diagnostic interface.
4.2.2.  Masking

   Once consent is verified, there still is some concern about
   misinterpretation attacks as described by Huang et al.[huang-w2sp].
   As long as communication is limited to UDP, then this risk is
   probably limited, thus masking is not required for UDP.  I.e., once
   communications consent has been verified, it is most likely safe to
   allow the implementation to send arbitrary UDP traffic to the chosen
   destination, provided that the STUN keepalives continue to succeed.

[BA] Receiving a STUN keepalive (particularly one which is not authenticated)
is not sufficient to protect against UDP-based attacks.  

   However, with TCP the risk of transparent proxies becomes much more
   severe.  If TCP is to be used, then WebSockets style masking MUST be
   employed.