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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Oleg,

ICE connectivity checks will take care of the attack. Only the parties involved the WebRTC call will be aware of the short-term credential (ice-ufrag, ice-pwd). ICE connectivity checks use the short-term credentials. So though the peer will send STUN Binding Request (ICE check) to the attacker. The attacker will not be able to compute the message-integrity for STUN Binding Response since it will not be aware of the password.

TURN authentication is more important because resources will be allocated on the server. we are discussing in BEHAVE WG the need for stronger authentication mechanism in draft http://tools.ietf.org/html/draft-reddy-behave-turn-auth-03.

-Tiru.
From: [e-mail] [mailto:[e-mail]] On Behalf Of Oleg Moskalenko
Sent: Tuesday, September 24, 2013 8:07 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Melinda Shore; [e-mail]
Subject: Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations

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