Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updates security considerations #30

Merged
merged 3 commits into from Mar 30, 2017
Merged
Changes from 2 commits
Commits
File filter...
Filter file types
Jump to…
Jump to file or symbol
Failed to load files and symbols.
+63 −21
Diff settings

Always

Just for now

@@ -49,7 +49,7 @@
</address>
</author>

<date year="2016" />
<date year="2017" />
<area>Transport</area>
<workgroup>MMUSIC Working Group</workgroup>
<keyword>RTP</keyword>
@@ -1737,27 +1737,67 @@ SDP Answer
</section>
</section>

<section title="Security Considerations" anchor="sec-security" toc="default">
<t>
The security considerations defined in <xref format="default"
<section anchor="sec-security" title="Security Considerations"
toc="default">
<t>The security considerations defined in <xref format="default"
pageno="false" target="RFC3264"/> and <xref format="default"
pageno="false" target="RFC5888"/> apply to the BUNDLE
extension. Bundle does not change which information
flows over the network but only changes which addresses and
ports that information is flowing on and thus has very little
impact on the security of the RTP sessions.
</t>
<t>
When the BUNDLE extension is used, a single set of security credentials
might be used for all media streams specified by a BUNDLE group.
</t>
<t>
When the BUNDLE extension is used, the number of SSRC values within
a single RTP session increases, which increases the risk of SSRC
collision. <xref format="default" pageno="false" target="RFC4568"/>
describes how SSRC collision may weaken SRTP and SRTCP encryption
in certain situations.
</t>
pageno="false" target="RFC5888"/> apply to the BUNDLE extension. Bundle
does not change which information, e.g., RTP streams, that flows over

This comment has been minimized.

Copy link
@ekr

ekr Mar 28, 2017

you can remove "that"

the network, with the exception of the usage of the MID SDES item as
discussed below. Primarily it changes which addresses and ports, and
thus in which (RTP) sessions that the information is flowing in. This
affects the security contexts being used and can cause previously
separated information flows to share security context. This has very

This comment has been minimized.

Copy link
@ekr

ekr Mar 28, 2017

"to share the same security context"

little impact on the performance of the security mechanism of the RTP
sessions. In cases where one would have applied different security
policies on the different RTP streams being bundled, or where the
parties having access to the security contexts would have differed
between the RTP stream additional analysis of the implications are

This comment has been minimized.

Copy link
@ekr

ekr Mar 28, 2017

comma after "RTP stream".

needed before selecting to apply BUNDLE.</t>

<t>The identification-tag, independent of transport, RTCP SDES packet or
RTP header extension, can expose the value to parties beyond the
signaling chain. Therefore, the identification-tag values MUST be
generated in a fashion that does not leak user information, e.g.,
randomly or using a per-bundle group counter, and SHOULD be 3 bytes or
less, to allow them to efficiently fit into the MID RTP header
extension. Note that if implementations use different methods for
generating identification-tags this could enable fingerprinting of the
implementation making it vulnerable to targeted attacks. The
identification-tag is exposed on the RTP stream level when included in
the RTP header extensions, however what it reveals of the RTP media
stream structure of the endpoint and application was already possible to
deduce from the RTP streams without the MID SDES header extensions. As
the identification-tag is also used to route the media stream to the
right application functionality it is also important that the value
received is the one intended by the sender, thus integrity and the
authenticity of the source are important to prevent denial of service on
the application. Existing SRTP configurations and other security
mechanisms protecting the whole RTP/RTCP packets will provide the
necessary protection.</t>

<t>When the BUNDLE extension is used, the set of configurations of the
security mechanism used in all the bundled media descriptions will need
to be compatible so that they can simultaneously used in parallel,
at least per direction or endpoint. When using SRTP this will be the
case, at least for the IETF defined key-management solutions due to
their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their
classification in <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/>.</t>

This comment has been minimized.

Copy link
@ekr

ekr Mar 28, 2017

Might want to fix the indent here.


<t><xref target="RFC7941">"RTP Header Extension for the RTP Control
Protocol (RTCP) Source Description Items"</xref> security consideration

This comment has been minimized.

Copy link
@ekr

ekr Mar 28, 2017

The security considerations of...

requires that when RTCP is confidentiality protected that any SDES RTP
header extension carrying an SDES item, like the MID RTP header

This comment has been minimized.

Copy link
@ekr

ekr Mar 28, 2017

s/like/such as/

extension, is also protected using commensurate strength algorithms.
However, assuming the above requirements and recommendations are
followed there are no known significant security risks with leaving the
MID RTP header extension without confidentiality protection. Thus, the
requirements in RFC 7941 MAY be ignored for the MID RTP header
extension. Security mechanisms for RTP/RTCP are discussed in Options for
Securing RTP Sessions <xref format="default" pageno="false"
target="RFC7201"/>, for example SRTP <xref format="default"
pageno="false" target="RFC3711"/> can provide the necessary security
functions of ensuring the integrity and source authenticity.</t>
</section>

<section title="Examples" anchor="sec-example-alt1" toc="default">
@@ -2453,6 +2493,7 @@ SDP Answer (2)
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.3550"?>
<?rfc include="reference.RFC.3605"?>
<?rfc include='reference.RFC.3711'?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.4961"?>
<?rfc include="reference.RFC.5245"?>
@@ -2461,6 +2502,7 @@ SDP Answer (2)
<?rfc include="reference.RFC.5764"?>
<?rfc include="reference.RFC.5888"?>
<?rfc include="reference.RFC.6347"?>
<?rfc include="reference.RFC.7201"?>
<?rfc include="reference.RFC.7656"?>
<?rfc include="reference.RFC.7941"?>
<?rfc include="reference.I-D.draft-ietf-ice-rfc5245bis-04"?>
ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.