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

From: Melinda Shore <[email-masked]>
Date: Mon, 23 Sep 2013 21:02:13 -0800

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 23 Sep 2013 23:46:14 -0700

On Mon, Sep 23, 2013 at 10:02 PM, Melinda Shore <[email-masked]>wrote:

> enforcement devices.

this distinction is a sort of academic exercise. I am not sure that
concentrating on that theoretical distinction has much of practical value
in the real world.

> STUN (and, to a lesser extent, TURN),

For a person who does not "like" STUN and TURN you are dedicating too much
efforts to discussing them.

> but prominent among
> answer is unauthenticated.

TURN responses are always authenticated, if any security mechanism is
chosen. The client must check the integrity-field to authenticate the
response. Only the entity who knows the user password can construct a valid
response.

The only unauthenticated response (usually) is STUN "binding" response.
This is just an implementation convention that it is usually
unauthenticated. Nothing in RFC requires it to be unauthenticated. That's
only a common practice to leave it unauthenticated. For secure
environments, we can always enforce authentication of the BINDING response.

> Using TCP as the TURN

In very secure environments, the short-term authentication TURN mechanism
can be used. Each TURN Send and Data indications are authenticated in that
case. Then no application level authentication is necessary.

TURN is really a neat and clever tool, when you do understand how it works.

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 24 Sep 2013 00:20:17 -0700

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 <[email-masked]>wrote:

> _______________________________________________
> pntaw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pntaw
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 24 Sep 2013 09:19:41 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Tuesday, September 24, 2013 12:50 PM
To: Melinda Shore
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

Melinda
_______________________________________________
pntaw mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pntaw

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 24 Sep 2013 07:37:24 -0700

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) <
[email-masked]> 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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Oleg Moskalenko
> *Sent:* Tuesday, September 24, 2013 12:50 PM
> *To:* Melinda Shore
> *Cc:* [email-masked]
> *Subject:* Re: [pntaw] More on
> draft-hutton-rtcweb-nat-firewall-considerations****
>
> ** **
>
> 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:****
>
> ****
> ****
> ****
> ** **
> ** **
> On Mon, Sep 23, 2013 at 10:02 PM, Melinda Shore <[email-masked]>
> wrote:****
>
> https://www.ietf.org/mailman/listinfo/pntaw****
>
> ** **
>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 24 Sep 2013 16:55:35 +0200

> authentication in the STUN/TURN servers, that may be really a concern.

I don't think the problem is server-side. FWIW, our server has supported
STUN auth since day one. I expect adding STUN auth to other server
implementations would be easy.

The problem is practical. Our free STUN service is configured to not
require auth for STUN. And clients almost never do use auth for STUN.
It's the way STUN is being used that is problematic.

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 24 Sep 2013 08:04:38 -0700

> It's the way STUN is being used that is problematic.

this is true, this is the same what I was saying. The existing WebRTC
clients simply are not able to authenticate properly the STUN Binding
request - they are hard-coded to unauthenticated Binding requests.

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 24 Sep 2013 08:06:43 -0700

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 <[email-masked]>wrote:

>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Oleg Moskalenko

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 24 Sep 2013 15:07:52 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Tuesday, September 24, 2013 8:07 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Melinda Shore; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> 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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Oleg Moskalenko
Sent: Tuesday, September 24, 2013 12:50 PM
To: Melinda Shore
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations

Melinda

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 24 Sep 2013 08:08:57 -0700

> implementations would be easy.

Our server also supported it from the day one - but at one moment we had to
make an exception for STUN Binding request because nobody uses it with
authentication. I'll make it an option in our server.

---

From: Dan Wing <[email-masked]>
Date: Tue, 24 Sep 2013 08:38:58 -0700

> answer is unauthenticated.  

* The bogus response has to match STUN's 96-bit transaction ID (which is generated by the client and supposed to be random), or else the bogus response is ignored.
* All WebRTC media traffic is encrypted (SRTP) and all WebRTC non-media traffic ("data traffic") is DTLS-protected (SCTPoDTLSoUDP).

-d

---

From: Melinda Shore <[email-masked]>
Date: Tue, 24 Sep 2013 08:18:53 -0800

On 9/24/13 1:19 AM, Tirumaleswar Reddy (tireddy) wrote:
> 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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 24 Sep 2013 17:11:13 +0000

Hi Melinda,

Please see inline

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Melinda Shore
> Sent: Tuesday, September 24, 2013 9:49 PM
> 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

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.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 24 Sep 2013 09:37:46 -0800

On 9/24/13 9:11 AM, Tirumaleswar Reddy (tireddy) wrote:
> 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.

There's a lot of history here.  pcp was preceded by midcom,
which did the same thing but failed to get any uptake at all
other than briefly appearing in Asterisk.  There were two
reasons for midcom's failure: 1) it used SNMPv3 for transport,
which everybody hated, and 2) it required a forklift network
upgrade.  You wouldn't be able to buy a VoIP system that
used it without also upgrading all your firewalls.

Midcom was standardized in the transport area and it seems
unlikely to me that pcp would have been chartered if they'd
gone back to the transport area, or if the ADs who'd run
the transport area at the time midcom was in business were
still in office.  When pcp was in charter discussions I asked
Jari, who was internet AD at the time, why he thought this
would succeed where midcom had failed and he really didn't
have an answer for that other than his personal optimism.

I worked for Cisco during this and what I heard from product
managers was that they had no interest in undermining the
value in their inspection technology by allowing entities
outside the firewall (including other Cisco devices - this
is one of the prices of corporate Balkanization) to make
decisions about what traffic should be permitted.  Unless
that situation has changed you're likely to encounter the
same resistance.  That said, that said, the popularity of
unilateral hole-punching technologies, that do not consult
the firewall, might be the right argument for something like
midcom or pcp.  But if I were a betting person I would not
bet on firewalls supporting  pcp hitting the market any
time soon (and to be clear, I think that's unfortunate
because I do think that's the better solution to the hole
punching and NAT mapping installation problem, even if it
was already standardized about a decade ago).

In the future there may be a better solution still based
on something like VNF.

But there's a long history here, as I said, and there may or
may not be something to learn from it.

Melinda

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 25 Sep 2013 14:14:11 +0200

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 25 Sep 2013 09:27:11 -0800

> chances that the hole would remain open - you'll be using it.

Authentication doesn't help - there needs to be some trusted
party to the transaction who can vouch for the legitimacy of
the request.  It's a lot easier with VoIP, as you've generally
got some sort of call control server mediating the transaction
and that terminates (and reoriginates) signaling requests,
so they know what's going on.

> *better* be hardened against outsiders anyway, because that hole *is*

That's a broader firewall issue, I think, regardless of
whether or not <whatever> is being used to open firewall
pinholes.  But basically I see two issues here:

1) that an attacker can subvert the technology to
open firewall pinholes, and
2) undermining the ability of the firewall to enforce local
policy by giving users the ability to punch holes in
contravention of that policy

>From an operational standpoint the second is the more serious
issue, I think.  Most of the arguments I've heard against that
being an issue have been ideological in nature.  That's not
necessarily a bad thing and I actually agree that firewalls
are harmful to network architecture, that they're largely
responsible for crunchy-on-the-outside-soft-on-the-inside
mindsets on the parts of network and security admins (and
corporate auditors), etc., but I think in the real world we
need to acknowledge that they're out there and are perceived
has having value by the people who deploy them, and giving
users the ability to scoot around firewall policy is
problematic.

Melinda

---

From: Dan Wing <[email-masked]>
Date: Wed, 25 Sep 2013 11:17:50 -0700

> users the ability to scoot around firewall policy is

"Policy" is a broad word.  Nailing down something more specific would be helpful for the discussion.  

My strawman is:  arbitrary UDP pinholes through the firewall are denied, but WebRTC sessions originated by certain domains (or by all domains?) are permitted to create UDP pinholes through the firewall.  

If that strawman is not quite right, please adjust and build a new straw man.

-d

---

From: Melinda Shore <[email-masked]>
Date: Wed, 25 Sep 2013 12:15:11 -0800

On 9/25/13 10:17 AM, Dan Wing wrote:
> My strawman is:  arbitrary UDP pinholes through the firewall are
> denied, but WebRTC sessions originated by certain domains (or by all
> domains?) are permitted to create UDP pinholes through the firewall.

This is where the IETF really is terribly limited by not having
more participation from people who actually run networks.

The most common case is that all outgoing traffic is permitted
but it's not the only case.  I've seen some networks in which
nearly nothing is allowed that's not proxied, and not just
inside the DOD.  In those environments it's likely that they
wouldn't permit any WebRTC traffic.  But there are networks
access policies in-between maximally strict and maximally lax
and that's the area that needs to be considered, I think.
It seems to me that the primary question is whether or not the
network administrators have the tools to be able to selectively
disallow traffic at their network boundaries.

Melinda

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 25 Sep 2013 14:34:58 -0700

> more participation from people who actually run networks.

Melinda, then you have a moral obligation to help us with the Websockets
draft :)

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 26 Sep 2013 08:18:30 +0000

On 25 September 2013 22:35 Oleg Moskalenko: Wrote:
> 
> Melinda, then you have a moral obligation to help us with the
> Websockets draft :)

Please could I also ask for everybody's help in making sure that in draft-hutton-rtcweb-nat-firewall-considerations 
we have captured all the scenarios that we need to take in to account and listed the different solution options.  

If it turns out that websockets is the right solution to some or all of these scenarios then we will reference that but even if that is the case we need this overview and to make sure we have all the important scenarios are covered.

Andy