Re: [rtcweb] Consent alternative

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Based on the discussion there are two different attacks to consider:

a)The attack mentioned by Magnus which is an on-path attack. This attacker can do lot more damage like dropping packets, modifying packets etc. so we may have lot more problems independent of whether STUN or DTLS consent is used. Further in this case since attacker controls the RTCWEB signaling there seems to be no defense.

b)Off-path attack that Martin had mentioned where B is only capable of spoofing IP address of C. This threat can be mitigated by sending DTLS heartbeat with sufficient entropy that guessing would be difficult for an off-path attacker. This off-path attack can also be solved by sending STUN consent whenever the IP address of the remote peer changes and STUN provides strong entropy by using random Transaction ID (96-bit).

If we consider B attacker is also capable of sniffing packets on wire, DTLS heartbeat does not have any benefit over STUN consent because B can sniff the DTLS heartbeat request sent by A and generate response. Since B seems be part of signaling exchange it will have access to fingerprint, short-term username/password etc.

-Tiru.
From: rtcweb [mailto:[e-mail]] On Behalf Of Martin Thomson
Sent: Tuesday, December 03, 2013 11:08 AM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Cullen Jennings (fluffy); [e-mail]
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)" <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Martin Thomson
> |Sent: Tuesday, December 03, 2013 4:14 AM
> |To: Magnus Westerlund
> |Cc: Cullen Jennings (fluffy); [e-mail]<mailto:[e-mail]>
> |Subject: Re: [rtcweb] Consent alternative
> |
> |On 29 November 2013 05:40, Magnus Westerlund
> |<[e-mail]<mailto:[e-mail]>> 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
> |[e-mail]<mailto:[e-mail]>
> |https://www.ietf.org/mailman/listinfo/rtcweb