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

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 5 Mar 2012 02:57:16 +0530

This I-D describes a new STUN usage for enabling WebRTC implementations
to perform consent freshness. It is far from complete, but comments
(especially on the design considerations/approach) are welcome..

Muthu

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, March 05, 2012 2:14 AM
To: [email-masked]
Subject: I-D Action: draft-muthu-behave-consent-freshness-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : STUN Usage for Consent Freshness
	Author(s)       : Muthu Arul Mozhi Perumal
                          Dan Wing
                          Hadriel Kaplan
	Filename        : draft-muthu-behave-consent-freshness-00.txt
	Pages           : 10
	Date            : 2012-03-04

   This document describes a STUN usage that enables WebRTC
   implementations to verify the peer consent for continuing to receive
   traffic on a candidate pair ICE is using for a media component after
   session establishment.  Verification of peer consent is necessary to
   ensure that a malicious JavaScript cannot use the browser as a
   platform for launching attacks.  This form of consent verification
   also serves the purpose of refreshing NAT bindings.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-muthu-behave-consent-freshness
-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-muthu-behave-consent-freshness-
00.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Simon Perreault <[email-masked]>
Date: Mon, 05 Mar 2012 10:02:51 -0500

> (especially on the design considerations/approach) are welcome..

I had a *very* quick look at it, and have a few questions. They're 
mostly "explain it to me like a two year old" type questions, so maybe 
the answers could be added to the doc itself.

- Looking at section "6. STUN Consent Method Processing", I don't see 
any difference between a Binding request and a Consent request on the 
server side. So how could a Consent request have different semantics 
than a Binding request if they are processed identically by the server?

- Why a new method instead of a new attribute? A new attribute 
indicating additional semantics seems more appropriate to me because all 
Binding processing would automatically be inherited by Consent. E.g. in 
the future we define a new Binding attribute, chances are it would also 
apply to Consent. All you need is a way to indicate "this is a regular 
Binding request but *additionally* I'm asking if you consent to me 
sending you packets". The server would include the consent attribute in 
the response if it consents, otherwise, and if it doesn't support that 
attribute, it would just ignore it and reply like a normal Binding 
request, which would be useful. Also you would inherit a lot of text 
about the mechanics (e.g. sections 6.1-6.4 marked TBD would be unnecessary).

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 6 Mar 2012 23:36:35 +0530

|- Looking at section "6. STUN Consent Method Processing",
|I don't see any difference between a Binding request and 
|a Consent request on the server side. So how could a Consent 
|request have different semantics than a Binding request if 
|they are processed identically by the server?

To make sure I understand correctly, by a server you don't mean a STUN
server sitting in the Internet used for resolving the NAT'ed address,
right? Such a server isn't expected to receive a consent request.
Consent request/response is expected to be used b/w two endpoints
involved in a real-time communication session.

>From the server side, the main difference b/w the Binding request
processing and the Consent request processing is the message integrity
verification. While a Binding request in the ICE usage would require
verification of the message integrity using the short-term credential
mechanism, the consent request will not. A consent request is also not
expected to contain any other attribute except FINGERPRINT (and probably
SOFTWARE). So, once the server identifies it as a consent request based
on the message type fields in the STUN header, it would branch out of
Binding request processing and process the request as a consent request.

I agree this isn't clearly described in section 6 and it needs to be
updated.

|- Why a new method instead of a new attribute?

As described in the design considerations section, the ICE usage
requires the message integrity and short-term credentials to be used
with Binding request/response. These are not needed for consent
freshness. One could add a new attribute to call out an ICE exception.
However, depending on where in the stack an implementation does the
integrity verification, an implementation may throw out a Binding
request/response if it doesn't find the MESSAGE-INTEGRITY or USERNAME
attributes. In addition, a Binding request sent for consent freshness
can cause ICE reprocessing if an implementation doesn't handle it
properly.

I am not saying it can't be done using a new attribute. But, using a new
method looks cleaner and less troublesome with existing deployments.

Muthu

|-----Original Message-----
|From: Simon Perreault [mailto:[email-masked]]
|Sent: Monday, March 05, 2012 8:33 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]
|Subject: Re: [BEHAVE] FW: I-D Action:
draft-muthu-behave-consent-freshness-00.txt
|
|On 2012-03-04 16:27, Muthu Arul Mozhi Perumal (mperumal) wrote:
|> This I-D describes a new STUN usage for enabling WebRTC
implementations
|> to perform consent freshness. It is far from complete, but comments
|> (especially on the design considerations/approach) are welcome..
|
|I had a *very* quick look at it, and have a few questions. They're
|mostly "explain it to me like a two year old" type questions, so maybe
|the answers could be added to the doc itself.
|
|- Looking at section "6. STUN Consent Method Processing", I don't see
|any difference between a Binding request and a Consent request on the
|server side. So how could a Consent request have different semantics
|than a Binding request if they are processed identically by the server?
|
|- Why a new method instead of a new attribute? A new attribute
|indicating additional semantics seems more appropriate to me because
all
|Binding processing would automatically be inherited by Consent. E.g. in
|the future we define a new Binding attribute, chances are it would also
|apply to Consent. All you need is a way to indicate "this is a regular
|Binding request but *additionally* I'm asking if you consent to me
|sending you packets". The server would include the consent attribute in
|the response if it consents, otherwise, and if it doesn't support that
|attribute, it would just ignore it and reply like a normal Binding
|request, which would be useful. Also you would inherit a lot of text
|about the mechanics (e.g. sections 6.1-6.4 marked TBD would be
unnecessary).
|
|Simon
|--
|DTN made easy, lean, and smart --> http://postellation.viagenie.ca
|NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
|STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Tue, 06 Mar 2012 13:49:38 -0500

> involved in a real-time communication session.

Right. By "server" I mean the peer that receives the STUN request.

> Binding request processing and process the request as a consent request.

What does "process the request as a consent request" mean? From the 
draft it looks like it could mean exactly the same as for a Binding 
request...

In other words, what's the difference between a consent request and a 
keepalive?

> freshness. One could add a new attribute to call out an ICE exception.

I'm not following you. ICE requires short-term auth for *connectivity 
checks*. Those are done *before* ICE concludes. ICE does not require 
short-term auth for Binding requests sent *after* ICE concludes. For 
keepalives, it even says that auth must not be used.

> can cause ICE reprocessing if an implementation doesn't handle it

That argument can be used to justify anything. I could say that your new 
Consent request could be interpreted as a Crash-Right-Now message if an 
implementation doesn't handle it properly.

Simon

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 7 Mar 2012 00:53:44 +0530

|In other words, what's the difference between a consent request
|and a keepalive?

A keepalive is a Binding indication that does not evoke a response,
whereas a consent request does.

|I'm not following you. ICE requires short-term auth for *connectivity
|checks*. Those are done *before* ICE concludes. ICE does not require
|short-term auth for Binding requests sent *after* ICE concludes. For
|keepalives, it even says that auth must not be used.

<snip from the RFC5245>
   B.4.  Importance of the STUN Username

   ICE requires the usage of message integrity with STUN using its
   short-term credential functionality.  The actual short-term
   credential is formed by exchanging username fragments in the SDP
   offer/answer exchange.

   B.10.  Why Are Binding Indications Used for Keepalives?

   Additionally, using a Binding Indication allows integrity to be
   disabled, allowing for better performance.  This is useful for large-
   scale endpoints, such as PSTN gateways and SBCs.
</snip>

It doesn't look ICE intended to limit the message integrity and
short-term auth for connectivity checks alone -- it looks applicable for
any Binding request/response transaction.

<snip from the RFC5245>
   10.  Keepalives
   Though Binding Indications are used for keepalives,
   an agent MUST be prepared to receive a connectivity check as well.
   If a connectivity check is received, a response is generated as
   discussed in [RFC5389], but there is no impact on ICE processing
   otherwise.
</snip>

If a connectivity check is received for keepalive, it should use the
message integrity and short-term auth, I think.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Simon Perreault
|Sent: Wednesday, March 07, 2012 12:20 AM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]
|Subject: Re: [BEHAVE] FW: I-D
Action:draft-muthu-behave-consent-freshness-00.txt
|
|On 2012-03-06 13:06, Muthu Arul Mozhi Perumal (mperumal) wrote:
|> |- Looking at section "6. STUN Consent Method Processing",
|> |I don't see any difference between a Binding request and
|> |a Consent request on the server side. So how could a Consent
|> |request have different semantics than a Binding request if
|> |they are processed identically by the server?
|>
|> To make sure I understand correctly, by a server you don't mean a
STUN
|> server sitting in the Internet used for resolving the NAT'ed address,
|> right? Such a server isn't expected to receive a consent request.
|> Consent request/response is expected to be used b/w two endpoints
|> involved in a real-time communication session.
|
|Right. By "server" I mean the peer that receives the STUN request.
|
|> From the server side, the main difference b/w the Binding request
|> processing and the Consent request processing is the message
integrity
|> verification. While a Binding request in the ICE usage would require
|> verification of the message integrity using the short-term credential
|> mechanism, the consent request will not. A consent request is also
not
|> expected to contain any other attribute except FINGERPRINT (and
probably
|> SOFTWARE). So, once the server identifies it as a consent request
based
|> on the message type fields in the STUN header, it would branch out of
|> Binding request processing and process the request as a consent
request.
|
|What does "process the request as a consent request" mean? From the
|draft it looks like it could mean exactly the same as for a Binding
|request...
|
|In other words, what's the difference between a consent request and a
|keepalive?
|
|> |- Why a new method instead of a new attribute?
|>
|> As described in the design considerations section, the ICE usage
|> requires the message integrity and short-term credentials to be used
|> with Binding request/response. These are not needed for consent
|> freshness. One could add a new attribute to call out an ICE
exception.
|
|I'm not following you. ICE requires short-term auth for *connectivity
|checks*. Those are done *before* ICE concludes. ICE does not require
|short-term auth for Binding requests sent *after* ICE concludes. For
|keepalives, it even says that auth must not be used.
|
|> However, depending on where in the stack an implementation does the
|> integrity verification, an implementation may throw out a Binding
|> request/response if it doesn't find the MESSAGE-INTEGRITY or USERNAME
|> attributes. In addition, a Binding request sent for consent freshness
|> can cause ICE reprocessing if an implementation doesn't handle it
|> properly.
|
|That argument can be used to justify anything. I could say that your
new
|Consent request could be interpreted as a Crash-Right-Now message if an
|implementation doesn't handle it properly.
|
|Simon
|--
|DTN made easy, lean, and smart --> http://postellation.viagenie.ca
|NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
|STUN/TURN server               --> http://numb.viagenie.ca
|_______________________________________________
|Behave mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/behave

---

From: Simon Perreault <[email-masked]>
Date: Tue, 06 Mar 2012 15:07:42 -0500

> whereas a consent request does.

Aaaaah! I think I'm starting to understand... You want a way to know if 
the peer is still listening to you! And you can't use a simple Binding 
Request because that could be interpreted as a connectivity check, which 
requires short-term auth. And you don't want to use short-term auth 
because it is too computationally intensive.

> any Binding request/response transaction.

This snippet should be explicit enough:

<snip from the RFC5245>
    If STUN is being used for keepalives, a STUN Binding Indication is
    used [RFC5389].  The Indication MUST NOT utilize any authentication
    mechanism.
</snip>

> message integrity and short-term auth, I think.

Ok, so once ICE concludes there are two messages one must be prepared to 
receive:
Binding Indication ==> keepalive ==> MUST NOT use auth
Binding Request ==> connectivity check ==> MUST use short-term auth

Could there be a way to relax the "MUST use short-term auth" 
requirement? The thing is that you need to be sure that your peer's ICE 
has concluded too. Once you know that then both of you are not 
vulnerable to media hijacking anymore, and at that point short-term auth 
would not be necessary anymore. I can't think of an existing way to know 
that right now, but with a new STUN message that could be possible. I'm 
thinking of an exchange going
"I'm done are you done?"
"yes I'm done"
---> short term auth no longer needed

Simon