Subject: Re: [MMUSIC] SAVP and SAVP in draft-ietf-mmusic-rfc2326bis-23

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Sep 2010 16:55:08 +0200

Roni Even skrev 2010-06-07 11:19:
> Hi,
> 
> 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.

Hi Roni,

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.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 29 Sep 2010 16:31:32 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Magnus Westerlund
> Sent: Monday, September 27, 2010 7:55 AM
> To: Roni Even
> Cc: 'mmusic'
> Subject: Re: [MMUSIC] SAVP and SAVP in draft-ietf-mmusic-rfc2326bis-23
> 
> That way we do get a fully specified security mechanism.

I am concerned about making MIKEY a MUST.

First, which of the MIKEYs are you suggesting?  MIKEY-RSA, -PSK, 
-RSA-R, -DHHMAC, or another?  If MIKEY-PSK (which is RFC3830's 
mandatory-to-implement mechanism), what mechanism is used for 
the RTSP client to get that pre-shared key or would that remain 
unspecified?  Depending on how the pre-shared key is obtained,
MIKEY-PSK may not be sufficient to protect against attackers 
that obtain the pre-shared key (for example, how often and 
how is the key changed in an RTSP session?).

Even if those were resolved, I would still object because a MUST 
requires still implementing MIKEY-(whichever) even if DTLS-SRTP is 
implemented in the future.  Some wording such as "In the absence 
of another mechanism, MIKEY-(whichever) MUST be implemented" at 
least avoids that problem, and would be a reasonable escape clause.

> The only thing

RFC3830 (MIKEY) mandatory-to-implement is MIKEY-PSK.  RFC3711 (SRTP) is
AES-CM with HMAC-SHA1.

> separately so that we can finish the core RTSP 2.0 spec.

I concur with that paragraph.  FYI, there is some progress on getting
DTLS-SRTP to work well in environments that are interesting to RTSP
(e.g., multicast) via draft-ietf-avt-srtp-ekt which allows different
hosts to terminate DTLS-SRTP and send SRTP (Section 4.1.1).

> least content protection is usually in place.

Agreed.

> Thus the need is
> primarily for integrity and authentication between server and client.

With that in mind, should there be a recommendation to only provide
SRTP integrity and authentication (that is, without encryption)?

-d

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic