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.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/