Re: [rtcweb] Consent alternative

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

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:[e-mail]]
|Sent: Thursday, December 05, 2013 12:08 AM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [e-mail]; Magnus Westerlund; Cullen Jennings (fluffy)
|Subject: Re: [rtcweb] Consent alternative
|
|On 3 December 2013 21:08, Muthu Arul Mozhi Perumal (mperumal)
|<[e-mail]> 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.