Subject: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-11.txt

From: [email-masked]
Date: Mon, 19 Nov 2012 14:51:37 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.

	Title           : Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution
	Author(s)       : Colin Perkins
                          Magnus Westerlund
	Filename        : draft-ietf-avt-srtp-not-mandatory-11.txt
	Pages           : 10
	Date            : 2012-11-19

Abstract:
   This memo discusses the problem of securing real-time multimedia
   sessions, and explains why the Real-time Transport Protocol (RTP),
   and the associated RTP control protocol (RTCP), do not mandate a
   single media security mechanism.  Guidelines for designers and
   reviewers of future RTP extensions are provided, to ensure that
   appropriate security mechanisms are mandated, and that any such
   mechanisms are specified in a manner that conforms with the RTP
   architecture.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-avt-srtp-not-mandatory-11

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 19 Nov 2012 22:59:13 +0000

This version of the draft updates the recommendations in Section 6 based on discussion with the Security Area Directors. There are no changes in the rest of the draft.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 25 Nov 2012 00:46:13 +0100

> This version of the draft updates the recommendations in Section 6 based on discussion with the Security Area Directors. There are no changes in the rest of the draft.

Mostly looks OK to me.

One thing I did not understand about the new section 6 ....
It describes RTP/AVPF as a profile that is an example of where a single 
security mechanism is not reasonable to mandate, because it's used in 
many other contexts.
I think that's OK - but isn't it true that RTP/AVPF *disallows* the use 
of SRTP, since it would then be RTP/SAVPF?

This can be confusing to the reader - it may be clearer if one mentions 
explicitly that the RTP/AVPF, which is a set of building blocks that 
don't need a security mandate, is used to build RTP/SAVPF, which *is* a 
security mandate.

Or am I the one confused?

                 Harald

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Nov 2012 09:08:02 +0100

Hi Harald,

> Or am I the one confused?

I guess you are getting tripped up on this sentence:

   In other cases, though,
   an RTP profile is applicable to such a wide range of applications
   that it would not make sense for that profile to mandate particular
   security building blocks be used (the RTP/AVPF profile [RFC4585] is
   an example of this type of RTP profile, since it provides building
   blocks that can be used in different styles of application).

This is an example why RTP profiles, independent of which profile it may
be is not the appropriate level of putting in the mandatory to implement
security solution alternative. And frankly SAVPF and SAVP is only half a
security mandate, they lack key-management and without a mandatory to
implement key-management solution they do not specify a MTI security
solution.

And if I count correctly in draft-ietf-avtcore-rtp-security-options
there are at least 11 options for keying SRTP.

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: Harald Alvestrand <[email-masked]>
Date: Mon, 26 Nov 2012 09:49:24 +0100

> implement key-management solution they do not specify a MTI security
Yes, my opinion of the usefulness of the RTP "profile" field is 
sometimes acerbic.
SAVP(F) mandates use of SRTP, but that gets you only some of the way.
> there are at least 11 options for keying SRTP.
Sigh.

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Mon, 26 Nov 2012 16:18:31 +0000

>> there are at least 11 options for keying SRTP.

Eleven keying method sounds right; that would be DTLS-SRTP, SDP Security
Descriptions, EKT, plus the eight different MIKEY methods.  Too many
options, but not all of them are standards track.

David

>_______________________________________________
>Audio/Video Transport Core Maintenance
>[email-masked]
>https://www.ietf.org/mailman/listinfo/avt

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2012 19:22:46 +0200

> options, but not all of them are standards track.

Given that everyone was (and still is) allowed to publish their favorite VoIP media key exchange protocol it is a surprise that we only have so few.
Some of the mechanisms have been published in the IETF only because of a too restrictive registration policy established by the MIKEY RFC.

On the other hand, if you look at the deployment then the situation is a bit different..