Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations
"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Tue, 24 September 2013 09:19 UTC
Return-Path: <tireddy@cisco.com>
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 A51B521F9E45 for <pntaw@ietfa.amsl.com>; Tue, 24 Sep 2013 02:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.618
X-Spam-Level:
X-Spam-Status: No, score=-9.618 tagged_above=-999 required=5 tests=[AWL=0.824, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
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 Ny+nfsQB4hXj for <pntaw@ietfa.amsl.com>; Tue, 24 Sep 2013 02:19:48 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE8621E8056 for <pntaw@ietf.org>; Tue, 24 Sep 2013 02:19:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16141; q=dns/txt; s=iport; t=1380014388; x=1381223988; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nnAQJzxvMvcPkbxAt/LyN4+kYskUmIQ8Ea0Dj43IjEw=; b=WNglTprtyaUXMLCj35lF+uBrI0Hll7jZHwI8vs7ER6UkLm50y3TF5IHW 3UVap54c6Rau6PzVFIv+YPIcHXYeasg9Dw6Mz//rKWY+5fVAG54Pr1prK HTXCEDGnJmR82JyLumE3VPGc5K2HBpUtqXnxQw2APmf8Lwy9qpLBW6KLF M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAB1YQVKtJV2Y/2dsb2JhbABagkNEOFLAUIEhFnSCJQEBAQQBAQEqQQsQAgEIDgMBAwEBCx0HIQYLFAMGCAIEAQ0FCIdrAw8MszANiWYEjGaBIoEYLQQGAQaDF4EAA5YTji2FM4MkgWoHFwYc
X-IronPort-AV: E=Sophos; i="4.90,969,1371081600"; d="scan'208,217"; a="263721926"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 24 Sep 2013 09:19:42 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8O9Jg9q031418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Sep 2013 09:19:42 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 04:19:42 -0500
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Oleg Moskalenko <mom040267@gmail.com>, Melinda Shore <melinda.shore@gmail.com>
Thread-Topic: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations
Thread-Index: AQHOuONCg4GUhi2DtUuPO48aTcUBQ5nUzxSA///HSoA=
Date: Tue, 24 Sep 2013 09:19:41 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A1907DC09@xmb-rcd-x10.cisco.com>
References: <52411CD5.1050909@gmail.com> <CALDtMr+O8__AUk9qXm9yz4ePNtV_n=V31oHNQ_a068viV_uZYg@mail.gmail.com>
In-Reply-To: <CALDtMr+O8__AUk9qXm9yz4ePNtV_n=V31oHNQ_a068viV_uZYg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.61.30]
Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A1907DC09xmbrcdx10ciscoc_"
MIME-Version: 1.0
Cc: "pntaw@ietf.org" <pntaw@ietf.org>
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: Tue, 24 Sep 2013 09:19:53 -0000
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. -Tiru. From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Tuesday, September 24, 2013 12:50 PM To: Melinda Shore Cc: pntaw@ietf.org Subject: Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations Melinda raised some valid TURN security concerns. I'd suggest to add two optional recommendations for the secure TURN environments: 1) Enforce authentication of STUN Binding request/response; 2) Short-term authentication mechanism. The problems with those recommendations are: 1) The existing STUN, TURN, WebRTC and ICE implementations do not support authenticated STUN Binding request/responses; this is an implementation problem, this is not a standard problem. I personally can say that adding an option of authenticated STUN request/response to our TURN server (rfc5766-turn-server) is an easy 1-hour work, but this is rather a convention problem. My experience is that once this option is enabled, the WebRTC stops working - it is not expecting a challenge response from the STUN server. It can be considered as a bug of the existing WebRTC libraries. 2) As of now, WebRTC does not support short-term authentication mechanism. 3) The new TURN REST API standard (under development) is revolving around the long-term authentication mechanism. On Mon, Sep 23, 2013 at 10:02 PM, Melinda Shore <melinda.shore@gmail.com<mailto:melinda.shore@gmail.com>> wrote: I think you really need to be clearer about the distinction between NAT and firewall, and that firewalls are policy enforcement devices. NATs arguably are (address policy) but to the extent they're deployed as access control mechanisms that function is incidental to their design. This matters a lot when you're talking about ICE, since it was designed as a *NAT* traversal mechanism, not a firewall traversal mechanism. There's been a long history of highly contentious middlebox work in the IETF and it's probably better to address those questions sooner rather than later, as I think they're bound to come up. So, you're extending ICE to firewall traversal, because ... ? In particular I'd put some text in section 1 addressing the difference between NATs and firewalls, the policy enforcement role of firewalls, that it is explicitly not the intention of this draft to propose a mechanism for violating local firewall policy, and that you recognize a need to give the network administrator control over what does and does not enter their network. That said, if they do wish to allow WebRTC traffic, this is how to do it. I think that will help fend off irritating questions from people like, say, me. I think there's probably a lot more that can be said about addressing and policy, particularly around authenticity, but I'm going to save that for after having re-read the WebRTC documents. But I'd like to skip ahead to the security considerations section, because that's really critically important and can't be left empty (to be honest I'm considering proposing to my own working group and others that we not adopt any working group draft that has an empty security considerations section - it's a big problem). I think there are two broad classes of security issues here: 1) the security of the mechanism itself, and 2) security in the context of the environment In this case the two are not cleanly separable, to the extent that presumably the reason for subverting the security of a WebRTC traversal mechanism would be to compromise the firewall (with one prominent exception, which I'll get to below). As I mentioned in previous email, you cannot allow the WebRTC firewall traversal technology to be subverted to allow "unauthorized" pinholing. This is kind of a messy problem, since it can involve port numbers (which doesn't apply in the creation of real-time media streams), stateful traffic inspection (which doesn't work in the presence of encrypted signaling traffic), and so on. It *may* be the case that there's an authoritative, trusted entity somewhere in the application architecture that can make authoritative statements about what's allowed, and you could leverage a third-party mechanism like OAuth if you can live with the added latency. I can give you a long, long list of reasons I don't like STUN (and, to a lesser extent, TURN), but prominent among them is that without some sort of application-layer authentication it is trivially easy to use it to hijack media streams. All you have to do is send a bogus STUN or TURN response with an address of your choosing, since the answer is unauthenticated. Using TCP as the TURN transport makes an attack more challenging but it doesn't eliminate it entirely. In VoIP scenarios, what they typically do is accept the response but then authenticate the application traffic, so if they get a bogus response the media streams can't be established, anyway. So, either think about how to protect against an insertion attack, or make it clear that you've got protection available at the application layer. Melinda _______________________________________________ pntaw mailing list pntaw@ietf.org<mailto:pntaw@ietf.org> https://www.ietf.org/mailman/listinfo/pntaw
- [pntaw] More on draft-hutton-rtcweb-nat-firewall-… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Tirumaleswar Reddy (tireddy)
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Simon Perreault
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Tirumaleswar Reddy (tireddy)
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Dan Wing
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Tirumaleswar Reddy (tireddy)
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Harald Alvestrand
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Dan Wing
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Hutton, Andrew