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

Harald Alvestrand <> Wed, 25 September 2013 12:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B5BD21F9FBF for <>; Wed, 25 Sep 2013 05:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.371
X-Spam-Status: No, score=-110.371 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0G2aAKGAMbdF for <>; Wed, 25 Sep 2013 05:14:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3992B21F9FAB for <>; Wed, 25 Sep 2013 05:14:15 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9839B39E1BB for <>; Wed, 25 Sep 2013 14:14:12 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O2W6FcKBe-52 for <>; Wed, 25 Sep 2013 14:14:10 +0200 (CEST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id E4AB939E0BF for <>; Wed, 25 Sep 2013 14:14:10 +0200 (CEST)
Message-ID: <>
Date: Wed, 25 Sep 2013 14:14:11 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Wed, 25 Sep 2013 12:14:20 -0000

On 09/24/2013 06:18 PM, Melinda Shore wrote:
> 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.  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.

So Melinda, if I read you right, the attack you're envisioning is not 
against the communication, but something like this:

client -> STUN server: What's my address?
firewall (tells nobody): installs a NAT mapping & pinhole for client 
that allows real traffic from anywhere
Evil STUN server -> client: your address is <something>
Evil STUN server -> Evil attacker: You can now reach <client> at <real 

If this is a port-NAT, the port opened by <client> is now accessible 
from the Internet.
If it's an address NAT, the whole host is - but that's unlikely in the 
firewall case, isn't it?

I'm not sure authentication helps here - once you've sent off a request 
to the evil server, you've opened the hole. It would even be good for 
the evil server to give a correct answer, since that increases the 
chances that the hole would remain open - you'll be using it.

But - all those packets will end up at the WebRTC client. And that had 
*better* be hardened against outsiders anyway, because that hole *is* 
going to be open.

How valuable is this attack vector?

> 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.
> Melinda
> _______________________________________________
> pntaw mailing list