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/