draft-ietf-avt-srtp-not-mandatory-14.txt | draft-ietf-avt-srtp-not-mandatory-15.txt | |||
---|---|---|---|---|
Network Working Group C.S. Perkins | Network Working Group C. Perkins | |||
Internet-Draft University of Glasgow | Internet-Draft University of Glasgow | |||
Intended status: Informational M. Westerlund | Intended status: Informational M. Westerlund | |||
Expires: April 18, 2014 Ericsson | Expires: July 20, 2014 Ericsson | |||
October 15, 2013 | January 16, 2014 | |||
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-14.txt | draft-ietf-avt-srtp-not-mandatory-15.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. This is relevant for designers and | |||
reviewers of future RTP extensions are provided, to ensure that | reviewers of future RTP extensions, to ensure that appropriate | |||
appropriate security mechanisms are mandated, and that any such | security mechanisms are mandated, and that any such mechanisms are | |||
mechanisms are specified in a manner that conforms with the RTP | 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 April 18, 2014. | This Internet-Draft will expire on July 20, 2014. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 | 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 . . . . . . . . 4 | 4. RTP Session Establishment and Key Management . . . . . . . . 4 | |||
5. On the Requirement for Strong Security in Framework protocols 5 | 5. On the Requirement for Strong Security in Framework protocols 5 | |||
6. Guidelines for Securing the RTP Protocol Framework . . . . . 6 | 6. 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 | |||
skipping to change at page 3, line 5 | skipping to change at page 2, line 49 | |||
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 security mechanisms defined for use | in the global Internet". The security mechanisms defined for use | |||
with RTP allow these requirements to be met. However, since RTP is a | with RTP allow these requirements to be met. However, since RTP is a | |||
protocol framework that is suitable for a wide variety of use cases, | protocol framework that is suitable for a wide variety of use cases, | |||
there is no single security mechanism that is suitable for every | there is no single security mechanism that is suitable for every | |||
scenario. This memo outlines why this is the case, and discusses how | scenario. This memo outlines why this is the case, and discusses how | |||
users of 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 document provides high level guidance on how to handle security | |||
future RTP-related work in the IETF. It does not specify a standard | issues for the various type of components within the RTP framework as | |||
of any kind. | well as the role of the service or application using RTP to ensure | |||
strong security is implemented. This document does not provide the | ||||
guidance that an individual implementer, or even specifier of a RTP | ||||
application, really can use to determine what security mechanism they | ||||
need to use; that is not intended with this document. | ||||
A non-exhaustive list of the RTP security options available at the | ||||
time of this writing is outlined in | ||||
[I-D.ietf-avtcore-rtp-security-options]. This document gives an | ||||
overview of the available RTP solutions, and provides guidance on | ||||
their applicability for different application domains. It also | ||||
attempts to provide indication of actual and intended usage at time | ||||
of writing as additional input to help with considerations such as | ||||
interoperability, availability of implementations etc. | ||||
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; | o Point-to-point voice telephony; | |||
o Point-to-point video conferencing and telepresence; | o Point-to-point video conferencing and telepresence; | |||
skipping to change at page 6, line 9 | skipping to change at page 6, line 18 | |||
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, in | that use the protocol framework and are expected to interoperate, in | |||
cases where the 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. 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. | |||
skipping to change at page 8, line 4 | skipping to change at page 8, line 12 | |||
followed by the selection of a mandatory to implement security | followed by the selection of a mandatory to implement security | |||
building blocks for that class of application, including the desired | building blocks for that class of application, including the desired | |||
RTP traffic protection and key-management. A non-exhaustive list of | RTP traffic protection and key-management. A non-exhaustive list of | |||
the RTP security options available at the time of this writing is | the RTP security options available at the time of this writing is | |||
outlined in [I-D.ietf-avtcore-rtp-security-options]. It is expected | outlined in [I-D.ietf-avtcore-rtp-security-options]. It is expected | |||
that each class of application will be supported by a memo describing | that each class of application will be supported by a memo describing | |||
what security options are mandatory to implement for that usage | what security options are mandatory to implement for that usage | |||
scenario. | scenario. | |||
8. Security Considerations | 8. Security Considerations | |||
This entire memo is about security. | ||||
This entire memo is about mandatory to implement security. | ||||
9. IANA Considerations | 9. IANA Considerations | |||
None. | None. | |||
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, Sean Turner, and John Mattsson for their feedback. | Farrell, Sean Turner, John Mattsson, and Benoit Claise 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-07 | Sessions", draft-ietf-avtcore-rtp-security-options-10 | |||
(work in progress), October 2013. | (work in progress), January 2014. | |||
[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-38 (work in | (RTSP)", draft-ietf-mmusic-rfc2326bis-38 (work in | |||
progress), October 2013. | progress), October 2013. | |||
[I-D.ietf-rtcweb-security-arch] | [I-D.ietf-rtcweb-security-arch] | |||
Rescorla, E., "WebRTC Security Architecture", draft-ietf- | Rescorla, E., "WebRTC Security Architecture", draft-ietf- | |||
rtcweb-security-arch-07 (work in progress), July 2013. | rtcweb-security-arch-07 (work in progress), July 2013. | |||
End of changes. 13 change blocks. | ||||
21 lines changed or deleted | 35 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/ |