Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations

"Tirumaleswar Reddy (tireddy)" <> Tue, 24 September 2013 17:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97AF121F9193 for <>; Tue, 24 Sep 2013 10:11:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.825
X-Spam-Status: No, score=-9.825 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JszHVzttiE8T for <>; Tue, 24 Sep 2013 10:11:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 07C4221F9654 for <>; Tue, 24 Sep 2013 10:11:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3213; q=dns/txt; s=iport; t=1380042676; x=1381252276; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nnDUIuU1EH7YWwSAlbJNSWea3sRcv1/qnZU2ndHkEB8=; b=VjY5Ic2z+Tc2oAeJx75eHNscv/zzOFjq7GE1lJldxNuJxwpTP5PYwFWV eUUGf+PuYdzlyjJ4AEmwK7AyXp1WJZQXvDj71eLP+UeQMt7rnnV5Yqc2W j5Qou/C7DRUrhjDZnnA6oL1+kpT2x3BrNuKM6Gik1li9G6MWLhxe8k4ih 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.90,972,1371081600"; d="scan'208";a="263910241"
Received: from ([]) by with ESMTP; 24 Sep 2013 17:11:13 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r8OHBDw6016022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Sep 2013 17:11:13 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 12:11:13 -0500
From: "Tirumaleswar Reddy (tireddy)" <>
To: Melinda Shore <>
Thread-Topic: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations
Thread-Index: AQHOuONCg4GUhi2DtUuPO48aTcUBQ5nUzxSA///HSoCAAM8ygP//uBtw
Date: Tue, 24 Sep 2013 17:11:13 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, Justin Uberti <>
Subject: Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Sep 2013 17:11:21 -0000

Hi Melinda,

Please see inline

> -----Original Message-----
> From: [] On Behalf Of
> Melinda Shore
> Sent: Tuesday, September 24, 2013 9:49 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc:
> Subject: Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations
> On 9/24/13 1:19 AM, Tirumaleswar Reddy (tireddy) wrote:
> > We had discussed in BEHAVE WG to change TURN REST API draft to use
> > OAuth. With OAuth, the WebRTC client will get self-contained token with
> > lifetime, session key etc in the signaling protocol which will be used
> > by the TURN client to compute message integrity for the TURN request.
> > TURN server will use the token to get the session key, validate the TURN
> > request and also compute the message integrity for the TURN response.
> > This solves the problem of not exposing long-term credentials to the
> > java script.
> The primary win, I think, is that  by allowing someone you trust
> to say "Yes, this user is authorized to perform this action" it
> provides some mitigation against the possibility of abuse by
> an attacker wishing to punch holes in your firewall.  

The above OAuth technique for TURN is designed not to solve the problem of punching holes in the firewall. It only solves problems mentioned in 
section 4 of draft and the WebRTC specific problem 6 discussed in the draft 

   6.  In WebRTC the Javascript needs be know the username and password
       to use in W3C RTCPeerConnection API to access the TURN server.
       This exposes the user credentials to the Javascript which could
       be malicious.

> OAuth is not, strictly speaking, an authentication mechanism, although
> it may look that way to the relying party.  How the user authenticates
> to the IdP is, strictly speaking, out of scope, here.
> Authentication on its own is probably not sufficient.  Just because
> I can prove who I am doesn't mean that I am permitted to punch
> holes through the firewall, at least not in the general case,
> and while I think you're likely to run into resistance if you
> try to roll your own authorization token I do think that you'll
> need something to be able to authorize hole-punching.
> I'll reiterate that I think you need to deal with the firewall
> vs. NAT distinction if you want to get this document through
> IETF review, should it ever progress that far.  STUN and TURN have
> not been used for creating firewall pinholes before, at least not
> in the IETF.

Agreed. The firewall problem is solved by the technique proposed in draft This draft describes the mechanism for firewalls to only permit UDP media session associated with specific WebRTC servers. This addresses the firewall problem in Enterprise network without having to do DPI on WebRTC signaling protocol.

> Melinda
> _______________________________________________
> pntaw mailing list