Subject: [BEHAVE] comments on behave-turn-09

From: Cullen Jennings <[email-masked]>
Date: Sat, 26 Jul 2008 22:03:05 +0100

I strongly encourage folks to resolve with the open issues in the  
section 19 title "Open Issues" and section 21 titled "Open Issues".   
We need this draft done sooner rather than later. If we resolve all  
these at this meeting, I still suspect we will be discussing TURN in  
December. If we don't resolve them, I would guess longer.

In the IANA section, do you need to register the SRV lookup name for  
turn / turns?

In IANA section, I think the statement "Extensions to TURN can be made  
through IETF Consensus" should be removed. The procedures to update  
the registry are already defined in other specifications and this just  
confuses the issue.

In the section 19 open issues, point 4. Could you clarify for me if  
this is an open issue or just one you disagree with with the WG. I was  
under the impression we had a consensus call on this.

The rest of my issues have to do with security where I got the idea  
from previous emails that the authors did not want to talk about yet  
as they know the security section needs an update but I will send  
comments anyways. Feel free to ignore if you are not yet at the point  
of talking about security. Actually nothing new here, I've said this  
all before.

My primary concern is about lack of server authenticating of requests  
from the client that create permissions and lack of client  
authenticating messages from the server. Keep in mind that TURN  
effectively pokes a small part of the internal protected space behind  
the firewall out to the TURN server.

Here's an attack that illustrate why I am concerned about this:

The attack is where the attacker, again outside the firewall sends a  
request that creates a permission to the firewall and spoofs the  
address/transport of the client (again guessing the port). The  
attacker uses this to create a permission that allows the attacker to  
send to the client. Once again, the attacker outside the firewall can  
send packets to the client without the client creating a permission to  
that peer.

I do not see how any enterprise that believes it needs to run a  
firewall could be OK allowing use of TURN unless we  protect against  
these attacks. You can argue firewalls are useless, but if an  
enterprise believes they are not useless, then this breaks part of  
what the enterprise expects to get from the firewall.

This could be solved by having a MUST level requirement for the client  
to authenticate packets came from the TURN server and for the TURN  
server to authenticate any packet that creates or refreshes a  
permission.

My secondary concern is if servers can pick arbitrary long times for  
permissions, this creates a serious problem as NATs and firewalls  
reuse the port in a shorter time. The attack is the firewall or NAT  
gives the PORT to a different client before the TURN server has  
expired the permission. The idea that we need a to support lifetimes  
up to 2^32 seconds seems wrong.

I love the statement about implementors keeping up with best practices  
around bot net attacks. What would the current best practices be at  
this point in time?

Cullen, in my individual contributor roll
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Mon, 28 Jul 2008 09:39:54 -0400

> December. If we don't resolve them, I would guess longer.

Whoops! Ignore section 21. In my last minute editing frenzy, I forgot  
section 21 existed and added section 19. All the issues still open are  
listed in section 19.

But I agree with Cullen's statement.

> In the IANA section, do you need to register the SRV lookup name for  

I think so. Will add.

>
>
> In IANA section, I think the statement "Extensions to TURN can be  
> made through IETF Consensus" should be removed. The procedures to  
> update the registry are already defined in other specifications and  
> this just confuses the issue.

OK.

> this is an open issue or just one you disagree with with the WG. I  
> was under the impression we had a consensus call on this.

See my e-mail of yesterday on this.

> comments anyways. Feel free to ignore if you are not yet at the  
> point of talking about security. Actually nothing new here, I've  
> said this all before.
>
> My primary concern is about lack of server authenticating of  
> requests from the client that create permissions and lack of client  
> effectively pokes a small part of the internal protected space  
> behind the firewall out to the TURN server.
>
> attacker uses this to create a permission that allows the attacker  
> to send to the client. Once again, the attacker outside the firewall  
> can send packets to the client without the client creating a  
> permission to that peer.

Let me make sure I understand your attack. We have:
- TURN client behind the firewall
- attacker outside the firewall
- TURN server outside the firewall.

Step 1: Client creates an allocation on the server.
Step 2: Attacker, though some means, learns or guesses the details of  
the allocation.
Step 3: Attacker sends a Send request to the server control port with  
a PEER-ADDRESS attribute that specifies itself. This causes the server  
to create a permission towards the attacker.
Step 4: Attacker sends data to the relayed-transport-address of the  
allocation, which is then forwarded by the server to the client.

Do I understand correctly?

> This could be solved by having a MUST level requirement for the  
> client to authenticate packets came from the TURN server and for the  
> TURN server to authenticate any packet that creates or refreshes a  
> permission.

Yes. I think this would solve the problem. This is open issue #5 in  
the TURN document.

In an e-mail on March 24, I discussed a number of ways to do this.  
Right now, I am leaning towards the following fix:
a) Add Send request and response messages (in addition to Send  
indications). Like all requests, Send requests can be authenticated.  
Like Send indications, Send requests may or may not contain a DATA  
attribute.
b) Send indications and ChannelData msgs no longer install/refresh  
permissions.

> up to 2^32 seconds seems wrong.

Currently, installing or refreshing a permission sets its lifetime to  
5 minutes.

It's the allocation lifetime which the client can change (using the  
LIFETIME attribute in an Allocate or Refresh request). Right now, the  
document RECOMMENDS that the maximum allocation lifetime be 1 hour,  
though I have been privately wondering if it should not just be fixed  
at some smaller value.

Do you see any problems with a permission lifetime of 5 minutes, or  
long allocation lifetimes?

>
>
> I love the statement about implementors keeping up with best  
> practices around bot net attacks. What would the current best  
> practices be at this point in time?

You should ask Mr Mahy about that, since I believe he wrote that  
sentence.

However, as you mentioned above, I am planning to update/rewrite the  
security section. Suggested text is welcome.

> Cullen, in my individual contributor roll

- Philip