Re: [rtcweb] Consent alternative
"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Tue, 03 December 2013 12:48 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 3DDBA1AE139 for <rtcweb@ietfa.amsl.com>; Tue, 3 Dec 2013 04:48:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 Wyn8Q4HSaSJF for <rtcweb@ietfa.amsl.com>; Tue, 3 Dec 2013 04:48:28 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BE8341ADEA6 for <rtcweb@ietf.org>; Tue, 3 Dec 2013 04:48:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24156; q=dns/txt; s=iport; t=1386074905; x=1387284505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5bqWLB2FmE36zvTc078LwWSRMwRwtX/kSC6MmUr5UaQ=; b=UvkxvkYCL7vI+OFDP9F3WsUTG/o0uHujQUUtgkoQaJRXyjcowjcvlu8a sBH7NI3OT+0j1NN47dj8Dfel5PJMi0Nb5HduhVW60G0+Yv3dJH1PD6G4M vcln1tnxALFV6BSG5ZbJSRn++6+eUgVPckJOtqjd1gTi4bkLI1hNRaqqc E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQHABrSnVKtJV2Y/2dsb2JhbABagkNEOFOCeq0diAJOGIEDFnSCJQEBAQQBAQEgCj8CCAMMBAIBCBEEAQEBCh0DAgICHwYLFAkIAgQOBQiHZwMPDbB9iQYNhzsXjG2BYBYXBAYBBoJlNYETA5YpgxuLKoU5gymCKg
X-IronPort-AV: E=Sophos; i="4.93,817,1378857600"; d="scan'208,217"; a="286025277"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 03 Dec 2013 12:48:24 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB3CmOXE008631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 12:48:24 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 06:48:24 -0600
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [rtcweb] Consent alternative
Thread-Index: AQHO77AWPi9LFgXOuUGt5r/tDp7yvppB3ZQQgAB7WQCAAAzaoA==
Date: Tue, 03 Dec 2013 12:48:23 +0000
Message-ID: <E721D8C6A2E1544DB2DEBC313AF54DE22437073A@xmb-rcd-x02.cisco.com>
References: <CABkgnnVNnT8uoWM8T=TqbTmy11CGTeHLP=_7z5KSMSpAsp9SyQ@mail.gmail.com> <52989933.6000907@ericsson.com> <CABkgnnUX3OFUyc5PXeN0ydykBwL0HyRuaigfJKMBbuWnuhnVJg@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE22436FBD9@xmb-rcd-x02.cisco.com> <CABkgnnUy3HxvsqYfwspEQ9_g1frUuFF4rwD-hTz45UzCr1fTBw@mail.gmail.com>
In-Reply-To: <CABkgnnUy3HxvsqYfwspEQ9_g1frUuFF4rwD-hTz45UzCr1fTBw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.69.3]
Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE22437073Axmbrcdx02ciscoc_"
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 12:48:31 -0000
That's a typical third party call control (3PCC) use case where B (3PCC) mangles call signaling + SDP b/w A and C and sets up the media session between them. The security of ICE (as defined in RFC5245) is rooted in the ice-ufrag and ice-pwd exchanged in call signaling. If a 3PCC can mangle them, ICE can't prevent the connectivity check from succeeding. If it is deemed a problem, it might need an ICE extension to fail the connectivity check b/w A and C. Muthu From: Martin Thomson [mailto:martin.thomson@gmail.com] Sent: Tuesday, December 03, 2013 11:08 AM To: Muthu Arul Mozhi Perumal (mperumal) Cc: rtcweb@ietf.org; Magnus Westerlund; Cullen Jennings (fluffy) Subject: RE: [rtcweb] Consent alternative I think that you misunderstood. This looks like a restarted ICE to A (from B), but it is really an entirely new session to C. It completes because C is unwittingly duped into briefly visiting B's page, which only needs to be long enough to clear a single connectivity check. On Dec 2, 2013 8:30 PM, "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com<mailto:mperumal@cisco.com>> wrote: > > |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<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<mailto:rtcweb@ietf.org> > |Subject: Re: [rtcweb] Consent alternative > | > |On 29 November 2013 05:40, Magnus Westerlund > |<magnus.westerlund@ericsson.com<mailto: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<mailto:rtcweb@ietf.org> > |https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative tim panton
- Re: [rtcweb] Consent alternative Bernard Aboba
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative tim panton
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Lorenzo Miniero
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Magnus Westerlund
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Dan Wing
- Re: [rtcweb] Consent alternative Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Dan Wing
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Consent alternative Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Consent alternative Harald Alvestrand
- Re: [rtcweb] Consent alternative Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Tirumaleswar Reddy (tireddy)