draft-ietf-avt-srtp-not-mandatory-12.txt | draft-ietf-avt-srtp-not-mandatory-13.txt | |||
---|---|---|---|---|
Network Working Group C. Perkins | Network Working Group C.S. Perkins | |||
Internet-Draft University of Glasgow | Internet-Draft University of Glasgow | |||
Intended status: Informational M. Westerlund | Intended status: Informational M. Westerlund | |||
Expires: August 29, 2013 Ericsson | Expires: November 07, 2013 Ericsson | |||
February 25, 2013 | May 06, 2013 | |||
Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single | Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single | |||
Media Security Solution | Media Security Solution | |||
draft-ietf-avt-srtp-not-mandatory-12.txt | draft-ietf-avt-srtp-not-mandatory-13.txt | |||
Abstract | Abstract | |||
This memo discusses the problem of securing real-time multimedia | This memo discusses the problem of securing real-time multimedia | |||
sessions, and explains why the Real-time Transport Protocol (RTP), | sessions, and explains why the Real-time Transport Protocol (RTP), | |||
and the associated RTP control protocol (RTCP), do not mandate a | and the associated RTP control protocol (RTCP), do not mandate a | |||
single media security mechanism. Guidelines for designers and | single media security mechanism. Guidelines for designers and | |||
reviewers of future RTP extensions are provided, to ensure that | reviewers of future RTP extensions are provided, to ensure that | |||
appropriate security mechanisms are mandated, and that any such | appropriate security mechanisms are mandated, and that any such | |||
mechanisms are specified in a manner that conforms with the RTP | mechanisms are specified in a manner that conforms with the RTP | |||
architecture. | architecture. | |||
Status of this Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on August 29, 2013. | This Internet-Draft will expire on November 07, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. RTP Applications and Deployment Scenarios . . . . . . . . . . . 3 | 2. RTP Applications and Deployment Scenarios . . . . . . . . . . 3 | |||
3. RTP Media Security . . . . . . . . . . . . . . . . . . . . . . 4 | 3. RTP Media Security . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. RTP Session Establishment and Key Management . . . . . . . . . 5 | 4. RTP Session Establishment and Key Management . . . . . . . . 4 | |||
5. On the Requirement for Strong Security in Framework | 5. On the Requirement for Strong Security in Framework protocols 5 | |||
protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 6. Guidelines for Securing the RTP Protocol Framework . . . . . 6 | |||
6. Guidelines for Securing the RTP Protocol Framework . . . . . . 6 | 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 | 11. Informative References . . . . . . . . . . . . . . . . . . . 8 | |||
11. Informative References . . . . . . . . . . . . . . . . . . . . 8 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 | ||||
1. Introduction | 1. Introduction | |||
The Real-time Transport Protocol (RTP) [RFC3550] is widely used for | The Real-time Transport Protocol (RTP) [RFC3550] is widely used for | |||
voice over IP, Internet television, video conferencing, and other | voice over IP, Internet television, video conferencing, and other | |||
real-time and streaming media applications. Despite this use, the | real-time and streaming media applications. Despite this use, the | |||
basic RTP specification provides only limited options for media | basic RTP specification provides only limited options for media | |||
security, and defines no standard key exchange mechanism. Rather, a | security, and defines no standard key exchange mechanism. Rather, a | |||
number of extensions are defined that can provide confidentiality and | number of extensions are defined that can provide confidentiality and | |||
authentication of RTP media streams and RTP Control Protocol (RTCP) | authentication of RTP media streams and RTP Control Protocol (RTCP) | |||
messages. Other mechanisms define key exchange protocols. This memo | messages. Other mechanisms define key exchange protocols. This memo | |||
outlines why it is appropriate that multiple extension mechanisms are | outlines why it is appropriate that multiple extension mechanisms are | |||
defined rather than mandating a single security and keying mechanism. | defined rather than mandating a single security and keying mechanism | |||
for all users of RTP. | ||||
The IETF policy on Strong Security Requirements for IETF Standard | The IETF policy on Strong Security Requirements for IETF Standard | |||
Protocols [RFC3365] (the so-called "Danvers Doctrine") states that | Protocols [RFC3365] (the so-called "Danvers Doctrine") states that | |||
"we MUST implement strong security in all protocols to provide for | "we MUST implement strong security in all protocols to provide for | |||
the all too frequent day when the protocol comes into widespread use | the all too frequent day when the protocol comes into widespread use | |||
in the global Internet". The mechanisms defined for use with RTP | in the global Internet". The security mechanisms defined for use | |||
allow these requirements to be met. However, since RTP is a protocol | with RTP allow these requirements to be met. However, since RTP is a | |||
framework that is suitable for a wide variety of use cases, there is | protocol framework that is suitable for a wide variety of use cases, | |||
no single security mechanism that is suitable for every scenario. | there is no single security mechanism that is suitable for every | |||
This memo outlines why this is the case, and discusses how users of | scenario. This memo outlines why this is the case, and discusses how | |||
RTP can meet the requirement for strong security. | users of RTP can meet the requirement for strong security. | |||
This memo provides information for the community and for reviewers of | This memo provides information for the community and for reviewers of | |||
future RTP-related work in the IETF. It does not specify a standard | future RTP-related work in the IETF. It does not specify a standard | |||
of any kind. | of any kind. | |||
2. RTP Applications and Deployment Scenarios | 2. RTP Applications and Deployment Scenarios | |||
The range of application and deployment scenarios where RTP has been | The range of application and deployment scenarios where RTP has been | |||
used includes, but is not limited to, the following: | used includes, but is not limited to, the following: | |||
o Point-to-point voice telephony (fixed and wireless networks) | o Point-to-point voice telephony; | |||
o Point-to-point voice and video conferencing | o Point-to-point video conferencing and telepresence | |||
o Centralised group video conferencing with a multipoint conference | o Centralised group video conferencing and telepresence, using a | |||
unit (MCU) | multipoint conference unit (MCU) or similar central middlebox | |||
o Any Source Multicast video conferencing (light-weight sessions; | o Any Source Multicast video (ASM) conferencing using the light- | |||
Mbone conferencing) | weight sessions model (e.g., the Mbone conferencing tools) | |||
o Point-to-point streaming audio and/or video | o Point-to-point streaming audio and/or video (e.g., on-demand TV or | |||
movie streaming) | ||||
o Source-specific multicast (SSM) streaming to large group (IPTV and | o Source-specific multicast (SSM) streaming to large receiver groups | |||
3GPP Multimedia Broadcast Multicast Service (MBMS) [MBMS]) | (e.g., IPTV streaming by residential ISPs, or the 3GPP Multimedia | |||
o Replicated unicast streaming to a group | Broadcast Multicast Service [MBMS]) | |||
o Replicated unicast streaming to a group of receivers | ||||
o Interconnecting components in music production studios and video | o Interconnecting components in music production studios and video | |||
editing suites | editing suites | |||
o Interconnecting components of distributed simulation systems | o Interconnecting components of distributed simulation systems | |||
o Streaming real-time sensor data (e.g., e-VLBI radio astronomy) | o Streaming real-time sensor data (e.g., e-VLBI radio astronomy) | |||
As can be seen, these scenarios vary from point-to-point to large | As can be seen, these scenarios vary from point-to-point sessions to | |||
multicast groups, from interactive to non-interactive, and from low | very large multicast groups, from interactive to non-interactive, and | |||
bandwidth (kilobits per second) telephony to high bandwidth (multiple | from low bandwidth (kilobits per second) telephony to high bandwidth | |||
gigabits per second) video and data streaming. While most of these | (multiple gigabits per second) video and data streaming. While most | |||
applications run over UDP [RFC0768], some use TCP [RFC0793], | of these applications run over UDP [RFC0768], some use TCP [RFC0793], | |||
[RFC4614] or DCCP [RFC4340] as their underlying transport. Some run | [RFC4614] or DCCP [RFC4340] as their underlying transport. Some run | |||
on highly reliable optical networks, others use low rate unreliable | on highly reliable optical networks, others use low rate unreliable | |||
wireless networks. Some applications of RTP operate entirely within | wireless networks. Some applications of RTP operate entirely within | |||
a single trust domain, others are inter-domain, with untrusted (and | a single trust domain, others run inter-domain, with untrusted (and, | |||
potentially unknown) users. The range of scenarios is wide, and | in some cases, potentially unknown) users. The range of scenarios is | |||
growing both in number and in heterogeneity. | wide, and growing both in number and in heterogeneity. | |||
3. RTP Media Security | 3. RTP Media Security | |||
The wide range of application scenarios where RTP is used has led to | The wide range of application scenarios where RTP is used has led to | |||
the development of multiple solutions for securing RTP media streams | the development of multiple solutions for securing RTP media streams | |||
and RTCP control messages, considering different requirements. | and RTCP control messages, considering different requirements. | |||
Perhaps the most widely applicable of these security options is the | Perhaps the most widely applicable of these security options is the | |||
Secure RTP (SRTP) framework [RFC3711]. This is an application-level | Secure RTP (SRTP) framework [RFC3711]. This is an application-level | |||
media security solution, encrypting the media payload data (but not | media security solution, encrypting the media payload data (but not | |||
the RTP headers) to provide confidentiality, and supporting source | the RTP headers) to provide confidentiality, and supporting source | |||
origin authentication as an option. SRTP was carefully designed to | origin authentication as an option. SRTP was carefully designed to | |||
be both low overhead, and to support the group communication and | be low overhead, including operating on links subject to RTP header | |||
third-party performance monitoring features of RTP, across a range of | compression, and to support the group communication and third-party | |||
networks. | performance monitoring features of RTP, across a range of networks. | |||
SRTP is not the only media security solution in use, however, and | SRTP is not the only media security solution for RTP, however, and | |||
alternatives are more appropriate for some scenarios, and necessary | alternatives can be more appropriate in some scenarios, perhaps due | |||
in some cases where SRTP is not suitable. For example, ISMAcryp | to ease of integration with other parts of the complete system. In | |||
[ISMACrypt2] provides payload-level confidentiality that is | addition, SRTP does not address all possible security requirements, | |||
appropriate for certain types of streaming video application, but | and other solutions are needed in cases where SRTP is not suitable. | |||
that is not suitable for voice telephony (the range of available RTP | For example, ISMAcryp payload-level confidentiality [ISMACrypt2] is | |||
security options, and their applicability to different scenarios, is | appropriate for some types of streaming video application, but is not | |||
outlined in [I-D.ietf-avtcore-rtp-security-options]). At present, | suitable for voice telephony, and uses features that are not provided | |||
there is no media security protocol that is appropriate for all the | by SRTP. | |||
environments where RTP is used. Multiple RTP media security | ||||
protocols can be expected to remain in wide use for the foreseeable | The range of available RTP security options, and their applicability | |||
to different scenarios, is outlined in | ||||
[I-D.ietf-avtcore-rtp-security-options]. At the time of this | ||||
writing, there is no media security protocol that is appropriate for | ||||
all the environments where RTP is used. Multiple RTP media security | ||||
protocols are expected to remain in wide use for the foreseeable | ||||
future. | future. | |||
4. RTP Session Establishment and Key Management | 4. RTP Session Establishment and Key Management | |||
A range of different protocols for RTP session establishment and key | A range of different protocols for RTP session establishment and key | |||
exchange exist, matching the diverse range of use cases for the RTP | exchange exist, matching the diverse range of use cases for the RTP | |||
framework. These mechanisms can be split into two categories: those | framework. These mechanisms can be split into two categories: those | |||
that operate in-band on the media path, and those that are out-of- | that operate in-band on the media path, and those that are out-of- | |||
band and operate as part of the session establishment signalling | band and operate as part of the session establishment signalling | |||
channel. The requirements for these two classes of solution are | channel. The requirements for these two classes of solution are | |||
different, and a wide range of solutions have been developed in this | different, and a wide range of solutions have been developed in this | |||
space. | space. | |||
A more detailed survey of requirements for media security management | A more detailed survey of requirements for media security management | |||
protocols can be found in [RFC5479]. As can be seen, the range of | protocols can be found in [RFC5479]. As can be seen from that memo, | |||
use cases is wide, and there is no single key management protocol | the range of use cases is wide, and there is no single key management | |||
that is appropriate for all scenarios. These solutions have been | protocol that is appropriate for all scenarios. The solutions have | |||
further diversified by the existence of infrastructure elements such | been further diversified by the existence of infrastructure elements, | |||
as authentication solutions that are tied into the key management. | such as authentication systems, that are tied to the key management. | |||
Some of the available keying options for RTP sessions are described | The most important and widely used keying options for RTP sessions at | |||
in [I-D.ietf-avtcore-rtp-security-options], although this list is not | the time of this writing are described in | |||
ensured to be exhaustive but include the ones known to the authors at | [I-D.ietf-avtcore-rtp-security-options]. | |||
the time of publication. | ||||
5. On the Requirement for Strong Security in Framework protocols | 5. On the Requirement for Strong Security in Framework protocols | |||
The IETF requires that all protocols provide a strong, mandatory to | The IETF requires that all protocols provide a strong, mandatory to | |||
implement, security solution [RFC3365]. This is essential for the | implement, security solution [RFC3365]. This is essential for the | |||
overall security of the Internet, to ensure that all implementations | overall security of the Internet, to ensure that all implementations | |||
of a protocol can interoperate in a secure way. Framework protocols | of a protocol can interoperate in a secure way. Framework protocols | |||
offer a challenge for this mandate, however, since they are designed | offer a challenge for this mandate, however, since they are designed | |||
for use by different classes of applications, in different | to be used by different classes of applications, in a wide range of | |||
environments. The different use cases for the framework have | different environments. The different use cases for the framework | |||
different security requirements, and implementations designed for | have different security requirements, and implementations designed | |||
different environments are generally not expected to interwork. | for different environments are generally not expected to interwork. | |||
RTP is an example of a framework protocol with wide applicability. | RTP is an example of a framework protocol with wide applicability. | |||
The wide range of scenarios described in Section 2 show the issues | The wide range of scenarios described in Section 2 show the issues | |||
that arise in mandating a single security mechanism for this type of | that arise in mandating a single security mechanism for this type of | |||
framework. It would be desirable if a single media security | framework. It would be desirable if a single media security | |||
solution, and a single key management solution, could be developed, | solution, and a single key management solution, could be developed, | |||
suitable for applications across this range of use scenarios. The | suitable for applications across this range of use scenarios. The | |||
authors are not aware of any such solution, however, and believe it | authors are not aware of any such solution, however, and believe it | |||
is unlikely that any such solution will be developed. In part, this | is unlikely that any such solution will be developed. In part, this | |||
is because applications in the different domains are not intended to | is because applications in the different domains are not intended to | |||
skipping to change at page 6, line 4 | skipping to change at page 5, line 32 | |||
RTP is an example of a framework protocol with wide applicability. | RTP is an example of a framework protocol with wide applicability. | |||
The wide range of scenarios described in Section 2 show the issues | The wide range of scenarios described in Section 2 show the issues | |||
that arise in mandating a single security mechanism for this type of | that arise in mandating a single security mechanism for this type of | |||
framework. It would be desirable if a single media security | framework. It would be desirable if a single media security | |||
solution, and a single key management solution, could be developed, | solution, and a single key management solution, could be developed, | |||
suitable for applications across this range of use scenarios. The | suitable for applications across this range of use scenarios. The | |||
authors are not aware of any such solution, however, and believe it | authors are not aware of any such solution, however, and believe it | |||
is unlikely that any such solution will be developed. In part, this | is unlikely that any such solution will be developed. In part, this | |||
is because applications in the different domains are not intended to | is because applications in the different domains are not intended to | |||
interwork, so there is no incentive to develop a single mechanism. | interwork, so there is no incentive to develop a single mechanism. | |||
More importantly, though, the security requirements for the different | More importantly, though, the security requirements for the different | |||
usage scenarios vary widely, and an appropriate security mechanism in | usage scenarios vary widely, and an appropriate security mechanism in | |||
one scenario simply does not work for some other scenarios. | one scenario simply does not work for some other scenarios. | |||
For a framework protocol, it appears that the only sensible solution | For a framework protocol, it appears that the only sensible solution | |||
to the strong security requirement of [RFC3365] is to develop and use | to the strong security requirement of [RFC3365] is to develop and use | |||
building blocks for the basic security services of confidentiality, | building blocks for the basic security services of confidentiality, | |||
integrity protection, authorisation, and authentication. When new | integrity protection, authorisation, authentication, and so on. When | |||
uses for the framework arise, they need to be studied to check if the | new uses for the framework protocol arise, they need to be studied to | |||
existing building blocks satisfy the requirements. A mandatory to | determine if the existing security building blocks can satisfy the | |||
implement set of security building blocks can then be specified for | requirements, or if new building blocks need to be developed. A | |||
that usage scenario of the framework. | mandatory to implement set of security building blocks can then be | |||
specified for that usage scenario of the framework. | ||||
Therefore, when considering the strong and mandatory to implement | Therefore, when considering the strong and mandatory to implement | |||
security mechanism for a specific class of applications, one has to | security mechanism for a specific class of applications, one has to | |||
consider what security building blocks need to be supported. To | consider what security building blocks need to be supported. To | |||
maximize interoperability it is important that common media security | maximize interoperability it is important that common media security | |||
and key management mechanisms are defined for classes of application | and key management mechanisms are defined for classes of application | |||
with similar requirements. The IETF needs to participate in this | with similar requirements. The IETF needs to participate in this | |||
selection of security building blocks for each class of applications | selection of security building blocks for each class of applications | |||
that use the protocol framework and are expected to interoperate | that use the protocol framework and are expected to interoperate, in | |||
where IETF has the appropriate knowledge of the class of | cases where the IETF has the appropriate knowledge of the class of | |||
applications. | applications. | |||
6. Guidelines for Securing the RTP Protocol Framework | 6. Guidelines for Securing the RTP Protocol Framework | |||
The IETF requires that protocols specify mandatory to implement (MTI) | The IETF requires that protocols specify mandatory to implement (MTI) | |||
strong security [RFC3365]. This applies to the specification of each | strong security [RFC3365]. This applies to the specification of each | |||
interoperable class of application that makes use of RTP. However, | interoperable class of application that makes use of RTP. However, | |||
RTP is a framework protocol, so the arguments made in Section 5 also | RTP is a framework protocol, so the arguments made in Section 5 also | |||
apply. Given the variability of the classes of application that use | apply. Given the variability of the classes of application that use | |||
RTP, and the variety of the currently available security mechanisms | RTP, and the variety of the currently available security mechanisms | |||
described in [I-D.ietf-avtcore-rtp-security-options], no one set of | described in [I-D.ietf-avtcore-rtp-security-options], no one set of | |||
MTI security options can realistically be specified that apply to all | MTI security options can realistically be specified that apply to all | |||
classes of RTP applications. | classes of RTP applications. | |||
Documents that define an interoperable class of applications using | Documents that define an interoperable class of applications using | |||
RTP are subject to [RFC3365] and need to specify MTI security | RTP are subject to [RFC3365], and so need to specify MTI security | |||
mechanisms. This is because such specifications do fully specify | mechanisms. This is because such specifications do fully specify | |||
interoperable applications that use RTP. Examples of such a | interoperable applications that use RTP. Examples of such documents | |||
documents in development at the time of this writing would be the | under development in the IETF at the time of this writing are the | |||
RTCWEB Security Architecture [I-D.ietf-rtcweb-security-arch] and Real | RTCWEB Security Architecture [I-D.ietf-rtcweb-security-arch] and the | |||
Time Streaming Protocol 2.0 (RTSP) [I-D.ietf-mmusic-rfc2326bis]. It | Real Time Streaming Protocol 2.0 (RTSP) [I-D.ietf-mmusic-rfc2326bis]. | |||
is also expected that a similar document will be produced for voice- | It is also expected that a similar document will be produced for | |||
over-IP applications using SIP and RTP. | voice-over-IP applications using SIP and RTP. | |||
The RTP framework can be extended in ways that do not specify an | The RTP framework includes several extension points. Some extensions | |||
interoperable class of applications. Two important extension points | can significantly change the behaviour of the protocol, to the extent | |||
are RTP Payload Formats and RTP Profiles. An RTP Payload Format | that applications using the extension form a separate interoperable | |||
defines how the output of a media codec can be used with RTP. At the | class of applications to those that have not been extended. Other | |||
time of this writing, there are over 70 RTP Payload Formats defined | extension points are defined in such a manner that they can be used | |||
in published RFCs, with more in development. It is appropriate for | (largely) independently of the class of applications using RTP. Two | |||
an RTP payload format to discuss specific security implications of | important extension points that are can be independent of the class | |||
using that codec with RTP. However, an RTP payload format does not | of applications are RTP Payload Formats and RTP Profiles. | |||
specify an interoperable class of applications that use RTP, and is | ||||
neither secure in itself, nor something to which [RFC3365] applies. | An RTP Payload Format defines how the output of a media codec can be | |||
Future RTP payload format specifications ought to explicitly state | used with RTP. At the time of this writing, there are over 70 RTP | |||
this, and include a reference to this memo for explanation. It is | Payload Formats defined in published RFCs, with more in development. | |||
not appropriate for an RTP payload format to mandate the use of SRTP | It is appropriate for an RTP payload format to discuss the specific | |||
[RFC3711], or any other security building blocks, since that RTP | security implications of using that media codec with RTP. However, | |||
an RTP payload format does not specify an interoperable class of | ||||
applications that use RTP since, in the vast majority of cases, a | ||||
media codec and it's associated RTP payload format can be used with | ||||
many different classes of application. As such, an RTP payload | ||||
format is neither secure in itself, nor something to which [RFC3365] | ||||
applies. Future RTP payload format specifications need to explicitly | ||||
state this, and include a reference to this memo for explanation. It | ||||
is not appropriate for an RTP payload format to mandate the use of | ||||
SRTP [RFC3711], or any other security building blocks, since that RTP | ||||
payload format might be used by different classes of application that | payload format might be used by different classes of application that | |||
use RTP, and that have different security requirements. | use RTP, and that have different security requirements. | |||
RTP profiles are larger extensions that adapt the RTP framework for | RTP profiles are larger extensions that adapt the RTP framework for | |||
use with particular classes of application. In some cases, those | use with particular classes of application. In some cases, those | |||
classes of application might share common security requirements so | classes of application might share common security requirements so | |||
that it could make sense for an RTP profile to mandate particular | that it could make sense for an RTP profile to mandate particular | |||
security options and building blocks (the RTP/SAVP profile [RFC3711] | security options and building blocks (the RTP/SAVP profile [RFC3711] | |||
is an example of this type of RTP profile). In other cases, though, | is an example of this type of RTP profile). In other cases, though, | |||
an RTP profile is applicable to such a wide range of applications | an RTP profile is applicable to such a wide range of applications | |||
that it would not make sense for that profile to mandate particular | that it would not make sense for that profile to mandate particular | |||
security building blocks be used (the RTP/AVPF profile [RFC4585] is | security building blocks be used (the RTP/AVPF profile [RFC4585] is | |||
an example of this type of RTP profile, since it provides building | an example of this type of RTP profile, since it provides building | |||
blocks that can be used in different styles of application). Any new | blocks that can be used in different styles of application). A new | |||
RTP profile needs to discuss if it makes sense to mandate particular | RTP profile specification needs to discuss whether, or not, it makes | |||
security building blocks be used with implementations of that | sense to mandate particular security building blocks that need to be | |||
profile, but without the expectation that all RTP profiles will | used with all implementations of that profile; however, there is no | |||
mandate particular security solutions. RTP profiles that do not | expectation that all RTP profiles will mandate particular security | |||
specify an interoperable usage for a particular class of RTP | solutions. RTP profiles that do not specify an interoperable usage | |||
applications are neither secure in themselves, nor something to which | for a particular class of RTP applications are neither secure in | |||
[RFC3365] applies; any future RTP profiles in this category need to | themselves, nor something to which [RFC3365] applies; any future RTP | |||
explicitly state this with justification, and include a reference to | profiles in this category need to explicitly state this with | |||
this memo. | justification, and include a reference to this memo. | |||
7. Conclusions | 7. Conclusions | |||
The RTP framework is used in a wide range of different scenarios, | The RTP framework is used in a wide range of different scenarios, | |||
with no common security requirements. Accordingly, neither SRTP | with no common security requirements. Accordingly, neither SRTP | |||
[RFC3711], nor any other single media security solution or keying | [RFC3711], nor any other single media security solution or keying | |||
mechanism, can be mandated for all uses of RTP. In the absence of a | mechanism, can be mandated for all uses of RTP. In the absence of a | |||
single common security solution, it is important to consider what | single common security solution, it is important to consider what | |||
mechanisms can be used to provide strong and interoperable security | mechanisms can be used to provide strong and interoperable security | |||
for each different scenario where RTP applications are used. This | for each different scenario where RTP applications are used. This | |||
skipping to change at page 8, line 32 | skipping to change at page 8, line 20 | |||
10. Acknowledgements | 10. Acknowledgements | |||
Thanks to Ralph Blom, Hannes Tschofenig, Dan York, Alfred Hoenes, | Thanks to Ralph Blom, Hannes Tschofenig, Dan York, Alfred Hoenes, | |||
Martin Ellis, Ali Begen, Keith Drage, Ray van Brandenburg, Stephen | Martin Ellis, Ali Begen, Keith Drage, Ray van Brandenburg, Stephen | |||
Farrell, and Sean Turner for their feedback. | Farrell, and Sean Turner for their feedback. | |||
11. Informative References | 11. Informative References | |||
[I-D.ietf-avtcore-rtp-security-options] | [I-D.ietf-avtcore-rtp-security-options] | |||
Westerlund, M. and C. Perkins, "Options for Securing RTP | Westerlund, M. and C. Perkins, "Options for Securing RTP | |||
Sessions", draft-ietf-avtcore-rtp-security-options-02 | Sessions", draft-ietf-avtcore-rtp-security-options-03 | |||
(work in progress), February 2013. | (work in progress), May 2013. | |||
[I-D.ietf-mmusic-rfc2326bis] | [I-D.ietf-mmusic-rfc2326bis] | |||
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., | Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., | |||
and M. Stiemerling, "Real Time Streaming Protocol 2.0 | and M. Stiemerling, "Real Time Streaming Protocol 2.0 | |||
(RTSP)", draft-ietf-mmusic-rfc2326bis-31 (work in | (RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in | |||
progress), February 2013. | progress), April 2013. | |||
[I-D.ietf-rtcweb-security-arch] | [I-D.ietf-rtcweb-security-arch] | |||
Rescorla, E., "RTCWEB Security Architecture", | Rescorla, E., "RTCWEB Security Architecture", draft-ietf- | |||
draft-ietf-rtcweb-security-arch-06 (work in progress), | rtcweb-security-arch-06 (work in progress), January 2013. | |||
January 2013. | ||||
[ISMACrypt2] | [ISMACrypt2] | |||
"ISMA Encryption and Authentication, Version 2.0 release | Internet Streaming Media Alliance (ISMA), , "ISMA | |||
Encryption and Authentication, Version 2.0 release | ||||
version", November 2007. | version", November 2007. | |||
[MBMS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); | [MBMS] 3GPP, , "Multimedia Broadcast/Multicast Service (MBMS); | |||
Protocols and codecs TS 26.346". | Protocols and codecs TS 26.346", . | |||
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
August 1980. | August 1980. | |||
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC | |||
RFC 793, September 1981. | 793, September 1981. | |||
[RFC3365] Schiller, J., "Strong Security Requirements for Internet | [RFC3365] Schiller, J., "Strong Security Requirements for Internet | |||
Engineering Task Force Standard Protocols", BCP 61, | Engineering Task Force Standard Protocols", BCP 61, RFC | |||
RFC 3365, August 2002. | 3365, August 2002. | |||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", STD 64, RFC 3550, July 2003. | Applications", STD 64, RFC 3550, July 2003. | |||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | |||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | Norrman, "The Secure Real-time Transport Protocol (SRTP)", | |||
RFC 3711, March 2004. | RFC 3711, March 2004. | |||
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram | [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram | |||
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. | Congestion Control Protocol (DCCP)", RFC 4340, March 2006. | |||
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | |||
"Extended RTP Profile for Real-time Transport Control | "Extended RTP Profile for Real-time Transport Control | |||
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, | Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July | |||
July 2006. | 2006. | |||
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap | [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap | |||
for Transmission Control Protocol (TCP) Specification | for Transmission Control Protocol (TCP) Specification | |||
Documents", RFC 4614, September 2006. | Documents", RFC 4614, September 2006. | |||
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, | [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, | |||
"Requirements and Analysis of Media Security Management | "Requirements and Analysis of Media Security Management | |||
Protocols", RFC 5479, April 2009. | Protocols", RFC 5479, April 2009. | |||
Authors' Addresses | Authors' Addresses | |||
End of changes. 35 change blocks. | ||||
126 lines changed or deleted | 142 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |