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

[Harald Alvestrand <[e-mail]>]

On 09/24/2013 06:18 PM, Melinda Shore wrote:
> On 9/24/13 1: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.
> The primary win, I think, is that  by allowing someone you trust
> to say "Yes, this user is authorized to perform this action" it
> provides some mitigation against the possibility of abuse by
> an attacker wishing to punch holes in your firewall.  OAuth
> is not, strictly speaking, an authentication mechanism, although
> it may look that way to the relying party.  How the user authenticates
> to the IdP is, strictly speaking, out of scope, here.

So Melinda, if I read you right, the attack you're envisioning is not 
against the communication, but something like this:

client -> STUN server: What's my address?
firewall (tells nobody): installs a NAT mapping & pinhole for client 
that allows real traffic from anywhere
Evil STUN server -> client: your address is <something>
Evil STUN server -> Evil attacker: You can now reach <client> at <real 
address>

If this is a port-NAT, the port opened by <client> is now accessible 
from the Internet.
If it's an address NAT, the whole host is - but that's unlikely in the 
firewall case, isn't it?

I'm not sure authentication helps here - once you've sent off a request 
to the evil server, you've opened the hole. It would even be good for 
the evil server to give a correct answer, since that increases the 
chances that the hole would remain open - you'll be using it.

But - all those packets will end up at the WebRTC client. And that had 
*better* be hardened against outsiders anyway, because that hole *is* 
going to be open.

How valuable is this attack vector?

>
> Authentication on its own is probably not sufficient.  Just because
> I can prove who I am doesn't mean that I am permitted to punch
> holes through the firewall, at least not in the general case,
> and while I think you're likely to run into resistance if you
> try to roll your own authorization token I do think that you'll
> need something to be able to authorize hole-punching.
>
> I'll reiterate that I think you need to deal with the firewall
> vs. NAT distinction if you want to get this document through
> IETF review, should it ever progress that far.  STUN and TURN have
> not been used for creating firewall pinholes before, at least not
> in the IETF.
>
> Melinda
>
> _______________________________________________
> pntaw mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pntaw