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

[Melinda Shore <[e-mail]>]

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.

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