RTSP 2.0 TLS handling

RTSP 2.0 TLS handling
Magnus Westerlund
draft-ietf-mmusic-rfc2326bis-12
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
IETF 65 - TLS WG
RTSP
2
2006-03-20
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)
IETF 65 - TLS WG
RTSP
3
2006-03-20
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.
IETF 65 - TLS WG
RTSP
4
Server
2.
5.
Proxy
1. 3.
4.
Client
2006-03-20
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?
IETF 65 - TLS WG
RTSP
5
2006-03-20
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.
IETF 65 - TLS WG
RTSP
6
2006-03-20