[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] RTSP and NATs
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
philippe.gentric@philips.com 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 +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic