Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution
draft-ietf-avt-srtp-not-mandatory-16

[Ballot comment]

Thanks for working this through over >1 generation
of security AD.

Do you really need this bit:

For a framework protocol, it appears that the only
sensible solution to the strong security requirement
of [RFC3365] is to develop and use building blocks
for the basic security services of confidentiality,
integrity protection, authorisation, authentication,
and so on.  When new uses for the framework protocol
arise, they need to be studied to determine if the
existing security building blocks can satisfy the
requirements, or if new building blocks need to be
developed.  A mandatory to implement set of security
building blocks can then be specified for that usage
scenario of the framework.

I'm concerned that composition like that could
result in insecurity. I think I'd prefer you to
delete this and the following para.

[Ballot comment]
I know this has been a long time in the making.  I have to admit I've never loved the idea of no MTI but we seem to do it for other protocols like HTTP, Oauth, eMail, and the list goes on.  My assumptions here are 1) there won't be whole lotta these profiles coming our way, and 2) implementers actually want to have *secure* interoperable solutions.

The Security Considerations really is:

This entire memo is about mandatory to implement security or the lack thereof for RTP.

[Ballot discuss]
This document does a good job to list the different "RTP Applications and Deployment Scenarios" in section 2.
Then, when it gets interesting, the content is somewhere else.

  The range of available RTP security options, and their applicability
  to different scenarios, is outlined in
  [I-D.ietf-avtcore-rtp-security-options].

Same answer in the section 4 "RTP Session Establishment and Key Management"

  The most important and widely used keying options for RTP sessions at
  the time of this writing are described in
  [I-D.ietf-avtcore-rtp-security-options].

Therefore, I don't understand how the document content maps the second part of the abstract? (this point is my DISCUSS)

  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.

I see "guidelines" in the section 6 title, but, as designer or reviewer, I'm not sure what the guidelines are. It seems the answer is always: "it depends, see draft-ietf-avtcore-rtp-security-options as a starting point. "

I wonder why draft-ietf-avtcore-rtp-security-options-09 is not integrated in this document?

[Ballot comment]
I am not quite comfortable with the discussion of interoperability. I do
buy the argument of the document, but I don't see how, when I buy or
implement RTP for one of the deployment or application scenarios listed
in section 2, I end up with the right strong security. I believe the way
to handle this is to describe for each of the cases in Section 2 what
security is expected in any implementation. In that way, there is
something to do a cross-check against, and interoperability is more
likely.

I'll leave this as a Comment and hope that the authors pick up on it and
work through it with someone who has more clue than I do about the needs
of interop and MTI security.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-avt-srtp-not-mandatory-14, which is
currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution) to Informational RFC


The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document:
- 'Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single
  Media Security Solution'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/ballot/


No IPR declarations have been submitted directly on this I-D.

[Ballot discuss]
Updated based on -10 and discussions Stephen and I had followed by additional discussions Stephen had with the authors.  Much of this comes down to our definition of profile and the srtp definition of profile being different.  Stephen suggested the following text that we're hoping will do the trick:


BCP61 generally requires that IETF protocols specify mandatory
to implement (MTI) strong security and this clearly applies to
specifications of applications that make use of RTP. RTP itself
however specifies a framework rather than a specific application,
and given the variability described in this document, and the
set of currently available mechanisms [ref] no one set of MTI
security options can realistically be specified for all RTP
applications.

Existing RTP profiles [ref,ref] and payload formats [ref,ref]
do not specify such an interoperable usage and are therefore
neither secure in themselves, nor something to which BCP66
applies. Future similar documents need to explicitly state
this.

Current work on real time web [ref] and SIP [ref] does
however need to meet BCP61 and therefore such documents need
to specify MTI security. This is because such specifications
do fully specify interoperable applications that use RTP.

[Ballot discuss]


This review is of version -10 of the draft.
This is definitely on the right track.

1. section 2 says that there's too much variation to pick a
single MTI security or key mgmt scheme but I'm not
convinced that all the variations would preclude that if
taken individually, for example bandwidth is no big deal
here, nor is realiability, in fact the only thing that
really seems relevant for MTI security/key mgmt is
multicast vs. point-to-point.  if I'm right about the above
then could we say that for RTP stacks that will mostly be
used for point-to-point applications, then SRTP SHOULD be
implemented so as to be usable for point-to-point
applications?

2. Section 5, 1st para: Can you give a non-security example
of what might cause non-interop for some use-cases? I mean
where the two implementations couldn't work together for
any configuration. (Which is what you're implying to
justify that they security implementations can be
non-interoperable.)

3. Last sentence of section 5 seems broken. Not sure I get
what its saying either.

4. Section 6 - why can't you say that RTP profiles SHOULD
specify MTI security? Surely if its possible then it ought
be done, and if not then it cannot, which adds up to
SHOULD.

5. Can you give an example of an RTP profile for which it
does not make sense to specify MTI security? I think at
least an existence proof is needed here.

[Ballot discuss]
Taking this over from Tim and agreeing with him.

This is a joint discuss from both Security ADs.  Given the importance of
this
document, we are both holding a discuss position so we can participate in
the
discussion that follows.

We accept the basic premise of this document: as a “framework protocol”,
applying
BCP 61 directly and mandating a single security solution is not
appropriate and
would not achieve the goal of BCP 61: ensuring that security
mechanisms are
implemented (and thus available) even if it is not turned on in
every deployment.
However, we do not believe the proposed solution (leaving the
selection to each
application of RTP) is any more likely to achieve that goal.
In most actual deployments,
RTP is basically not secured.  Allowing a thousand
flowers to bloom practically
guarantees that real deployments will not include
security mechanisms (since there
is so little prospect of code re-use and many
current deployments won’t turn it on.)

To meet the spirit of BCP 61, we recommend that the working group consider the
following approach: specify a small set of solutions that cover the major
classes of
applications, and mandate implementation of the appropriate solution
for each RTP
application.  RTP application standards would be required to
justify a mandatory to
implement security scheme that does not fall within this
set.  We believe this solution
provides the best opportunity to achieve the
goals of BCP 61 for RTP-based applications.

[Ballot discuss]
Note: This is a joint discuss from both Security ADs.  Given the importance of this
document, we are both holding a discuss position so we can participate in the
discussion that follows.

We accept the basic premise of this document: as a “framework protocol”, applying
BCP 61 directly and mandating a single security solution is not appropriate and
would not achieve the goal of BCP 61: ensuring that security mechanisms are
implemented (and thus available) even if it is not turned on in every deployment.
However, we do not believe the proposed solution (leaving the selection to each
application of RTP) is any more likely to achieve that goal.  In most actual deployments,
RTP is basically not secured.  Allowing a thousand flowers to bloom practically
guarantees that real deployments will not include security mechanisms (since there
is so little prospect of code re-use and many current deployments won’t turn it on.)

To meet the spirit of BCP 61, we recommend that the working group consider the
following approach: specify a small set of solutions that cover the major classes of
applications, and mandate implementation of the appropriate solution for each RTP
application.  RTP application standards would be required to justify a mandatory to
implement security scheme that does not fall within this set.  We believe this solution
provides the best opportunity to achieve the goals of BCP 61 for RTP-based applications.

[Ballot discuss]
Note: This is a joint discuss from both Security ADs.  Given the importance of this
document, we are both holding a discuss position so we can participate in the
discussion that follows.

We accept the basic premise of this document: as a “framework protocol”, applying
BCP 61 directly and mandating a single security solution is not appropriate and
would not achieve the goal of BCP 61: ensuring that security mechanisms are
implemented (and thus available) even if it is not turned on in every deployment.
However, we do not believe the proposed solution (leaving the selection to each
application of RTP) is any more likely to achieve that goal.  In most actual deployments,
RTP is basically not secured.  Allowing a thousand flowers to bloom practically
guarantees that real deployments will not include security mechanisms (since there
is so little prospect of code re-use and many current deployments won’t turn it on.)

To meet the spirit of BCP 61, we recommend that the working group consider the
following approach: specify a small set of solutions that cover the major classes of
applications, and mandate implementation of the appropriate solution for each RTP
application.  RTP application standards would be required to justify a mandatory to
implement security scheme that does not fall within this set.  We believe this solution
provides the best opportunity to achieve the goals of BCP 61 for RTP-based applications.

[Ballot comment]
This is a very much needed document, well written, and makes IMO the
right conclusions.

I did have two issues, however, but decided to place a Yes vote as
opposed to holding a discuss. I do want to talk about these topics
on the IESG telechat, however.

The first issue is that in Section 4 MIKEY is ruled out as mechanism for supporting situations where the SIP infrastructure is untrusted. I do not understand why this is being done. MIKEY can provide end-to-end authentication, which would seem to thwart attacks where SDES would
clearly fail. Can this exclusion be elaborated and/or removed?

The second issue relates to the main recommendations. The documents
makes the argument that RTP applications are so diverse that they can
not live under the same security solution. However, I am left wondering
whether there would be mandatory-to-implement security solutions for
specific applications. Do the authors for some reason believe that is
not feasible or undesirable? Should there be IETF activities started
on making such requirements for specific applications?

[Ballot discuss]
This draft seems to say that BCP 61 does not apply to RTP.  BCP 61
  describes the "Danvers Doctrine", which says that the IETF should
  standardize on the use of the best security available, regardless of
  national policies.  BCP 61 also says:

  > One of the continuing arguments we hear against building security
  > into protocols is the argument that a given protocol is intended only
  > for use in "protected" environments where security will not be an
  > issue.
  >
  > However it is very hard to predict how a protocol will be used in the
  > future.  What may be intended only for a restricted environment may
  > well wind up being deployed in the global Internet.  We cannot wait
  > until that point to "fix" security problems.  By the time we realize
  > this deployment, it is too late.
  >
  > The solution is that we MUST implement strong security in all
  > protocols to provide for the all too frequent day when the protocol
  > comes into widespread use in the global Internet.

  I find it inappropriate for an Informational document to a BCP.  If
  there is consensus that RTP is a special case, then the exception to
  BCP 61 ought to be documented in a BCP.
 
  I do not believe that there is such a consensus as it would contradict
  the results of the RTPSEC BOF held at IETF 68.  The RTP security
  requirements were eventually published as RFC 5479, and then RFC 5763
  and RFC 5764 (DTLS-SRTP) published a solution to those requirements.

  I recognize that DTLS-SRTP is not the solution for all environments.
  However, today most RTP in deployments use no security.  BCP 61 argues
  for security to be implemented even if it is not turn on in every
  deployment.  A secuity solution for unicast point-to-point audio is
  unlikely to work well for multicast IPTV.  This does not argue for no
  security.  Rather it argues for a collection of security solutions
  that accomodate the various environments that RTP supports.

[Ballot discuss]
This draft seems to say that BCP 61 does not apply to RTP.  BCP 61
  describes the "Danvers Doctrine", which says that the IETF should
  standardize on the use of the best security available, regardless of
  national policies.  BCP 61 also says:

  > One of the continuing arguments we hear against building security
  > into protocols is the argument that a given protocol is intended only
  > for use in "protected" environments where security will not be an
  > issue.
  >
  > However it is very hard to predict how a protocol will be used in the
  > future.  What may be intended only for a restricted environment may
  > well wind up being deployed in the global Internet.  We cannot wait
  > until that point to "fix" security problems.  By the time we realize
  > this deployment, it is too late.
  >
  > The solution is that we MUST implement strong security in all
  > protocols to provide for the all too frequent day when the protocol
  > comes into widespread use in the global Internet.

  I find it inappropriate for an Informational document to a BCP.  If
  there is consensus that RTP is a special case, then the exception to
  BCP 61 ought to be documented in a BCP.
 
  I do not believe that there is such a consensus as it would contradict
  the results of the RTPSEC BOF held at IETF 68.  The RTP security
  requirements were eventually published as RFC 5479, and then RFC 5763
  and RFC 5764 (DTLS-SRTP) published a solution to those requirements.

  I recognize that DTLS-SRTP is not the solution for all environments.
  However, today most RTP in deployments use no security.  BCP 61 argues
  for security to be implemented even if it is not turn on in every
  deployment.  A secuity solution for unicast point-to-point audio is
  unlikely to work well for multicast IPTV.  This does not argue for no
  security.  Rather it argues for a collection of security solutions
  that accomodate the various environments that RTP supports.

[Ballot comment]
1. In Section 1: s/Section 2 describes the scenarios in which RTP is deployed./Section 2 describes the most widely encountered scenarios in which RTP is deployed./

2. in Section 2 - why are the conferencing scenarios listing only video conferencing and not voice and video conferencing?

[Ballot discuss]
This document does a good job in building the case that SRTP is not universally fit as a security solution for all use cases of RTP. I have however a couple of issues with two sections in the document that I would like to be discussed before I can approve the document:

1. The last application scenario listed in Section 3 says:

>  Finally, the link layer may be secure, and it may be known that the
  RTP media data is constrained to that single link (for example, when
  operating in a studio environment, with physical link security).  An
  environment like this is inherently constrained, but might avoid the
  need for application, transport, or network layer media security.

I do not believe that this is relevant in a discussion about securing an IETF protocol. BCP 61 (RFC 3365) Section 6 is very clear in that:

>  One of the continuing arguments we hear against building security
  into protocols is the argument that a given protocol is intended only
  for use in "protected" environments where security will not be an
  issue.
...
  The solution is that we MUST implement strong security in all
  protocols to provide for the all too frequent day when the protocol
  comes into widespread use in the global Internet.

I suggest to take out this case as irrelevant

2. I am confused about what section 5 tries to say. First I do not know the term 'framework protocol' - this needs to be defined or referred to. What the section seems to say is that for that category of protocols (where RTP belongs) the strong security is more an application issue, where an application may be built of several building blocks, out of which the protocol is only one of them. This seems again to question or even justify an extemption from the requirements of BCP 61 [RFC3365] for RTP or even a whole class of protocols.

[Ballot comment]
Section 3., paragraph 4:
>    [ETSI.TS.102.474], where one mode of operation uses ISMAcryp
>    (http://www.isma.tv/specs/ISMA_E&Aspec2.0.pdf) to encrypt the RTP
>    payload data only.

  Nit: It'd be better to refer to this URL as a reference.


Section 4., paragraph 9:
>    authentication solutions that are tied into the key manangement.

  Nit: s/manangement./management./

This draft was put together by key AVT experts to help the IESG understand why
SRTP is not always required for secure transport of media. It was
written in response to repeated queries of Security Considerations sections in
AVT documents by members of the IESG. The PROTO writeup follows.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Tom Taylor  is PROTO Shepherd. I have reviewed this
version of the document and believe it is ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document was written by key WG members. The document had good discussion by
a number of other key members at IETF 71, prior to its acceptance as a Working
Group document. Since then it drew comments on the list once in 2008, and once
during WGLC in 2009. Nevertheless, the Document Shepherd feels that it has had
adequate review.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns. No IPR disclosures.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

I would say the WG as a whole understands and agrees with it.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

IDnits indicates some outdated references, which can be fixed at an appropriate
time.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

All references are informative.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

IANA section exists, but has no actions.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Not applicable.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
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.

Working Group Summary
This document had good discussion at IETF 71 and received solid
support to become a Working Group document. It was written by two
former Chairs of the AVT Working Group, and the need for it was
recognized by the Area Director of the time.

Document Quality
Thanks to Dan York and Ali Begen for their review comments.