Menu

#226 DTLS or other keymanangent for SRTP in RTSP

open
General (104)
5
2010-09-27
2010-09-27
No

Roni Even skrev 2010-06-07 11:19:
> > Section C.1.4 and C.1.5 recommend using MIKEY for key exchange. I think
> > that since we now have DTLS-SRTP in RFC 5764 we should look at
> > recommending this option.

Magnus Westerlund reponded:
This questions doesn't seem to have been answered nor commented by anyone.

I think you actually have found an issue here. First of all that without
a mandated to implement keying mechanism this is actually
underspecified. The second a discussion on what keying mechanism to use.

To resolve this I will suggest that we change RECOMMEND to MUST in
section C.14 and C.1.5 on using MIKEY with these protocol identifiers.
That way we do get a fully specified security mechanism. The only thing
I need to consider is if MIKEY and SRTP has at least one mandatory to
implement mode each so that no further about which sets of mechanism
must be supported.

I would agree that DTLS-SRTP is a good idea for transport layer security
if needed for RTP media streams in RTSP. However, this needs
specification work and some considerations. I would also like to point
out that this do require a bit of special muxing which should be
expressed in the protocol string, just like in the SDP case also in
RTSP. Thus I think using another profile, lower transport combination
than for SRTP directly on UDP is warranted for DTLS-SRTP. As this
require job, I think anyone interested in this should define this
separately so that we can finish the core RTSP 2.0 spec.

I don't know if the interest is so big for transport level protection,
although I think we shall provide a solution. The reason is that at
least content protection is usually in place. Thus the need is primarily
for integrity and authentication between server and client.

Discussion

MongoDB Logo MongoDB