Re: [rtcweb] Consent alternative

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Tue, 03 December 2013 04:30 UTC

Return-Path: <mperumal@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577601ADF95 for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 20:30:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czTnH8fFYTeE for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 20:30:17 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 30BA81ADF38 for <rtcweb@ietf.org>; Mon, 2 Dec 2013 20:30:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5229; q=dns/txt; s=iport; t=1386045015; x=1387254615; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bal7/6ZRT+ULcFSO/Sa3gZjv9lRiBeIFQw0dnqLn9fQ=; b=PDbE+QIyuL5xofbu4XDFyInibBpxKWByQLXRaSxs9zj7UKbGhr50RnRR aNqziVrOfao9bYaDfvtcKVGz39a4VQW/8cxfawHKysdgBa6zo4wWvhVzJ mFmZj3miIAtyRebFOPKyvPkIFz/ih2b5LR5hBqo12S8Xcr0imDnTD/yN7 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAGddnVKtJV2c/2dsb2JhbABZgwc4U7gcToEaFnSCJQEBAQQBAQE3MgIIAwwEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCId5DcBeF45XMQcGgxqBEwOZRJBjgymCKg
X-IronPort-AV: E=Sophos;i="4.93,815,1378857600"; d="scan'208";a="289025611"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 03 Dec 2013 04:30:14 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB34UERM003104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 04:30:14 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 22:30:14 -0600
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Martin Thomson <martin.thomson@gmail.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: [rtcweb] Consent alternative
Thread-Index: AQHO77AWPi9LFgXOuUGt5r/tDp7yvppB3ZQQ
Date: Tue, 03 Dec 2013 04:30:13 +0000
Message-ID: <E721D8C6A2E1544DB2DEBC313AF54DE22436FBD9@xmb-rcd-x02.cisco.com>
References: <CABkgnnVNnT8uoWM8T=TqbTmy11CGTeHLP=_7z5KSMSpAsp9SyQ@mail.gmail.com> <52989933.6000907@ericsson.com> <CABkgnnUX3OFUyc5PXeN0ydykBwL0HyRuaigfJKMBbuWnuhnVJg@mail.gmail.com>
In-Reply-To: <CABkgnnUX3OFUyc5PXeN0ydykBwL0HyRuaigfJKMBbuWnuhnVJg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [72.163.208.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Consent alternative
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 03 Dec 2013 04:30:19 -0000

|2. B (the attacker) triggers an "ICE restart" with A, though really
|this generates a new ICE negotiation with a victim, C.  C consents to
|talk to B, but not necessarily with A.  This arrangement is easy to
|achieve on the drive-by web.
|
|3. A completes ICE with C and expects to continue the DTLS connection
|over the newly discovered 5-tuple.

Assuming this is a regular ICE restart, the STUN binding requests sent as part of the ICE connectivity checks from A to C would have randomly generated transaction IDs. Unless B is on the A-C path or can guess those transaction IDs, it wouldn't be able to generate legitimate binding responses to cause ICE to conclude b/w A and C.

Muthu

|-----Original Message-----
|From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin Thomson
|Sent: Tuesday, December 03, 2013 4:14 AM
|To: Magnus Westerlund
|Cc: Cullen Jennings (fluffy); rtcweb@ietf.org
|Subject: Re: [rtcweb] Consent alternative
|
|On 29 November 2013 05:40, Magnus Westerlund
|<magnus.westerlund@ericsson.com> wrote:
|> I have looked briefly on this and wonder if this isn't vulnerable to
|> active attacks from a attacker (Alice) that likes to use a set of WebRTC
|> browsers, including (Bob) to generate DDOS traffic towards the target
|> (Charlie).
|
|Hi Magnus,
|
|I think that you did manage to hit on something critical here.
|
|The basic security primitive in play with ICE consent is proof of
|receipt.  That is the key piece at play here as well.  We require
|proof of receipt simply because that elevates the requirements for an
|attacker to the point that they have to basically be on-path.  At that
|point, they (likely) already have the ability to generate traffic
|toward a victim of an equal (or maybe greater) volume to the sender
|and gain little by mounting the attack.
|
|That's why I'm not particularly interested in the part where you talk
|about attackers intercepting binding requests.
|
|The actual attack that you have hit upon (or caused me to think about)
|is not quite as you described, but it does rely on the fact that the
|proposed change to the consent mechanism no longer actively depends on
|proof of receipt.
|
|It also relies on the possibility that a DTLS connection can be moved
|without requiring proof of receipt on the new path.  That, to me, is
|the fundamental problem to be solved.  From my reread of RFC 6347, it
|appears as though the only consideration given to DoS was at the
|handshake.  Once something like ICE is in play (and MICE makes this
|worse), the ability to "move" the connection presents an attacker with
|an opportunity.  (I have to point out that this also confirms my fears
|about the mechanism used to signal ICE restarts, but I'll get back to
|that.)
|
|Here is the attack as I understand it:
|
|1. A talks to B, establishing a DTLS connection using ICE.  There is
|no need for lots of data to flow at this point, this is the "warm-up"
|phase of the attack.
|
|2. B (the attacker) triggers an "ICE restart" with A, though really
|this generates a new ICE negotiation with a victim, C.  C consents to
|talk to B, but not necessarily with A.  This arrangement is easy to
|achieve on the drive-by web.
|
|3. A completes ICE with C and expects to continue the DTLS connection
|over the newly discovered 5-tuple.  C is confused, but really has no
|recourse at this point.  Even if the DTLS connection fails, C is now
|the victim on the other end of an unending stream of bits.  B spoofs
|the source address of the necessary packets to continue consent, A
|continues to send to C, and nothing that C does can stop the flood
|because they don't have access to the master secret and cannot
|therefore produce an authenticated packet that terminates the
|connection.  B can continue the attack as long as A is willing, at the
|bargain-basement price of a (spoofed) DTLS heartbeat response every
|10-20 seconds.
|
|The key here is the lack of a proof of receipt from A toward C for the
|DTLS connection that is moved.  There is nothing inherent to DTLS that
|provides proof that C received data from A and is also willing to
|continue to communicate... Almost.
|
|The DTLS heartbeat extension does provide such a thing:
|http://tools.ietf.org/html/rfc6520#page-6
|
|All we need to do to close this little loophole is to require that a
|DTLS heartbeat request be sent after any change in underlying 5-tuple.
| That request MUST contain sufficient entropy that guessing would be
|difficult for an off-path attacker; noting that this is also covered
|by TLS record layer encryption and authentication, limiting the number
|of parties that are even allowed to make a guess.  I'm a big fan of
|128 bits, but less is almost certainly OK.  If no response is received
|within N seconds, consent is expired.  The basic consent timer seems
|appropriate here, i.e., N=30.
|
|DTLS renegotiation would also work, but I consider that to be a little
|heavyweight.  I'm not sure that it's that widely implemented either.
|_______________________________________________
|rtcweb mailing list
|rtcweb@ietf.org
|https://www.ietf.org/mailman/listinfo/rtcweb