Subject: RE: [MMUSIC] Secure RTSP thoughts

From: [email-masked]
Date: Fri, 25 Apr 2003 11:29:54 +0300

Hi,

 > -----Original Message-----
 > From: ext Mark Baugher [mailto:[email-masked]]
 > Sent: 25 April, 2003 06:00
 > To: Thomas Zeng
 > Cc: [email-masked]
 > Subject: RE: [MMUSIC] Secure RTSP thoughts
 > 
 > 
 > Thomas,
 > 
 > At 06:28 PM 4/24/2003 -0700, Thomas Zeng wrote:
 > >Mark:
 > >
 > >So far concerns seem to be limited to ALGs/proxies.
 > >
 > >Having said that, in the case of HTTP, there is the 
 > informative RFC2818
 > >"HTTP Over TLS" which describes how to use HTTP over TLS. See:
 > >
 > >I wonder whether similar RFC  on "RTSP over TLS" is needed?
 > 
 > Perhaps an informational or BCP document would be useful or even 
 > necessary.  But I expect that it would recommend that we 
 > don't use TLS/SSL 
 > to proxies (or whenever the endpoint of the SSL connection 
 > isn't coincident 
 > with the endpoint of the RTSP connection).  Seems to me that 
 > the proxy 
 > security problem is a different barrel of monkeys.

I think you're right. For HTTP, RFC 2818 solves a separate problem from RFC 2817, which actually describes how TLS can be tunneled through proxies and how a TCP connection can be upgraded to TLS.

Cheers,
Aki

 > 
 > Mark
 > 
 > 
 > >- thomas
 > >
 > >
 > >-----Original Message-----
 > >From: Mark Baugher [mailto:[email-masked]]
 > >Sent: Thursday, April 24, 2003 3:21 PM
 > >To: Magnus Westerlund
 > >Cc: [email-masked]
 > >Subject: Re: [MMUSIC] Secure RTSP thoughts
 > >
 > >
 > >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.
 > > >
 > > >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
 > > >>>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.
 > > >>>
 > > >>
 > > >>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.
 > > >>
 > > >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]
 > > >
 > > >
 > > >
 > > >_______________________________________________
 > > >mmusic mailing list
 > > >[email-masked]
 > > >https://www1.ietf.org/mailman/listinfo/mmusic
 > >
 > >
 > >_______________________________________________
 > >mmusic mailing list
 > >[email-masked]
 > >https://www1.ietf.org/mailman/listinfo/mmusic
 > >_______________________________________________
 > >mmusic mailing list
 > >[email-masked]
 > >https://www1.ietf.org/mailman/listinfo/mmusic
 > 
 > 
 > _______________________________________________
 > mmusic mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/mmusic
 > 
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic