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

Oleg Moskalenko <mom040267@gmail.com> Tue, 24 September 2013 14:37 UTC

Return-Path: <mom040267@gmail.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 8316711E8122 for <pntaw@ietfa.amsl.com>; Tue, 24 Sep 2013 07:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.41
X-Spam-Level:
X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 fll6IJRH4KSe for <pntaw@ietfa.amsl.com>; Tue, 24 Sep 2013 07:37:25 -0700 (PDT)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 656F911E80F3 for <pntaw@ietf.org>; Tue, 24 Sep 2013 07:37:25 -0700 (PDT)
Received: by mail-pa0-f50.google.com with SMTP id fb1so3777419pad.37 for <pntaw@ietf.org>; Tue, 24 Sep 2013 07:37:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=30QyeZ6DkETpmGFGMKh+jfJjs8qPXSamiYw8RSK37dc=; b=sSWHgLPTJga/aBLVxyW6wpsxXk033PjrFYxuPURO1mR/M/3zQmY1CivkMxGxGa3ogI CPtB9H99Ck3V9KNTJ/CaYH2VKJ+s+CTRndMJLzSfq3sPU/SVPocXU/NaXJ9Km2gMfYhG sGJ9MyXHVLYM8sVjc1c+3TfJ69YL4alefoBpE3Tn0hYlm/ROtI8bCQZIYXE/T0RL9EXc 24tJEx4rfjQcrxPzECicutQDC0IzDLtrx75mxHbVV0ciYTI73TPtRfaVVwqX/ZfbFgXd pgVdzfF7+//ulrfcdGTSrlLFxqY9IdF34DKD8A3Jyiea02b7Pe5KV3QhpHcfQbWigkAT XiHg==
MIME-Version: 1.0
X-Received: by 10.68.172.3 with SMTP id ay3mr27643160pbc.5.1380033444953; Tue, 24 Sep 2013 07:37:24 -0700 (PDT)
Received: by 10.68.91.163 with HTTP; Tue, 24 Sep 2013 07:37:24 -0700 (PDT)
In-Reply-To: <913383AAA69FF945B8F946018B75898A1907DC09@xmb-rcd-x10.cisco.com>
References: <52411CD5.1050909@gmail.com> <CALDtMr+O8__AUk9qXm9yz4ePNtV_n=V31oHNQ_a068viV_uZYg@mail.gmail.com> <913383AAA69FF945B8F946018B75898A1907DC09@xmb-rcd-x10.cisco.com>
Date: Tue, 24 Sep 2013 07:37:24 -0700
Message-ID: <CALDtMrKOdWSRxM4c_XW7rv6_hTcsa_Zp2A+83zoK3+fHYR0rrA@mail.gmail.com>
From: Oleg Moskalenko <mom040267@gmail.com>
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Content-Type: multipart/alternative; boundary=047d7b10cfc543c47e04e7221308
Cc: Melinda Shore <melinda.shore@gmail.com>, "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 14:37:26 -0000

Hi Tiru,

Melinda was talking about a different area of concern. She was considering
an attack when a malicious party sends a fake STUN Binding response to the
client. Then, the client will have wrong value of its own reflexive IP
address and the client will use that wrong address in, say, SDP. Then the
peer will be sending the media stream to the attacker's IP address.

As STUN Binding request/response dialog is usually implemented without
authentication in the STUN/TURN servers, that may be really a concern.

Oleg



On Tue, Sep 24, 2013 at 2:19 AM, Tirumaleswar Reddy (tireddy) <
tireddy@cisco.com> 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.****
>
> ** **
>
> -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>
> 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
> https://www.ietf.org/mailman/listinfo/pntaw****
>
> ** **
>