Subject: Re: [rtcweb] Consent alternative

From: Martin Thomson <[email-masked]>
Date: Mon, 2 Dec 2013 14:44:28 -0800

On 29 November 2013 05:40, Magnus Westerlund
<[email-masked]> 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.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 3 Dec 2013 04:30:13 +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:[email-masked]] On Behalf Of Martin Thomson
|Sent: Tuesday, December 03, 2013 4:14 AM
|To: Magnus Westerlund
|Cc: Cullen Jennings (fluffy); [email-masked]
|Subject: Re: [rtcweb] Consent alternative
|
|On 29 November 2013 05:40, Magnus Westerlund
|<[email-masked]> 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
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Mon, 2 Dec 2013 21:38:14 -0800

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)" <
[email-masked]> wrote:
> 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.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 3 Dec 2013 12:48:23 +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:[email-masked]]
Sent: Tuesday, December 03, 2013 11:08 AM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: [email-masked]; 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)" <[email-masked]<mailto:[email-masked]>> wrote:
> |From: rtcweb [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Martin Thomson
> |Cc: Cullen Jennings (fluffy); [email-masked]<mailto:[email-masked]>
> |<[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Dec 2013 08:55:22 -0800

On 3 December 2013 04:48, Muthu Arul Mozhi Perumal (mperumal)
<[email-masked]> wrote:
> 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.
>
>
>

I think that you have missed the point here.  The point is that A and
B share a DTLS connection, and B uses ICE to convince A to send
packets for that connection to C.  All this requires is that B is able
to spoof the source address of packets to appear as coming from C.
It's got nothing to do with 3PCC scenarios.

---

From: Dan Wing <[email-masked]>
Date: Tue, 3 Dec 2013 16:24:08 -0800

> heavyweight.  I'm not sure that it's that widely implemented either.

Requiring sending an ICE request (and receiving an ICE response) would also _almost_ work -- that is, when remote party claims to change their IP address not only is an ICE request from their IP address needed, but also need to send an ICE request to their new IP address and get an ICE response (same as you are saying to send them a DTLS heartbeat to their new address).  To thwart that, an ICE attacker would need to be on-path and we could envision places where B (the attacker in your enumerated list above) is on a shared network with C (victim), such as shared WiFi.  DTLS heartbeat prevents that attack because B (the attacker) doesn't know the necessary secrets to generate the DTLS heartbeat message (whereas with ICE, B would know the ICE username and ICE password).  If I have all that correct for how ICE consent could be attacked, it shows a security advantage of DTLS consent over ICE consent.

-d

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 4 Dec 2013 05:08:01 +0000

|I think that you have missed the point here. The point is that A and
|B share a DTLS connection, and B uses ICE to convince A to send
|packets for that connection to C. 

Can you describe that in terms of a real-world use case? I don't see how that is different from a 3PCC scenario where the 3PCC (e.g a call center agent) talks to both A and C, and transfers A to C (aka full-consult transfer). 

|All this requires is that B is able to spoof the source address of 
|packets to appear as coming from C.

B doesn't have to spoof anything at all -- for the ICE connectivity check to succeed b/w A and C, B just needs to send A's ice-ufrag and ice-pwd to C and vice versa.

Muthu

|-----Original Message-----
|From: Martin Thomson [mailto:[email-masked]]
|Sent: Tuesday, December 03, 2013 10:25 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]; Magnus Westerlund; Cullen Jennings (fluffy)
|Subject: Re: [rtcweb] Consent alternative
|
|On 3 December 2013 04:48, Muthu Arul Mozhi Perumal (mperumal)
|<[email-masked]> wrote:
|> 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.
|
|I think that you have missed the point here.  The point is that A and
|B share a DTLS connection, and B uses ICE to convince A to send
|packets for that connection to C.  All this requires is that B is able
|to spoof the source address of packets to appear as coming from C.
|It's got nothing to do with 3PCC scenarios.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Dec 2013 10:38:18 -0800

> Can you describe that in terms of a real-world use case? I don't see how that is different from a 3PCC scenario where the 3PCC (e.g a call center agent) talks to both A and C, and transfers A to C…

I'm not describing a use case, I'm describing an attack.  A 3PCC
transfer should result in a new DTLS connection.  That's a completely
different scenario.

> B doesn't have to spoof anything at all -- for the ICE connectivity check to succeed b/w A and C, B just needs to send A's ice-ufrag and ice-pwd to C and vice versa.

Yes, B does have to spoof something.  If B's goal is to cause A to
send packets to C without consent from C (or, more precisely, even
when C initially consents, then ceases to consent), then spoofing is
necessary.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Dec 2013 10:59:28 -0800

On 3 December 2013 16:24, Dan Wing <[email-masked]> wrote:
> Requiring sending an ICE request (and receiving an ICE response) would also _almost_ work -- that is, when remote party claims to change their IP address not only is an ICE request from their IP address needed, but also need to send an ICE request to their new IP address and get an ICE response (same as you are saying to send them a DTLS heartbeat to their new address).

Yes, almost.  If ICE restart didn't also correspond with a change in
ufrag/pwd it might.  As it stands, ICE restart and new victim look
exactly the same.

> To thwart that, an ICE attacker would need to be on-path and we could envision places where B (the attacker in your enumerated list above) is on a shared network with C (victim), such as shared WiFi.

In general, I find that on-path attackers aren't especially
interesting when it comes to DoS attacks.  Shared WiFi seems like it
might avoid the "directly on path" part, though since the attacker
disadvantages themselves as much as their victim, I don't worry.

> DTLS heartbeat prevents that attack because B (the attacker) doesn't know the necessary secrets to generate the DTLS heartbeat message (whereas with ICE, B would know the ICE username and ICE password).  If I have all that correct for how ICE consent could be attacked, it shows a security advantage of DTLS consent over ICE consent.

Yes.  That is definitely an advantage.

---

From: Dan Wing <[email-masked]>
Date: Wed, 4 Dec 2013 11:11:16 -0800

> disadvantages themselves as much as their victim, I don't worry.

Sure.  But the attacker doesn't need to remain on that shared network to continue the attack, so the attacker is not (necessarily) disadvantaging themselves -- the attacker just needed to see the packets on the wire and send a command-and-control message to another host that generates the spoofed ICE consent packets.  

-d

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Dec 2013 11:13:41 -0800

> Sure.  But the attacker doesn't need to remain on that shared network to continue the attack, so the attacker is not (necessarily) disadvantaging themselves -- the attacker just needed to see the p…

Good point.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 5 Dec 2013 04:43:19 +0000

Apparently, we are talking about different problems. Perhaps, a diagram showing the sequence of steps that lead to the attack you are describing might help me understand it.

|-----Original Message-----
|From: Martin Thomson [mailto:[email-masked]]
|Sent: Thursday, December 05, 2013 12:08 AM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]; Magnus Westerlund; Cullen Jennings (fluffy)
|Subject: Re: [rtcweb] Consent alternative
|
|On 3 December 2013 21:08, Muthu Arul Mozhi Perumal (mperumal)
|<[email-masked]> wrote:
|> |I think that you have missed the point here. The point is that A and
|> |B share a DTLS connection, and B uses ICE to convince A to send
|> |packets for that connection to C.
|>
|> Can you describe that in terms of a real-world use case? I don't see how that is different from a
|3PCC scenario where the 3PCC (e.g a call center agent) talks to both A and C, and transfers A to C
|(aka full-consult transfer).
|
|I'm not describing a use case, I'm describing an attack.  A 3PCC
|transfer should result in a new DTLS connection.  That's a completely
|different scenario.
|
|>
|> |All this requires is that B is able to spoof the source address of
|> |packets to appear as coming from C.
|>
|> B doesn't have to spoof anything at all -- for the ICE connectivity check to succeed b/w A and C, B
|just needs to send A's ice-ufrag and ice-pwd to C and vice versa.
|
|Yes, B does have to spoof something.  If B's goal is to cause A to
|send packets to C without consent from C (or, more precisely, even
|when C initially consents, then ceases to consent), then spoofing is
|necessary.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 5 Dec 2013 04:48:55 +0000

|-----Original Message-----
|From: rtcweb [mailto:[email-masked]] On Behalf Of Martin Thomson
|Sent: Thursday, December 05, 2013 12:29 AM
|To: Dan Wing (dwing)
|Cc: Cullen Jennings (fluffy); [email-masked]
|Subject: Re: [rtcweb] Consent alternative
|
|On 3 December 2013 16:24, Dan Wing <[email-masked]> wrote:
|> Requiring sending an ICE request (and receiving an ICE response) would also _almost_ work -- that
|is, when remote party claims to change their IP address not only is an ICE request from their IP
|address needed, but also need to send an ICE request to their new IP address and get an ICE response
|(same as you are saying to send them a DTLS heartbeat to their new address).
|
|Yes, almost.  If ICE restart didn't also correspond with a change in
|ufrag/pwd it might.  As it stands, ICE restart and new victim look
|exactly the same.

RFC5245 section 9.1.1.1:
   To restart ICE, an agent MUST change both the ice-pwd and the ice-
   ufrag for the media stream in an offer.

Muthu

|
|> To thwart that, an ICE attacker would need to be on-path and we could envision places where B (the
|attacker in your enumerated list above) is on a shared network with C (victim), such as shared WiFi.
|
|In general, I find that on-path attackers aren't especially
|interesting when it comes to DoS attacks.  Shared WiFi seems like it
|might avoid the "directly on path" part, though since the attacker
|disadvantages themselves as much as their victim, I don't worry.
|
|> DTLS heartbeat prevents that attack because B (the attacker) doesn't know the necessary secrets to
|generate the DTLS heartbeat message (whereas with ICE, B would know the ICE username and ICE
|password).  If I have all that correct for how ICE consent could be attacked, it shows a security
|advantage of DTLS consent over ICE consent.
|
|Yes.  That is definitely an advantage.
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Dec 2013 22:37:15 -0800

>    ufrag for the media stream in an offer.

My point exactly.  I don't like that part of RFC 5245 (though it's not
special in that regard, there are plenty of other points equally
worthy of contempt).