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

Hi Melinda,

Please see inline

> -----Original Message-----
> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf Of
> Melinda Shore
> Sent: Tuesday, September 24, 2013 9:49 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: pntaw@ietf.org
> Subject: Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations
> 
> 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.  

The above OAuth technique for TURN is designed not to solve the problem of punching holes in the firewall. It only solves problems mentioned in 
section 4 of draft http://tools.ietf.org/html/draft-reddy-behave-turn-auth-03 and the WebRTC specific problem 6 discussed in the draft 

   6.  In WebRTC the Javascript needs be know the username and password
       to use in W3C RTCPeerConnection API to access the TURN server.
       This exposes the user credentials to the Javascript which could
       be malicious.

> 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.
> 
> 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.

Agreed. The firewall problem is solved by the technique proposed in draft http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-01. This draft describes the mechanism for firewalls to only permit UDP media session associated with specific WebRTC servers. This addresses the firewall problem in Enterprise network without having to do DPI on WebRTC signaling protocol.

-Tiru.

> Melinda
> 
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw