Subject: [BEHAVE] comments on ietf-behave-turn07

From: Cullen Jennings <[email-masked]>
Date: Mon, 3 Mar 2008 01:01:18 -0800

It is looking much better.

We should talk about if things that update permissions need to have  
integrity or authentication. I'm worried about an attacker being able  
to refresh them.

I have a feeling section 11 has plenty of work left. Would be nice to  
add to the draft (appendix perhaps) our current notes about what  
fields user land programs can read and write on various OS just so we  
have it in one place - could be removed before publishing)

Section 11.2

I'm not sure I like the idea I am about to say but .... one  
possibility would be to add a attribute  that could only be used in a  
Send that told the relay to set the DF bit between the relay and peer.  
This would allow things to do PMTU discover on the relay to peer path.

Section 11.4 - This is, ah, broken if it ignores the PMTU between  
relay and peer. I do agree that do application level probing and  
ignore ICMP based approaches.

We still need that bandwidth text.

On the topic of public servers: Not sure what you mean by public. If  
you mean free, then I will point out that google provides me with a  
nice email service but it still has a credential. If you are worried  
about P2P, I'm sure we could get a nice way to use existing  
credentials or get the the overlay to pass a short term credential  
like we do in ICE.

Let me tell you about last time I said "there seems to be little  
chance of a forwarding loop" :-) Murphy make sure these sort of  
statements never end well.

Trivial Stuff:

Section 8, for the make 300 second default permission, I would make it  
clear this was default for when using UDP between relay and peer and  
other protocols may be different.

Be nice to say that permissions where not refreshed  in the  section  
where relay sends a DATA and section where relay gets data from peer  
and send it to client.

I'm already convinced that padding TCP data to 4 bytes will introduce  
plenty of bugs - convince me that it offers a performance gain.  (I  
don't really care about this and willing to ignore it)

The stuff about servers that could only read DSCP some of the time  
really intrigued me - can you tell me more?

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

---

From: Philip Matthews <[email-masked]>
Date: Mon, 3 Mar 2008 15:08:10 -0500

Cullen:

Thanks for your comments. A few quick replies inline.
I'll go through them more carefully when I get back to the document.

- Philip

> integrity or authentication. I'm worried about an attacker being able

If we require authentication on all requests (see below), then the  
only way an attacker could update a permission is to send data to  
some peer (and fake the source address of the packet). Is this a  
problem? A NAT has this same problem...

> ignore ICMP based approaches.

New text for section 11 coming soon ...

> credentials or get the the overlay to pass a short term credential

Yes. I am now thinking that the right solution is to always require  
authentication, even for public servers.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 22 Mar 2008 10:48:49 -0700

> problem? A NAT has this same problem...

Not sure if this is a problem or not but the situation is fairly  
different than a NAT. With a NAT, only an attacker behind the NAT can  
do this. With a TURN server, an attacker anywhere can do it.

---

From: Philip Matthews <[email-masked]>
Date: Mon, 24 Mar 2008 12:15:55 -0400

> do this. With a TURN server, an attacker anywhere can do it.

Folks:

Cullen also raised this issue in the BEHAVE session, but we never got  
the chance to discuss it. So I would like to discuss it here.

The question is: Is it a problem that indications and ChannelData  
messages in TURN are not authenticated?

For others reading this, I should point out that indications in TURN  
are not authenticated because TURN uses the long-term credential  
mechanism from STUN, and that mechanism is a challenge-response  
mechanism. Since indications cannot be challenged, there is no  
straight-forward way to authenticate them. ChannelData msgs are  
worse: not only is there no mechanism, but there is also no obvious  
way to carry authentication information.

What are the consequences of not authenticating indications and  
ChannelData messages? I see two:
1) An attacker can inject fake data packets to the server or the client.
2) At attacker can refresh permissions and channels.

When I look at these problems, I always compare them with the  
situation where the client and peer are communicating directly  
(without using the TURN server). Attack (1) seems virtually identical  
to the source-address spoofing problem, and can be solved in the same  
way: namely, by using message-integrity and/or encryption of data  
packets at the application layer. This seems to me to be the right  
way for applications to solve this problem.

Attack (2) is a bit different, and I could imagine a case where a  
rogue peer has somehow tricked the client into talking with it  
initially, and then uses attack (2) to keep a permission and/or  
channel alive while it DOSes the client.

I will note, however, that even without using attack (2), the rogue  
peer can DOS the client for 5 minutes (= the lifetime of a permission).

So I see the following options that we could take:

Option A: Ignore this problem for now. Solve it in the future if it  
turns out to be a problem.

Option B: Provide some way to authenticate indications or ChannelData  
messages. For example, for indications, we might require that  
indications use the username, realm, nonce, and password of the last  
successfully authenticated request. For ChannelData messages, how to  
fix this is not so obvious, and seems to almost go against the reason  
for having this message format in the first place.

Option C: Don't allow data traffic to refresh permissions and channel  
bindings. Instead, require that the client use channel rebindings to  
refresh channels, and introduce some new request type for refreshing  
permissions.

Option D: Require any client that is worried about this problem to  
use TLS for transport between the client and the server.

Option E: Like option D, but also define how to use DTLS for  
transport between the client and the server.

Personally, I am currently leaning towards option A and/or Option D.

Comments?

- Philip

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Mar 2008 12:29:22 -0400

I vote option A': ignore the problem but document in the draft why it is ok to ignore it. (for which I like your reasoning, that it's no worse than without a TURN server)
-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Philip Matthews
> Sent: Monday, March 24, 2008 12:16 PM
> To: Behave WG
> Subject: [BEHAVE] TURN: Are unauthenticated indications and ChannelData
> msgs a problem?
>

---

From: Philip Matthews <[email-masked]>
Date: Mon, 24 Mar 2008 12:46:34 -0400

Just a few comments.

First of all, attack (2) is a real attack, though it is quite  
possible that it is not very important.

Second, if we removed Send indications (as your other e-mail  
suggested), then option C becomes somewhat more attractive, since  
there is already an authenticate-able request/response transaction to  
refresh channels.

- Philip

On Mon, 24-Mar-08, at 12:29 , Hadriel Kaplan wrote:
>
> I vote option A': ignore the problem but document in the draft why  
> it is ok to ignore it. (for which I like your reasoning, that it's  
> no worse than without a TURN server)
> -hadriel
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Mar 2008 13:09:48 -0400

> From: Philip Matthews [mailto:[email-masked]]
>

Can you explain how (2) is not already a potential problem with NAT traversal in general?  I.e., if I open a NAT pinhole by sending out data from inside my NAT, why this case (2) cannot happen?

> there is already an authenticate-able request/response transaction to

Option C sucks, imo.  More STUN requests = more exception traffic for a server to handle.  This thing will simply not scale.  Besides, if we make the TURN server look at source IP+port and channel-id's, then the number space one would have to guess to inject such messages is reasonably large (~64 bits?), and if it's a MitM, the game's up with digest authentication too for all intents and purposes.  This is what TLS was built to handle.

-hadriel

---

From: Philip Matthews <[email-masked]>
Date: Mon, 24 Mar 2008 13:26:57 -0400

On Mon, 24-Mar-08, at 13:09 , Hadriel Kaplan wrote:
> Can you explain how (2) is not already a potential problem with NAT  
> traversal in general?  I.e., if I open a NAT pinhole by sending out  
> data from inside my NAT, why this case (2) cannot happen?

As Cullen pointed out, the attacker has to be on the private side of  
the NAT to refresh the permission. With a TURN server, if the TURN  
server is in the public internet, then the attacker can be anywhere  
(as long as it can do source address spoofing).

- Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 25 Mar 2008 11:00:01 +0200

> messages in TURN are not authenticated?

No. It's the same issue as with the NAT anyone behind the same NAT.

A "secure" TURN (or SOCKS) server ought to have its server-to-client side 
protected from the wild open Internet. If the purpose is to control access to 
the outer Internet.

Otherwise, if TURN is a work-around for some brain-dead NAT on your way, this 
does not create much holes than you would have if you were connected to the 
Internet in the first place.

IMHO, this should simply be documented in the Security considerations.

-- 
Rémi Denis-Courmont

---

From: "Benny Prijono" <[email-masked]>
Date: Tue, 25 Mar 2008 11:58:46 +0000

>  2) At attacker can refresh permissions and channels.

What about:
 3) Attacker can create new permission to arbitrary peer to send rogue
data to client
 4) Attacker can DOS the server by tricking it into creating so many permissions

If he can fake source IP address/port, then he just sends a Send
Indication with arbitrary peer address to create a new permission, no?

Cheers
 Benny

---

From: Philip Matthews <[email-masked]>
Date: Tue, 25 Mar 2008 10:26:04 -0400

> Indication with arbitrary peer address to create a new permission, no?

Good point! These are indeed attacks that I had not previously  
considered.

I think these are lightly more serious than my attack (2), but I  
still don't see why someone would bother with these attacks.

- Philip