Re: [MMUSIC] RTSP and NATs

[Magnus Westerlund <[e-mail]>]

Thanks Philippe,

The attack you describe is possible unless we have a way of positively 
identify a entity from two ways. First we must be able to establish the 
identity of the host that are located at the given media destination IP 
address/port. Secondly that host must be able to prove that it is that 
entity.

In slightly more detail: When a client asks the server to send media to 
a given destination, the server must be able to get an global unique 
identifier of the destination from a trusted party. Then the server uses 
this global identifier in the security challenge to the destination. The 
destination answers the challenge and proves that it is really the given 
entity.

The first step of getting a global host entity based on IP will never 
work with an NATed address. It seem to be possible to make it work when 
you use an public IP address.

In basic any NAT traversal mechanism will allow for an attack by a man 
in the middle, see:
http://www.ietf.org/internet-drafts/draft-dupont-transient-pseudonat-01.txt

In fact today's RTSP is definitely not safe against man in the middle 
attacks. The man in the middle must only be able to receive the servers 
response to SETUP request to get the session ID: Then it can control the 
server from any place by simply spoof the sender address to that of the 
target. If you use TCP the attacker must be able to receive the TCP 
flows response. That it is all it takes to use RTSP as a DOS tool.

Best Regards

Magnus Westerlund

[e-mail] wrote:

>Magnus you write:
>
>  
>
>>By having the receiver sign the message going from client
>>to server with keys that are transported through other ways we can
>>ensure that no other than the intended receiver can verify that it
>>agrees. This makes it possible to protect also against man in the middle
>>attacks. It will of course requires secure RTSP signaling.
>>    
>>
>
>I dont see how a "secure RTSP session" solves the case I was thinking about is:
>
>your server thinks that the client is behind a NAT,
>because the IP addresses for RTSP and RTP are different,
>but in fact that client is a Bad Guy who wants to induce
>your server to flood someone else.
>
>if Mr Bad Guy is also a man-in-the-middle you are in real trouble because:
>
>1) your attacker is initiating that RTSP session so
>
>A) your server cannot  trust "a different IP address" indicated in that session, even if the session is TLS-ized  !
>
>B) you cannot use that session to convey crypto stuff for a separate UDP challenge either  because:
>
>2) this guys is also a man-in-the-middle who can trap/spoof UDP traffic
>i.e. a challenge/response at that "different IP address".
>
>I dont know how to solve that one (help security experts?)
>
>regards,
>
>Philippe Gentric
>Software Architect
>Philips MP4Net
>"philippe dot gentric at philips dot com"
>http://www.platform4.philips.com
>
>  
>

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic