Re: [rtcweb] Consent alternative

Martin Thomson <martin.thomson@gmail.com> Tue, 03 December 2013 05:38 UTC

Return-Path: <martin.thomson@gmail.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 606111AE04A for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 21:38:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 l_HiFF0w5Tei for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 21:38:18 -0800 (PST)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF0A1AE049 for <rtcweb@ietf.org>; Mon, 2 Dec 2013 21:38:17 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id z2so4436393wiv.13 for <rtcweb@ietf.org>; Mon, 02 Dec 2013 21:38:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C2EoCiDjRhn6nHyKHiaL0492LerBYDLRB5DIDOuTJDg=; b=QVvjfqH6jM6SA8MqkkvxlFSarjBvHUDvcC4gaEFHTLOdsN1mSXzexlw5bVbsZb5RDS 4cCJt99t7MaiHvIMWmwiHHdhyXYLAB/ZPkth5rEAMYMbZfmujcUVz0plYyQp2jNcEsAe EOjEMaz5W6ToIJmzzdymf9ABuiJYv0ULJM2F/VC35rzEoq5+HbO6mC0bg7H1PXCXfg67 +LdPxJrQPGPlPBRZR2Dwt/PZVM8/rr1/KjAtFYFx8EvN9pjGx3E+6e3/dJ/LehthwWDQ T4iQBTdu766US+1hekSdjeUH3eEh9JzZPZg9LNnAeiY9jOn0YyZ4sKPQMLj8fIqK2F+4 PFtA==
MIME-Version: 1.0
X-Received: by 10.180.36.105 with SMTP id p9mr739407wij.58.1386049094500; Mon, 02 Dec 2013 21:38:14 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Mon, 2 Dec 2013 21:38:14 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Mon, 2 Dec 2013 21:38:14 -0800 (PST)
In-Reply-To: <E721D8C6A2E1544DB2DEBC313AF54DE22436FBD9@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>
Date: Mon, 02 Dec 2013 21:38:14 -0800
Message-ID: <CABkgnnUy3HxvsqYfwspEQ9_g1frUuFF4rwD-hTz45UzCr1fTBw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Muthu Arul Mozhi Perumal, (mperumal)" <mperumal@cisco.com>
Content-Type: multipart/alternative; boundary="e89a8f503562eb471804ec9ab320"
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, 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 05:38:21 -0000

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