Subject: [MMUSIC] Secure RTSP thoughts

From: Tom Marshall <[email-masked]>
Date: Tue, 22 Apr 2003 20:52:49 -0700

Secure RTSP has been the topic of several conversations recently, both in
the telecons and internally at work.  I got to thinking about the problem
and came up with a possible framework.  It's by no means complete, it's just
a start.

I briefly read the SIP spec recently.  SIP has the capability to encrypt
portions of the messages.  What if we applied that capability to RTSP?  We
might be able to come up with a backward compatible, firewall friendly,
encryption capable protocol.  Most of the things that one would want
encrypted are in the headers or entity already: the WWW-Authenticate header
and the DESCRIBE response entity.  Here's an example:

  DESCRIBE rtsp://media.example.org/video.mpeg RTSP/1.0
  CSeq: 1
  Content-Type: application/encrypted
  Content-Length: 27

  WWW-Authenticate: foo:bar

The WWW-Authenticate header would be sent encrypted.  The response might be
like this:

  RTSP/1.0 200 OK
  CSeq: 1
  Date: Wed, 23 Apr 2003 04:36:22 GMT
  Content-Type: application/encrypted
  Content-Length: 1344

  Content-Base: rtsp://media.example.org/video.mpeg/
  Content-Type: application/sdp
  Content-Length: 1234

  v=0
  ...

Here the last three headers and the SDP are encrypted.  Note that there is
no use in encrypting the Content-Base when the request-uri is sent in the
clear.  The request-uri could be sent as "*" and a new header in the
encrypted section could carry the actual request-uri.  We could call this
header something tricky like Request-URI.

Some headers obviously should never be encrypted.  Examples include CSeq,
Transport, and Via.  A list of such headers would need to be made and
included in the spec.

Proxies might need special treatment.  If one would want to encrypt some
data to the proxy and other data to the server, a double encryption might be
useful.

And finally, we would need to come up with a tag for this feature in the new
spec.

Thoughts?

-- 
Windows 2000: Designed for the Internet. The Internet: Designed for UNIX.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Apr 2003 00:37:26 -0400

You are basically talking about using S/MIME.

S/MIME is useful in SIP because of its peer-to-peer nature. But, it 
comes at a high cost - the requirement to have a PKI. Especially for 
encryption, where you need the key of the recipient.

If RTSP is focusing now on the client/server model exclusively (per our 
nat debate), I would think that TLS is a better match. Doing the 
equivalent of sips - rtsps - would be much more deployable, since it 
would not require some additional key distribution mechanism.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Tom Marshall <[email-masked]>
Date: Tue, 22 Apr 2003 21:57:39 -0700

> encryption, where you need the key of the recipient.

There must be some way to make it work reasonably well.  I am not an
encryption expert, but I can start reading up on it.

> would not require some additional key distribution mechanism.

We may focus on client/server but RTSP does have peer-to-peer uses.

Doesn't TLS encrypt all of the data?  I think that is quite undesirable. 
You lose the ability to use ALGs and existing RTSP proxies.

-- 
The problem with most conspiracy theories is that they seem to believe that
for a group of people to behave in a way detrimental to the common good
requires intent.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 23 Apr 2003 09:48:50 +0200

Hi Tom,

It seems evident that we must start discussing what we want to 
accomplish with securing the RTSP messages.

Some requirements on what I see as necessary for transport secured RTSP:

+ Message authentication to prevent tampering. In my opinion we must 
authenticate the whole message to provide any benefit. This will create 
problems with ALGs and Proxies. The Transport header is a vital header 
for RTSP functionality and it is desired to have it secured, and at the 
same time it is the header that an proxy or ALG needs to both read and 
possibly change.

+ Message privacy, I don't know what parts we actually need to have 
encrypted. There is several issues here, user privacy, preventing 
disclosure of information that an attacker could use.

What should the security architecture be? Do we need two levels, one 
between each entity, i.e. between client and proxy and then proxy to 
server. Then a second level that is protected end to end, i.e. client 
<-> server.

I think we should get a security advisor for this. One knowledgeable 
about these issues would be very good.

Colin and Joerg: Who is our security advisor?

>>If RTSP is focusing now on the client/server model exclusively (per
>>    
>>
>our 
>  
>
As pointed out above, I think we need to think about what we would like 
to accomplish. We need to review what security we need and what is 
possible to fit into this. I think we will have to face some hard 
decisions before the end of this work. Would a proxy really be able to 
handle such a message you propose. One bug I see is that the proxy needs 
at least the host part of the request URI to be able to send the request 
to the correct entity. And if you need trusted proxies, I think one 
actually needs consider that these proxies must be updated and security 
audited.

I get the feeling that using TLS is rather simple but requires a limited 
usage model or trusted proxies. And as proxies can't really be trusted, 
what do we do?

Best Regards

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 23 Apr 2003 09:54:26 -0400

>Colin and Joerg: Who is our security advisor?

Eric Rescorla.

Colin

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 23 Apr 2003 13:54:05 -0700

At 12:48 AM 4/23/03, Magnus Westerlund wrote:
>server. Then a second level that is protected end to end, i.e. client <-> 
>server.

One possible approach would be for us to *first* specify an end-to-end 
security solution - e.g., using TLS ("rtsps://").  Although this would not 
work with ALGs and proxies, it would be relatively easy to do (building on 
existing work), and be very useful.

In the longer term, we could also look at the more complex problem of 
defining an alternative, multi-layered solution that would work with 
ALGs/proxies.

>encrypted.

One clear requirement is to encrypt the SDP description that gets returned 
in response to a "DESCRIBE", because that will contain decryption keys (if 
SRTP is to be used for media transport).

I think that a TLS-based solution - even though it would work only 
end-to-end - would be a good starting point, and it would help make 
RTSP/SRTP streaming a reality fairly quickly.

>I think we should get a security advisor for this. One knowledgeable about 
>these issues would be very good.

Yes - definitely!

         Ross.

---

From: Mark Baugher <[email-masked]>
Date: Thu, 24 Apr 2003 15:20:45 -0700

Magnus
   This reminds me of a topic that you raised at the last meeting: We need 
to define RTSP-over-SSL/TLS.  I don't understand what needs to be defined 
outside of ALGs/proxies, which break the end-to-end security model and are 
a special problem for other protocols - notably SIP.

   Are your concerns limited to ALGs/proxies?

Mark
At 09:48 AM 4/23/2003 +0200, Magnus Westerlund wrote:
>Hi Tom,
>
>It seems evident that we must start discussing what we want to accomplish 
>with securing the RTSP messages.
>
>problems with ALGs and Proxies. The Transport header is a vital header for 
>RTSP functionality and it is desired to have it secured, and at the same 
>time it is the header that an proxy or ALG needs to both read and possibly 
>change.
>
>As pointed out above, I think we need to think about what we would like to 
>accomplish. We need to review what security we need and what is possible 
>to fit into this. I think we will have to face some hard decisions before 
>the end of this work. Would a proxy really be able to handle such a 
>message you propose. One bug I see is that the proxy needs at least the 
>host part of the request URI to be able to send the request to the correct 
>entity. And if you need trusted proxies, I think one actually needs 
>consider that these proxies must be updated and security audited.
>