[payload] Security consideration template text for RTP payload formats

[Magnus Westerlund <[e-mail]>]

Secdir and Sec ADs,

I have just updated the draft on Howto write RTP payload formats:
https://datatracker.ietf.org/wg/payload/

I would like to request review from both some Secdir persons and at
least one of the ADs regarding the security aspects of this document.
The reasons are that this document contains both recommendations on what
to think about when writing Security Consideration sections and template
text. As this is a document that has existed a long time we have
determined that the template text will be commonly used by authors of
RTP payload formats.

Thus I want to ensure that we have at least now have agreement on this
text, especially in light of the discussion around
https://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/
and that we don't want secdir reviewers raising issues with this
template text when you see it in the last call reviews in future years.

The relevant security sections from the Howto draft are the following:

7.2.  Security Considerations

   All Internet drafts require a Security Considerations section.  The
   security considerations section in an RTP payload format needs to
   concentrate on the security properties this particular format has.
   Some payload formats have very few specific issues or properties and
   can fully fall back on the security considerations for RTP in general
   and those of the profile being used.  Because those documents are
   always applicable, a reference to these is normally placed first in
   the security considerations section.  There is suggested text in the
   template below.

   The security issues of confidentiality, integrity protection and
   source authentication are common issue for all payload formats.
   These should be solved by mechanisms external to the payload and do
   not need any special consideration in the payload format except for
   an reminder on these issues.  Reasons for this division is further
   documented in "Securing the RTP Protocol Framework: Why RTP Does Not
   Mandate a Single Media Security Solution"
   [I-D.ietf-avt-srtp-not-mandatory].  For a survey of available
   mechanisms to meet these goals, please review "Options for Securing
   RTP Sessions" [I-D.ietf-avtcore-rtp-security-options].  Suitable
   stock text to inform people about this is included in the template.

   Potential security issues with an RTP payload format and the media
   encoding that needs to be considered are:

   1.  That the decoding of the payload format or its media shows
       substantial non-uniformity, either in output or in complexity to
       perform the decoding operation.  For example a generic non-
       destructive compression algorithm may provide an output of almost
       an infinite size for a very limited input, thus consuming memory
       or storage space out of proportion with what the receiving
       application expected.  Such inputs can cause some sort of
       disruption, i.e.  a denial of service attack on the receiver side
       by preventing that host from producing any goodput.  Certain
       decoding operations may also vary in the amount of processing
       needed to perform those operations depending on the input.  This
       may also be a security risk if it is possible to raise processing
       load significantly above nominal simply by designing a malicious
       input sequence.  If such potential attacks exist, this must be
       made clear in the security considerations section to make
       implementers aware of the need to take precautions against such
       behavior.

   2.  The inclusion of active content in the media format or its
       transport.  "Active content" means scripts etc.  that allow an
       attacker to perform potentially arbitrary operations on the
       receiver.  Most active contents has limited possibility to access
       the system or perform operations outside a protected sandbox.
       RFC 4855 [RFC4855] has a requirement that it be noted in the
       media types registration if the payload format contains active
       content or not.  If the payload format has active content it is
       strongly recommended that references to any security model
       applicable for such content are provided.  A boilerplate text for
       "no active content" is included in the template.  This must be
       changed if the format actually carries active content.

   3.  Some media formats allow for the carrying of "user data", or
       types of data which are not known at the time of the
       specification of the payload format.  Such data may be a security
       risk and should be mentioned.

   4.  Audio or Speech codecs supporting variable bit-rate based on
       audio/speech input or having discontinuous transmission support
       must consider the issues discussed in Guidelines for the Use of
       Variable Bit Rate Audio with Secure RTP [RFC6562].

   Suitable stock text for the security considerations section is
   provided in the template in the appendix.  However, authors do need
   to actively consider any security issues from the start.  Failure to
   address these issues may block approval and publication.


---- Next Section ----

A.13.  Security Considerations

   [See Section 7.2]

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [RFC3550] , and in any applicable RTP profile such as
   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
   SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
   Why RTP Does Not Mandate a Single Media Security Solution"
   [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
   formats responsibility to discuss or mandate what solutions are used
   to meet the basic security goals like confiedenitality, integrity and
   source authenticity for RTP in general.  This responsibility lays on
   anyone using RTP in an application.  They can find guidance on
   available security mechanisms and important considerations in Options
   for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
   The rest of the this security consideration discusses the security
   impacting properties of the payload format itself.

   This RTP payload format and its media decoder do not exhibit any
   significant non-uniformity in the receiver-side computational
   complexity for packet processing, and thus are unlikely to pose a
   denial-of-service threat due to the receipt of pathological data.
   Nor does the RTP payload format contain any active content.

   [The previous paragraph may need editing due to the format breaking
   either of the statements.  Fill in here any further potential
   security threats created by the payload format itself.]


Thanks


Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------