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

Oleg Moskalenko <> Tue, 24 September 2013 15:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E77511E814E for <>; Tue, 24 Sep 2013 08:07:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.414
X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0y286LIfmc6G for <>; Tue, 24 Sep 2013 08:06:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::234]) by (Postfix) with ESMTP id A8C8511E8156 for <>; Tue, 24 Sep 2013 08:06:59 -0700 (PDT)
Received: by with SMTP id kl14so3782829pab.25 for <>; Tue, 24 Sep 2013 08:06:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xu6lIFa5Yn5QwDx8zbTvpWYMypYZaodUWHG5oJ7h/W0=; b=s0+rcVPTlJjZghMRHgNIxbrVdrSWAlndQ6iiodUfwkPinhtRoAnsS7YDAbeOH09tTZ pgV5TzfncBCGHiMQqSBl+qy3WGyjhR9aPHvQqo+2yI15oov6g6xo2MMMRgPt+Qzxx4wF i8U5guzz3V2HciEBNQ4WiZOj45HGGa67afJQT3j0jSEvxJOrtpo+hLMEvH0zAcwQjBKk h97uMnP5CDh+qAklM1crt/ADbmjTcquvHwt2KFLViyIDPLWsW6+tqiptBT6VBc9gIHL1 EmcxS0cWcG4gNnNzhmcsIh2YN//LekM+iNcsHoL9KSmxatQrHVQY/CU72p2fxNEQwzDm xXWA==
MIME-Version: 1.0
X-Received: by with SMTP id ef4mr4907800pbb.27.1380035203593; Tue, 24 Sep 2013 08:06:43 -0700 (PDT)
Received: by with HTTP; Tue, 24 Sep 2013 08:06:43 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 24 Sep 2013 08:06:43 -0700
Message-ID: <>
From: Oleg Moskalenko <>
To: "Tirumaleswar Reddy (tireddy)" <>
Content-Type: multipart/alternative; boundary=047d7b6d85f216820604e7227c83
Cc: Melinda Shore <>, "" <>
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 15:07:01 -0000

Melinda also probably implied a similar problem with TURN and relayed
addresses, but that problem is addressed by the TURN security mechanism, as
in section 17.1.5 of RFC 5766.

On Tue, Sep 24, 2013 at 7:37 AM, Oleg Moskalenko <>wrote;wrote:

> 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) <
>> 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:* [] *On
>> Behalf Of *Oleg Moskalenko
>> *Sent:* Tuesday, September 24, 2013 12:50 PM
>> *To:* Melinda Shore
>> *Cc:*
>> *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 <>
>> 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
>> ** **