Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-00.txt

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 May 2012 23:58:46 +0200

Apologies for not catching this until it came up on RTCWEB recently....

I have two issues with draft-muthu-behave-consent-freshness:

1) I can't tell from the draft which direction an exchange verifies 
consent for

2) I don't think I am convinced by the arguments against including 
MESSAGE-INTEGRITY.

My attack scenario:

A -------------------------- >>>>>> ---- media --->>>>>>>>>>> B
                                            M - may listen to the media 
stream, can send packets to A

Attack scenario 1:
B wishes to stop receiving media from A. M wishes to keep media flowing 
in order to inconvenience B somehow.

If A is supposed to send a Consent-Request, M has to capture the 
Consent-Request packet and reply with a Consent Success response, 
copying the transaction ID. Since B has presumably stopped listening, B 
won't bother generating a Consent Error.

If B is supposed to send the Consent-Request, M can simply manufacture a 
Consent-Request every 30 seconds; it doesn't care what happens to the 
Consent Success response.

Attack scenario 2:
B wishes to receive media from A. M wishes to stop the media flow.

If M listens to the media stream, M can fake a single Consent Error 
response to a Consent Request.

My suggested modifications to the I-D:

- Reinstate use of USERNAME and MESSAGE-INTEGRITY.  This protects 
against all the attacks above.
- Make it clear that A (media sender) is the one generating Consent 
Request. That makes attack 1 more difficult.
- Remove Consent Error. It's useless, and can form an attack surface.

Hope this feedback is useful.

                       Harald

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 May 2012 08:40:17 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Harald Alvestrand
> Sent: Monday, May 07, 2012 2:59 PM
> To: [email-masked]
> Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-
> freshness-00.txt
> 

That will be improved in the next version.  

The sender of a stream has to obtain consent before sending that stream.

> stream, can send packets to A

So, "M" is on the media path.

> copying the transaction ID.

Right, that is what "M" would do.

But M, being on path, could send its own packets towards B.  M could
perhaps even spoof A's address when sending its own packets towards
B.

Similar attacks are possible if the connection between A and B
is TCP, M is on-path, and M can spoof B's address.  With TCP, M sees 
the TCP sequence number and responds with a spoofed ACK.  To my 
knowledge, the only protections for such a TCP attack are 
TCP-MD5 and TCP-AO (both don't work across NATs, which are 
pervasive on home networks).  Or of course tunneling TCP over an 
encryption tunnel (IPsec or DTLS).

> Since B has presumably stopped listening, B

Comparing this to TCP again, if the connection between A and B was 
TCP and M can spoof B's address, M could send a TCP RST.

> against all the attacks above.

I agree that MESSAGE-INTEGRITY does protect from an on-path
attacker.

But if the requirement is to protect ourselves from on-path 
attackers, it means we cannot bring up a TCP channel -- not 
between the peers and not to a TURN server (because we don't
know where the attacker, M, is located).

> - Remove Consent Error. It's useless, and can form an attack surface.

Consent Error allows a receiver to immediately quit receiving packets --
much like RTCP BYE (back in the day).  But RTCP BYE had no authentication,
so nobody uses it.

The purpose of Consent Error is to more quickly stop an undesired flow.

If RTCWEB is really going to use SRTP everywhere, we can rely on
the ability to do an SRTCP BYE and eliminate Consent Error.

-d

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 08 May 2012 19:15:45 +0200

Higher-level response.....

I'm not sure the comparision to TCP is entirely appropriate. The 
discussion of "voice hammer" seemed to indicate that media streams 
(which "just keep on coming" until the next consent check) are more 
"dangerous" than TCP streams (which require a continuous stream of ACKs).

that said, the setup consent requirement does not protect against the 
combination of a malicious site (to steal the credentials) and an 
on-path attacker (to steal the transaction IDs). So perhaps it's OK to 
not protect against an on-path attacker; the only attack that can be 
mounted that way is an attack where a flow was once legitimate and is no 
longer desired, which doesn't seem a huge case.

> The sender of a stream has to obtain consent before sending that stream.
And while sending that stream, I assume.
>> A -------------------------->>>>>>  ---- media --->>>>>>>>>>>  B
Not necessarily. To give a contrived example, consider a case where B 
has a wireless hop to it where it associates securely with the sender, 
but does not encrypt the packets, and has good spoofing filters, while A 
is generically Internet-connected and not spoofing-filtered; M can 
listen to packets, and send to A with B's source address, but cannot 
inject packets to B.

Told you it was contrived :-)
> encryption tunnel (IPsec or DTLS).

I'm not sure the attacks are the same; the TCP attack buys you one 
window of data, while the consent-freshness attack buys you 30 seconds 
of media. Is there a significant difference in bang-for-the-buck?
> TCP and M can spoof B's address, M could send a TCP RST.
Yup, and this is a technique known to be used by the Great Firewall. 
When creating a new protocol, shouldn't we take the opportunity to not 
open ourselves to well known attacks?
> know where the attacker, M, is located).
The way draft-ietf-rtcweb-security-04 is formulated, the requirement is 
to protect against media flows (the term "voice hammer" is not used 
there). It does not protect against the combination of a malicuous site 
(required to steal the credentials) and an on-path attacker (required to 
steal the transaction IDs). But it will protect against one of the two.

See comments above about whether media flows are more harmful than TCP 
flows, and about whether we should repeat existing vulnerabilities.
> The purpose of Consent Error is to more quickly stop an undesired flow.
Is the idea that one would send Consent Error without a Consent Request?
Or is it OK to require that the recipient hang around for 30 seconds 
after closing in order to say "no" to a Consent Request?
> the ability to do an SRTCP BYE and eliminate Consent Error.

Seems clearer to me.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 May 2012 10:29:05 -0700

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Tuesday, May 08, 2012 10:16 AM
> To: Dan Wing
> Cc: [email-masked]
> mounted that way is an attack where a flow was once legitimate and is
> no longer desired, which doesn't seem a huge case.

Voice Hammer is described in ICE (RFC5245) and prevented by the
initial ICE connectivity checks -- which use MESSAGE-INTEGRITY.  
This protection is necessary for RTP flows and for SDESC-keyed 
SRTP.

(However, if WEBRTC uses DTLS-SRTP handshakes, WEBRTC can use DTLS-
SRTP to protect from the Voice Hammer attack, and could eliminate
MESSAGE-INTEGRITY, which is helpful to reduce CPU load.  I hope 
to have an I-D published soon to explain that.)

After a media flow is authorized by the receiver, the Voice Hammer 
attack goes away, as you mention above, which leaves us with the
continued consent problem - the receiver crashes, gets unplugged, or 
is still powered on and running properly but no longer wants to 
receive the media stream.  It was for that case we had the
Consent Error message.  I suggest we can eliminate the Consent
Error message if WEBRTC has SRTP, because we can use SRTCP BYE.
But if WEBRTC allows RTP, it's useless to send an RTCP BYE, 
because it will be ignored (because it can be trivially spoofed 
by an off-path attacker).   We could ignore that problem as
one of the risks of running plain RTP, or keep Consent Error
for that case.  It comes down to if WEBRTC really chooses to
use SRTP everywhere or if WEBRTC allows RTP to be used in some
cases.

-d

> >> If B is supposed to send the Consent-Request, M can simply
> manufacture
> >> a

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 9 May 2012 00:21:29 +0530

|I suggest we can eliminate the Consent Error message if 
|WEBRTC has SRTP, because we can use SRTCP BYE.

I see two issues relying on SRTCP BYE:
1. I think BYE isn't mandatory to send as per RFC3550. There are cases
where a participant may leave a session without sending a BYE. Here is a
snip from section 6.3.7 of RFC3550:

   A participant that does not want to wait for the above 
   mechanism to allow transmission of a BYE packet MAY leave
   the group without sending a BYE at all.  That participant
   will eventually be timed out by the other group members.

That doesn't prevent WebRTC mandating BYE, however. It would probably
require some signaling (in the form an SDP attribute).

2. BYE isn't reliably sent. WebRTC could add reliability and mandate it,
though. Consent Error would be much simpler, I think.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dan Wing (dwing)
|Sent: Tuesday, May 08, 2012 10:59 PM
|To: 'Harald Alvestrand'
|Cc: [email-masked]
|Subject: Re: [BEHAVE] FW: I-DAction:
draft-muthu-behave-consent-freshness-00.txt
|
|> -----Original Message-----
|> From: Harald Alvestrand [mailto:[email-masked]]
|> Sent: Tuesday, May 08, 2012 10:16 AM
|> To: Dan Wing
|> Cc: [email-masked]
|> Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-
|> freshness-00.txt
|>
|> Higher-level response.....
|>
|> I'm not sure the comparision to TCP is entirely appropriate. The
|> discussion of "voice hammer" seemed to indicate that media streams
|> (which "just keep on coming" until the next consent check) are more
|> "dangerous" than TCP streams (which require a continuous stream of
|> ACKs).
|>
|> that said, the setup consent requirement does not protect against the
|> combination of a malicious site (to steal the credentials) and an
|> on-path attacker (to steal the transaction IDs). So perhaps it's OK
to
|> not protect against an on-path attacker; the only attack that can be
|> mounted that way is an attack where a flow was once legitimate and is
|> no longer desired, which doesn't seem a huge case.
|
|Voice Hammer is described in ICE (RFC5245) and prevented by the
|initial ICE connectivity checks -- which use MESSAGE-INTEGRITY.
|This protection is necessary for RTP flows and for SDESC-keyed
|SRTP.
|
|(However, if WEBRTC uses DTLS-SRTP handshakes, WEBRTC can use DTLS-
|SRTP to protect from the Voice Hammer attack, and could eliminate
|MESSAGE-INTEGRITY, which is helpful to reduce CPU load.  I hope
|to have an I-D published soon to explain that.)
|
|After a media flow is authorized by the receiver, the Voice Hammer
|attack goes away, as you mention above, which leaves us with the
|continued consent problem - the receiver crashes, gets unplugged, or
|is still powered on and running properly but no longer wants to
|receive the media stream.  It was for that case we had the
|Consent Error message.  I suggest we can eliminate the Consent
|Error message if WEBRTC has SRTP, because we can use SRTCP BYE.
|But if WEBRTC allows RTP, it's useless to send an RTCP BYE,
|because it will be ignored (because it can be trivially spoofed
|by an off-path attacker).   We could ignore that problem as
|one of the risks of running plain RTP, or keep Consent Error
|for that case.  It comes down to if WEBRTC really chooses to
|use SRTP everywhere or if WEBRTC allows RTP to be used in some
|cases.
|
|-d
|
|
|>
|>
|> On 05/08/2012 05:40 PM, Dan Wing wrote:
|> >> -----Original Message-----
|> >> From: [email-masked] [mailto:[email-masked]] On
|> >> Behalf Of Harald Alvestrand
|> >> Sent: Monday, May 07, 2012 2:59 PM
|> >> To: [email-masked]
|> >> Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-
|> >> freshness-00.txt
|> >>
|> >> Apologies for not catching this until it came up on RTCWEB
|> recently....
|> >>
|> >> I have two issues with draft-muthu-behave-consent-freshness:
|> >>
|> >> 1) I can't tell from the draft which direction an exchange
verifies
|> >> consent for
|> > That will be improved in the next version.
|> >
|> > The sender of a stream has to obtain consent before sending that
|> stream.
|> And while sending that stream, I assume.
|> >> 2) I don't think I am convinced by the arguments against including
|> >> MESSAGE-INTEGRITY.
|> >>
|> >> My attack scenario:
|> >>
|> >> A -------------------------->>>>>>  ---- media --->>>>>>>>>>>  B
|> >>                                              M - may listen to the
|> media
|> >> stream, can send packets to A
|> > So, "M" is on the media path.
|> Not necessarily. To give a contrived example, consider a case where B
|> has a wireless hop to it where it associates securely with the
sender,
|> but does not encrypt the packets, and has good spoofing filters,
while
|> A
|> is generically Internet-connected and not spoofing-filtered; M can
|> listen to packets, and send to A with B's source address, but cannot
|> inject packets to B.
|>
|> Told you it was contrived :-)
|> >
|> >> Attack scenario 1:
|> >> B wishes to stop receiving media from A. M wishes to keep media
|> flowing
|> >> in order to inconvenience B somehow.
|> >>
|> >> If A is supposed to send a Consent-Request, M has to capture the
|> >> Consent-Request packet and reply with a Consent Success response,
|> >> copying the transaction ID.
|> > Right, that is what "M" would do.
|> >
|> > But M, being on path, could send its own packets towards B.  M
could
|> > perhaps even spoof A's address when sending its own packets towards
|> > B.
|> >
|> >
|> > Similar attacks are possible if the connection between A and B
|> > is TCP, M is on-path, and M can spoof B's address.  With TCP, M
sees
|> > the TCP sequence number and responds with a spoofed ACK.  To my
|> > knowledge, the only protections for such a TCP attack are
|> > TCP-MD5 and TCP-AO (both don't work across NATs, which are
|> > pervasive on home networks).  Or of course tunneling TCP over an
|> > encryption tunnel (IPsec or DTLS).
|>
|> I'm not sure the attacks are the same; the TCP attack buys you one
|> window of data, while the consent-freshness attack buys you 30
seconds
|> of media. Is there a significant difference in bang-for-the-buck?
|> >> Since B has presumably stopped listening, B
|> >> won't bother generating a Consent Error.
|> >>
|> >> If B is supposed to send the Consent-Request, M can simply
|> manufacture
|> >> a
|> >> Consent-Request every 30 seconds; it doesn't care what happens to
|> the
|> >> Consent Success response.
|> >>
|> >> Attack scenario 2:
|> >> B wishes to receive media from A. M wishes to stop the media flow.
|> >>
|> >> If M listens to the media stream, M can fake a single Consent
Error
|> >> response to a Consent Request.
|> > Comparing this to TCP again, if the connection between A and B was
|> > TCP and M can spoof B's address, M could send a TCP RST.
|> Yup, and this is a technique known to be used by the Great Firewall.
|> When creating a new protocol, shouldn't we take the opportunity to
not
|> open ourselves to well known attacks?
|> >> My suggested modifications to the I-D:
|> >>
|> >> - Reinstate use of USERNAME and MESSAGE-INTEGRITY.  This protects
|> >> against all the attacks above.
|> > I agree that MESSAGE-INTEGRITY does protect from an on-path
|> > attacker.
|> >
|> > But if the requirement is to protect ourselves from on-path
|> > attackers, it means we cannot bring up a TCP channel -- not
|> > between the peers and not to a TURN server (because we don't
|> > know where the attacker, M, is located).
|> The way draft-ietf-rtcweb-security-04 is formulated, the requirement
is
|> to protect against media flows (the term "voice hammer" is not used
|> there). It does not protect against the combination of a malicuous
site
|> (required to steal the credentials) and an on-path attacker (required
|> to
|> steal the transaction IDs). But it will protect against one of the
two.
|>
|> See comments above about whether media flows are more harmful than
TCP
|> flows, and about whether we should repeat existing vulnerabilities.
|> >> - Make it clear that A (media sender) is the one generating
Consent
|> >> Request. That makes attack 1 more difficult.
|> >> - Remove Consent Error. It's useless, and can form an attack
|> surface.
|> > Consent Error allows a receiver to immediately quit receiving
packets
|> --
|> > much like RTCP BYE (back in the day).  But RTCP BYE had no
|> authentication,
|> > so nobody uses it.
|> >
|> > The purpose of Consent Error is to more quickly stop an undesired
|> flow.
|> Is the idea that one would send Consent Error without a Consent
|> Request?
|> Or is it OK to require that the recipient hang around for 30 seconds
|> after closing in order to say "no" to a Consent Request?
|> > If RTCWEB is really going to use SRTP everywhere, we can rely on
|> > the ability to do an SRTCP BYE and eliminate Consent Error.
|>
|> Seems clearer to me.
|> >
|
|_______________________________________________
|Behave mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 May 2012 12:55:31 -0700

> From: Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]]
> Sent: Tuesday, May 08, 2012 11:51 AM
> To: Dan Wing (dwing); Harald Alvestrand
> Cc: [email-masked]
> Subject: RE: [BEHAVE] FW: I-DAction: draft-muthu-behave-consent-
> freshness-00.txt
> 

I believe that last sentence is a quiet assumption that the lack
of RTCP receiver reports would cause a timeout, or that some
higher-level function (the human) would terminate the call.

> 2. BYE isn't reliably sent. WebRTC could add reliability and mandate
> it, though. Consent Error would be much simpler, I think.

And another point, in favor of your argument for keeping Consent
Error:  we cannot send SRTCP BYE on the data channel (SRTP channel),
and need some way for that channel to be aborted faster than
timing out.
 
-d

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 08 May 2012 23:32:01 +0200

> higher-level function (the human) would terminate the call.
The RTP procedures in RFC 3550 specify when a recipient that doesn't 
send RR RTCP packets is deemed to have left an RTP session. It's not a 
quiet assumption; it's part of the RTP protocol.

But I still don't understand Consent Error.

I asked this before:
Is the intent of Consent Error that the recipient of the stream has to 
hang around for at least 30 seconds in order to reply to the next 
Consent Request, in order to make the streams stop?

> and need some way for that channel to be aborted faster than
SRTP data channel? Do you mean SCTP?
SCTP associations are closed using the SHUTDOWN message (RFC 4960 
section 3.3.8), or ABORT (section 3.3.7) if you're in a hurry.

Since it's carried on top of the DTLS layer, it can't be spoofed.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 May 2012 16:05:47 -0700

> Sent: Tuesday, May 08, 2012 2:32 PM
> To: Dan Wing
> Cc: 'Muthu Arul Mozhi Perumal (mperumal)'; [email-masked]
> Subject: Re: [BEHAVE] FW: I-DAction: draft-muthu-behave-consent-
> freshness-00.txt
> 
> >> where a participant may leave a session without sending a BYE. Here
> is
> >> a

It's to allow informing the sender that consent (to continue to 
send media) has been revoked.  Without it, the sender will send 2 or
3 consent checks, and not receive responses, before the sender 
believes consent has been revoked.

Consider 'Consent Error' sortof like sending an ICMP.  Everything
works without ICMP, but errors are recovered faster with ICMP.  Same
with Consent Error -- errors are recovered faster.

> SRTP data channel? Do you mean SCTP?

Sorry, yes -- I meant to type "SCTP".

> Since it's carried on top of the DTLS layer, it can't be spoofed.

Great.

-d