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

Harald Alvestrand <harald@alvestrand.no> Wed, 25 September 2013 12:14 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5BD21F9FBF for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 05:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.371
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G2aAKGAMbdF for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 05:14:15 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3992B21F9FAB for <pntaw@ietf.org>; Wed, 25 Sep 2013 05:14:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9839B39E1BB for <pntaw@ietf.org>; Wed, 25 Sep 2013 14:14:12 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2W6FcKBe-52 for <pntaw@ietf.org>; Wed, 25 Sep 2013 14:14:10 +0200 (CEST)
Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E4AB939E0BF for <pntaw@ietf.org>; Wed, 25 Sep 2013 14:14:10 +0200 (CEST)
Message-ID: <5242D393.4070500@alvestrand.no>
Date: Wed, 25 Sep 2013 14:14:11 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: pntaw@ietf.org
References: <52411CD5.1050909@gmail.com> <CALDtMr+O8__AUk9qXm9yz4ePNtV_n=V31oHNQ_a068viV_uZYg@mail.gmail.com> <913383AAA69FF945B8F946018B75898A1907DC09@xmb-rcd-x10.cisco.com> <5241BB6D.2000104@gmail.com>
In-Reply-To: <5241BB6D.2000104@gmail.com>
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-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=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 
address>

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
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw