Subject: [rtcweb] What is consent?

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Sep 2012 17:30:07 -0700

What specific properties of a STUN Binding request does the browser
use to determine that the peer has consented to receive packets?

>From what I can infer, it's simply the existence of a response.  That
is insufficient.

-security says:
   [...]  ICE provides this verification as
   well, by using the STUN credentials as a form of per-session shared
   secret.  Those credentials are known to the Web application, but
   would need to also be known and used by the STUN-receiving element to
   be useful.

But that's not strictly correct.  The Binding response necessarily
does not include MESSAGE-INTEGRITY, which is the critical tie to
per-session credentials.

What then would prevent the browser from mistaking a response from a
STUN server as consent?

The STUN server doesn't need to check MESSAGE-INTEGRITY and USERNAME
is systematically ignored where it is not used, so we can't rely on
the server doing something helpful for itself.  I imagine that
stunserver.org could be made safe because it doesn't provide
FINGERPRINT in responses (it's 3489 compliant, not 5389).  But what a
5389 STUN server?

Hopefully, I'm just missing something.  But this has been bugging me.

--Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Sep 2012 17:44:47 -0700

> does not include MESSAGE-INTEGRITY, which is the critical tie to

You lost me here.  RFC 5389 specifically requires that if the
client provided MESSAGE-INTEGRITY in the Binding Response
in S 10.1.2:

   If these checks pass, the agent continues to process the request or
   indication.  Any response generated by a server MUST include the
   MESSAGE-INTEGRITY attribute, computed using the password utilized to
   authenticate the request.  The response MUST NOT contain the USERNAME
   attribute.

And the client is required to check it in 10.1.3:

10.1.3.  Receiving a Response

   The client looks for the MESSAGE-INTEGRITY attribute in the response.
   If present, the client computes the message integrity over the
   response as defined in Section 15.4, using the same password it
   utilized for the request.  If the resulting value matches the
   contents of the MESSAGE-INTEGRITY attribute, the response is
   considered authenticated.  If the value does not match, or if
   MESSAGE-INTEGRITY was absent, the response MUST be discarded, as if
   it was never received.  This means that retransmits, if applicable,
   will continue.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Sep 2012 09:09:00 -0700

Clearly, I did miss something.  Obviously, this relates to the bit in
ICE where it requires that the STUN backward compatibility measures
are not used.

But it didn't really answer my question.

Clearly, an RFC 3489 STUN server will not pass this basic test.  That
means that we can safely exclude servers like stunserver.org from the
set of consenting peers.

I suspect that for practical reasons we have to tolerate missing
MESSAGE-INTEGRITY and FINGERPRINT.  That means we can at least use old
servers to collect server reflexive addresses.  For those old servers
it's trivial to use the absence of either parameter as an indication
that they do not provide consent.

But the question stands: for STUN servers that are 5389 compliant,
what distinguishes the STUN server from a consenting peer?

--Martin

p.s. I reached my conclusion for the following reasons:
1. Section 7.1.3.2 of RFC 5245, which I presumed to be
complete...which it is, sort of.
2. MESSAGE-INTEGRITY is only of questionable utility in the response
if you assume that the server is ignoring requests that don't have a
valid MESSAGE-INTEGRITY.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Sep 2012 09:22:36 -0700

> if you assume that the server is ignoring requests that don't have a

I'm really not following this.

Responses from the server need to *contain* the MESSAGE-INTEGRITY
field and otherwise are not taken as evidence of consent. This field can
only be generated by a server that has the ICE credentials. So, obviously,
a legacy STUN server won't generate that.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Sep 2012 09:34:47 -0700

> a legacy STUN server won't generate that.

It's clear that I'm just being thick.

The STUN server (legacy or otherwise) won't have a password and wont
generate MESSAGE-INTEGRITY.

I apologise for wasting your (and everyone else's) time.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 11 Sep 2012 18:49:58 +0200

> I apologise for wasting your (and everyone else's) time.
The terms might have gotten confused, since STUN is used in two modes:

- With a STUN server, to identify reflexive addresses
- With a peer, to verify ability to communicate, and to verify continued 
consent.

We don't want to mandate credentials for the first one.
We do want to mandate credentials for the second.

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Sep 2012 11:29:28 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Harald Alvestrand
> Sent: Tuesday, September 11, 2012 9:50 AM
> To: [email-masked]
> Subject: Re: [rtcweb] What is consent?
> 

Right.  The confusion is that ICE uses the STUN protocol for
two purposes:  to collect reflexive addresses, and to
perform connectivity checks with peers.  In RTCWEB, we plan
to additionally use connectivity checks for "consent", so
the STUN protocol will be used for three different purposes.

(And four if we count TURN, which also uses the STUN packet
format.)

-d

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Sep 2012 14:29:14 -0500

Eric Rescorla said: 

"Responses from the server need to *contain* the MESSAGE-INTEGRITY field and
otherwise are not taken as evidence of consent. This field can only be
generated by a server that has the ICE credentials. So, obviously, a legacy
STUN server won't generate that."

[BA] While the presence of the MESSAGE-INTEGRITY field is a necessary
condition, is it sufficient to demonstrate consent? For example, does the
nominated flag need to be set to true?  RFC 5245 Section 7.1.3.2.4 says: 

7.1.3.2.4.  Updating the Nominated Flag

   If the agent was a controlling agent, and it had included a USE-
   CANDIDATE attribute in the Binding request, the valid pair generated
   from that check has its nominated flag set to true.  This flag
   indicates that this valid pair should be used for media if it is the
   highest-priority one amongst those whose nominated flag is set.  This
   may conclude ICE processing for this media stream or all media
   streams; see Section 8.

   If the agent is the controlled agent, the response may be the result
   of a triggered check that was sent in response to a request that
   itself had the USE-CANDIDATE attribute.  This case is described in
   Section 7.2.1.5, and may now result in setting the nominated flag for
   the pair learned from the original request.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Sep 2012 16:39:06 -0700

> Behalf Of Bernard Aboba
> Sent: Tuesday, September 11, 2012 12:29 PM
> To: 'Eric Rescorla'
> Cc: [email-masked]

For ICE Mobility (draft-wing-mmusic-ice-mobility), we might want to 
keep other candidates available, but inactive.  Over those other
candidates we would not signal USE-CANDIDATE, but we would want to
be able to switch to the other candidate as quickly as possible
(ideally, switch over immediately).  Similar considerations might 
apply to multipath RTP (draft-singh-avtcore-mprtp), too.
 
-d

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Sep 2012 22:33:58 -0500

>> Dan Wing said:

[BA] My question is whether the browser has a legitimate reason to send media to a destination that is not part of a valid pair for which the nominated flag is set to true, as per RFC 5245 Section 7.1.3.2.4.  For mobility you can still signal USE-CANDIDATE but not use the pair if another pair had higher priority.

---

From: Lishitao <[email-masked]>
Date: Wed, 12 Sep 2012 06:50:43 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Wednesday, September 12, 2012 11:34 AM
To: Eric Rescorla
Cc: [email-masked]
Subject: Re: [rtcweb] What is consent?

Dan Wing said:

-d

I donot think rfc 5245 allows this, it only allow only one pair with the USE-CANDIDATE attribute present.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Sep 2012 07:17:07 -0500

On Sep 12, 2012, at 1:51, "Lishitao" <[email-masked]> wrote:
> apply to multipath RTP 

[BA] But in that case you would want to use the pair, no?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Sep 2012 08:57:08 -0700

There are a number of things that concern me regarding this.

Firstly, USE-CANDIDATE can be sent on multiple pairs over time.
Particularly if the first pair fails for some reason.  Blocking
nominations after the first would prevent failover, as well as things
like multipath or confusing cases where there are multiple components
using the same set of local candidates (c.f., BUNDLE backward
compatibility scenarios).

I don't think that USE-CANDIDATE is sufficient or necessary for
consent.  Nomination is asymmetric in nature; only the controlling
peer can send it.  The controlled peer has no way to know that the
nomination check wasn't spoofed.  After all, that is the reason both
peers send connectivity checks.  The controlled peer then can't attach
any real significance to the nomination.  That isn't inherently a
problem - the controlled peer is still making checks and it is those
checks that verify that the controlling peer is willing to receive
packets at those addresses.

However, the underlying concern Bernard alludes to is a real one.  Not
only does consent indicate that I can send an arbitrary volume of data
to the checked host, as a natural consequence of ICE checking, there
is a decent chance that I get a large number of options, all of which
accept that arbitrary volume of data.

--Martin

On 12 September 2012 05:17, Bernard Aboba <[email-masked]> wrote:
> [BA] My question is whether the browser has a legitimate reason to send
> media to a destination that is not part of a valid pair for which the
> nominated flag is set to true, as per RFC 5245 Section 7.1.3.2.4.  For
> mobility you can still signal USE-CANDIDATE but not use the pair if another
> pair had higher priority.
>
>
>
>
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 12 Sep 2012 10:39:01 -0700

> Behalf Of Martin Thomson
> Sent: Wednesday, September 12, 2012 8:57 AM
> To: Bernard Aboba
> Cc: [email-masked]

The volume of data is separate from USE-CANDIDATE, though.  ICE does
not currently have a way to indicate bandwidth.  

There was a bandwidth extension for TURN, but it did not achieve
working group consensus and is not in the TURN RFC.  There is
a bandwidth extension to ICE that Microsoft documents and I believe
use in their products, http://msdn.microsoft.com/en-us/library/cc339480, 
MS-ICE2BWM and MS-TURNBWM.

-d

> > I donot think rfc 5245 allows this, it only allow only one pair with
> the
> > USE-CANDIDATE attribute present.
> >
> >

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Sep 2012 10:55:50 -0700

> not currently have a way to indicate bandwidth.

Yes.

> MS-ICE2BWM and MS-TURNBWM.

There are two bandwidth-related things in use.  One is related to
bandwidth estimation and not really pertinent to this.  The other
potentially relevant one is the bandwidth parameter (the one that
never reached consensus) is used to manage bandwidth for relay
allocations.

The latter is interesting to me, particularly if that parameter can be
applied to ICE.  There are some gotchas that need careful
consideration, particularly around this area of having consent on
multiple valid candidate pairs.

--Martin

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 12 Sep 2012 16:39:56 -0700

> multiple valid candidate pairs.
I may be hopelessly naive here, but isn't the b= parameter of the SDP 
negotiation supposed to give an upper limit on how much data the 
recipient expects to receive on a connection?

RFC 3264 section 5.1 (unicast offer):

    If the bandwidth attribute is present for a stream, it indicates the
    desired bandwidth that the offerer would like to receive.

Section 6.1 (unicast answer):

    The answerer MAY include a bandwidth attribute for any media stream;
    this indicates the bandwidth that the answerer would like the offerer
    to use when sending media.

(note that "media stream" here is != MediaStream)

The browser being used to stage an attack will of course not know this 
value, since its signalling is controlled by the attacker, but the 
browser being attacked will be able to tell the difference between a 
within-contract amount of data and an out-of-contract amount of data.

               Harald

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Sep 2012 16:49:38 -0700

On 12 September 2012 16:39, Harald Alvestrand <[email-masked]> wrote:
> negotiation supposed to give an upper limit on how much data the recipient
> expects to receive on a connection?

SDP is completely unauthenticated.  We have to assume that it is
provided by a web attacker.

That doesn't mean that the SDP bandwidth isn't a limit, or that it
shouldn't be respected.  On the other hand, if it's set to 10
bazillion, it doesn't give an RTP sender permission to send that much
data toward a peer.

--Martin

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Sep 2012 19:02:53 -0500

On Sep 12, 2012, at 6:40 PM, "Harald Alvestrand" <[email-masked]> wrote:
> 
> The browser being used to stage an attack will of course not know this value, since its signalling is controlled by the attacker, but the browser being attacked will be able to tell the difference between a within-contract amount of data and an out-of-contract amount of data.
> 
>              Harald

[BA] Correct, but how does the receiver turn off the spigot? Is this handled via circuit breakers?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Sep 2012 17:13:59 -0700

By not returning consent checks.