1. Slide title In CAPITALS 50 pt Slide subtitle 32 pt RTSP 2.0 TLS handling Magnus Westerlund draft-ietf-mmusic-rfc2326bis-12

2. Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level 2-5 20 pt IETF 65 - TLS WGRTSP2006-03-202 Real-Time Streaming Protocol  Signalling protocol for controlling streaming sessions, i.e. the network remote control.  Media normally goes in its own transport session over UDP. Exception is the interleaved mode, which is last resort fall back solution.  Has a ”rtsps” URI scheme to indicate the requirement to use TLS protected signalling.  Normal TLS usage is defined in section 18.2  Uses the guidelines from RFC 2818

3. Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level 2-5 20 pt IETF 65 - TLS WGRTSP2006-03-203 RTSP and Proxies  Some environement requires proxies: –Firewalls need to open pinholes for the media –Logging or content filtering of some media content  Many of these cases can accept a trust model where the proxy is trusted. This due to the close association with it, like your companies.  Defined a mechanism for handling multiple TLS hops by either: 1.have the proxy relay the next hop server certificate to the client and have it approve the certificate. 2.let the proxy determine which certificates to accept 3.accept any certificate (Debugging only)

4. Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level 2-5 20 pt IETF 65 - TLS WGRTSP2006-03-204 TLS connect walkthrough 1.Client connects with TLS and send Request to proxy. 2.Proxy Connects with TLS to server and get server side certificate. 3. Proxy responds to request with 470 ( Connection Authorization Required), and include certificate. 4.Client checks certificate, and accepts it by including a hash of the certificate and proxy URI in the Accept-Credentials header and resend the request. 5.Proxy matches hash with connection and forwards request in TLS. Server Proxy Client 1. 2. 3.4. 5.

5. Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level 2-5 20 pt IETF 65 - TLS WGRTSP2006-03-205 Open Issue in Accept-Credentials  The Accept-Credentials header is sent as part of the request when needed.  Each entry within the Accept-Credentials headers has an intended proxy.  Should that proxy remove the entry intened for itself before forwarding the request?  Doing the above procedure rather then having them go end to end would: –Reduce bandwidth in requests –Slightly increase processing load –Hide earlier TLS hops from later RTSP agents –The Via header shows route, however it allows for a proxy to hide topology  Any security implications?

6. Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level 2-5 20 pt IETF 65 - TLS WGRTSP2006-03-206 Request for Review  Document is getting close to WG last call in MMUSIC WG  Want to have review on the security mechanisms before that to avoid to late suprises  Please review section 18 and send comments to authors and MMUSIC WG.