Slide titleIn CAPITALS

50 pt

Slide subtitle 32 pt

RTSP 2.0 TLS handling

Magnus Westerlund

draft-ietf-mmusic-rfc2326bis-12

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-520 pt

IETF 65 - TLS WG RTSP 2006-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

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-520 pt

IETF 65 - TLS WG RTSP 2006-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 accept3. accept any certificate (Debugging only)

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-520 pt

IETF 65 - TLS WG RTSP 2006-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.

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-520 pt

IETF 65 - TLS WG RTSP 2006-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?

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-520 pt

IETF 65 - TLS WG RTSP 2006-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.