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

[Oleg Moskalenko <[e-mail]>]

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 <[e-mail]>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) <
> [e-mail]> 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:* [e-mail] [mailto:[e-mail]] *On
>> Behalf Of *Oleg Moskalenko
>> *Sent:* Tuesday, September 24, 2013 12:50 PM
>> *To:* Melinda Shore
>> *Cc:* [e-mail]
>> *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 <[e-mail]>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pntaw****
>>
>> ** **
>>
>
>