draft-ietf-avt-srtp-not-mandatory-05.txt		draft-ietf-avt-srtp-not-mandatory-06.txt
	Network Working Group C. 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: July 26, 2010 Ericsson		Expires: January 1, 2011 Ericsson
	January 22, 2010		June 30, 2010
	Why RTP Does Not Mandate a Single Security Mechanism		Why RTP Does Not Mandate a Single Security Mechanism
	draft-ietf-avt-srtp-not-mandatory-05.txt		draft-ietf-avt-srtp-not-mandatory-06.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.		single media security mechanism.
	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), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on January 1, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on July 26, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	skipping to change at page 4, line 45		skipping to change at page 4, line 45
	SRTP is not the only media security solution in use, however, and		SRTP is not the only media security solution in use, however, and
	alternatives are more appropriate for some scenarios. For example,		alternatives are more appropriate for some scenarios. For example,
	many client-server streaming media applications can run over a single		many client-server streaming media applications can run over a single
	TCP connection, multiplexing media data with control information on		TCP connection, multiplexing media data with control information on
	that connection (RTSP [I-D.ietf-mmusic-rfc2326bis] is a widely used		that connection (RTSP [I-D.ietf-mmusic-rfc2326bis] is a widely used
	example of such a protocol). The natural way to provide media		example of such a protocol). The natural way to provide media
	security for such client-server media applications is to use TLS		security for such client-server media applications is to use TLS
	[RFC5246] to protect the TCP connection, sending the RTP media data		[RFC5246] to protect the TCP connection, sending the RTP media data
	over the TLS connection. Using the SRTP framework in addition to TLS		over the TLS connection. Using the SRTP framework in addition to TLS
	is unncessary, and would result in double encryption of the media,		is unnecessary, and would result in double encryption of the media,
	and SRTP cannot be used instead of TLS since it is RTP-specific, and		and SRTP cannot be used instead of TLS since it is RTP-specific, and
	so cannot protect the control traffic.		so cannot protect the control traffic.
	Other RTP use cases work over networks which provide security at the		Other RTP use cases work over networks which provide security at the
	network layer, using IPsec. For example, certain 3GPP networks need		network layer, using IPsec. For example, certain 3GPP networks need
	IPsec security associations for other purposes, and can reuse those		IPsec security associations for other purposes, and can reuse those
	to secure the RTP session [3GPP.33.210]. SRTP is, again, unnecessary		to secure the RTP session [3GPP.33.210]. SRTP is, again, unnecessary
	in such environments, and its use would only introduce overhead for		in such environments, and its use would only introduce overhead for
	no gain.		no gain.
	skipping to change at page 5, line 38		skipping to change at page 5, line 38
	4. Implications for Key Management		4. Implications for Key Management
	With such a diverse range of use cases come a range of different		With such a diverse range of use cases come a range of different
	protocols for RTP session establishment. Mechanisms used to provide		protocols for RTP session establishment. Mechanisms used to provide
	security keying for these different session establishment protocols		security keying for these different session establishment protocols
	can basically be put into two categories: inband and out-of-band in		can basically be put into two categories: inband and out-of-band in
	relation to the session establishment mechanism. The requirements		relation to the session establishment mechanism. The requirements
	for these solutions are highly varying. Thus a wide range of		for these solutions are highly varying. Thus a wide range of
	solutions have been developed in this space:		solutions have been developed in this space:
	o The most common use case for RTP is probably point-to-point voice		o A common use case for RTP is probably point-to-point voice calls
	calls or centralised group conferences, negotiated using SIP		or centralised group conferences, negotiated using SIP [RFC3261]
	[RFC3261] with the SDP offer/answer model [RFC3264], operating on		with the SDP offer/answer model [RFC3264], operating on a trusted
	a trusted infrastructure. In such environments, SDP security		infrastructure. In such environments, SDP security descriptions
	descriptions [RFC4568] or the MIKEY [RFC4567] protocol are		[RFC4568] or the MIKEY [RFC4567] protocol are appropriate keying
	appropriate keying mechanisms, piggybacked onto the SDP [RFC4566]		mechanisms, piggybacked onto the SDP [RFC4566] exchange. The
	exchange. The infrastructure may be secured by protecting the SIP		infrastructure may be secured by protecting the SIP exchange using
	exchange using TLS or S/MIME, for example [RFC3261].		TLS or S/MIME, for example [RFC3261]. Protocols such as DTLS
			[RFC5764] or ZRTP [I-D.zimmermann-avt-zrtp] may also be
			appropriate in such environments.
	o Point-to-point RTP sessions may be negotiated using SIP with the		o Point-to-point RTP sessions may be negotiated using SIP with the
	offer/answer model, but operating over a network with untrusted		offer/answer model, but operating over a network with untrusted
	infrastructure. In such environments, the key management protocol		infrastructure. In such environments, the key management protocol
	is run on the media path, bypassing the untrusted infrastructure.		is run on the media path, bypassing the untrusted infrastructure.
			Protocols such as DTLS [RFC5764] or ZRTP [I-D.zimmermann-avt-zrtp]
	Protocols such as DTLS [I-D.ietf-avt-dtls-srtp] or ZRTP		are useful here.
	[I-D.zimmermann-avt-zrtp] are useful here.
	o For point-to-point client-server streaming of RTP over RTSP, a TLS		o For point-to-point client-server streaming of RTP over RTSP, a TLS
	association is appropriate to manage keying material, in much the		association is appropriate to manage keying material, in much the
	same manner as would be used to secure an HTTP session.		same manner as would be used to secure an HTTP session.
	o A session description may be sent by email, secured using S/MIME		o A session description may be sent by email, secured using S/MIME
	or PGP, or retrieved from a web page, using HTTP with TLS.		or PGP, or retrieved from a web page, using HTTP with TLS.
	o A session description may be distributed to a multicast group		o A session description may be distributed to a multicast group
	using SAP or FLUTE secured with S/MIME.		using SAP or FLUTE secured with S/MIME.
	o A session description may be distributed using the Open Mobile		o A session description may be distributed using the Open Mobile
	Alliance DRM key management specification [OMA-DRM] when using a		Alliance DRM key management specification [OMA-DRM] when using a
	point-to-point streaming session setup with RTSP in the 3GPP PSS		point-to-point streaming session setup with RTSP in the 3GPP PSS
	environment [PSS].		environment [PSS].
	o In the 3GPP Multimedia Broadcast Multicast Service (MBMS) system,		o In the 3GPP Multimedia Broadcast Multicast Service (MBMS) system,
	HTTP and MIKEY are used for key management [MBMS-SEC].		HTTP and MIKEY are used for key management [MBMS-SEC].
	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 [I-D.ietf-sip-media-security-requirements].		protocols can be found in [RFC5479]. As can be seen, the range of
	As can be seen, the range of use cases is wide, and there is no		use cases is wide, and there is no single protocol that is
	single protocol that is appropriate for all scenarios. These		appropriate for all scenarios. These solutions have been further
	solutions have been further diversified by the existence of		diversified by the existence of infrastructure elements such as
	infrastructure elements such as authentication solutions that are		authentication solutions that are tied into the key manangement.
	tied into the key manangement.
	5. On the Requirement for Strong Security in IETF protocols		5. On the Requirement for Strong Security in IETF protocols
	BCP 61 [RFC3365] puts a requirement on IETF protocols to provide		BCP 61 [RFC3365] puts a requirement on IETF protocols to provide
	strong, mandatory to implement, security solutions. This is actually		strong, mandatory to implement, security solutions. This is actually
	quite a difficult requirement for any type of framework protocol,		quite a difficult requirement for any type of framework protocol,
	like RTP, since one can never know all the deployment scenarios, and		like RTP, since one can never know all the deployment scenarios, and
	if they are covered by the security solution. It would clearly be		if they are covered by the security solution. It would clearly be
	desirable if a single media security solution and a single key		desirable if a single media security solution and a single key
	management solution could be developed, satisfying the range of use		management solution could be developed, satisfying the range of use
	skipping to change at page 8, line 8		skipping to change at page 8, line 8
	This entire memo is about security.		This entire memo is about security.
	8. IANA Considerations		8. IANA Considerations
	No IANA actions are required.		No IANA actions are required.
	9. Acknowledgements		9. Acknowledgements
	Thanks to Ralph Blom, Hannes Tschofenig, Dan York, Alfred Hoenes,		Thanks to Ralph Blom, Hannes Tschofenig, Dan York, Alfred Hoenes,
	Martin Ellis, and Ali Begen for their feedback.		Martin Ellis, Ali Begen, and Keith Drage for their feedback.
	10. Informative References		10. Informative References
	[3GPP.33.210]		[3GPP.33.210]
	3GPP, "IP network layer security", 3GPP TS 33.210,		3GPP, "IP network layer security", 3GPP TS 33.210.
	September 2008.
	[ETSI.TS.102.474]		[ETSI.TS.102.474]
	ETSI, "Digital Video Broadcasting (DVB); IP Datacast over		ETSI, "Digital Video Broadcasting (DVB); IP Datacast over
	DVB-H: Service Purchase and Protection", ETSI TS 102 474,		DVB-H: Service Purchase and Protection", ETSI TS 102 474,
	November 2007.		November 2007.
	[I-D.ietf-avt-dtls-srtp]
	McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for Secure
	Real-time Transport Protocol (SRTP)",
	draft-ietf-avt-dtls-srtp-07 (work in progress),
	February 2009.
	[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-22 (work in		(RTSP)", draft-ietf-mmusic-rfc2326bis-23 (work in
	progress), July 2009.		progress), March 2010.
	[I-D.ietf-sip-media-security-requirements]
	Wing, D., Fries, S., Tschofenig, H., and F. Audet,
	"Requirements and Analysis of Media Security Management
	Protocols", draft-ietf-sip-media-security-requirements-09
	(work in progress), January 2009.
	[I-D.zimmermann-avt-zrtp]		[I-D.zimmermann-avt-zrtp]
	Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media		Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
	Path Key Agreement for Secure RTP",		Path Key Agreement for Unicast Secure RTP",
	draft-zimmermann-avt-zrtp-17 (work in progress),		draft-zimmermann-avt-zrtp-22 (work in progress),
	January 2010.		June 2010.
	[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".
	[MBMS-SEC]		[MBMS-SEC]
	3GPP, "Security of Multimedia Broadcast/Multicast Service		3GPP, "Security of Multimedia Broadcast/Multicast Service
	(MBMS) TS 33.246".		(MBMS) TS 33.246".
	[OMA-DRM] Open Mobile Alliance, "DRM Specification 2.0".		[OMA-DRM] Open Mobile Alliance, "DRM Specification 2.0".
	skipping to change at page 10, line 10		skipping to change at page 9, line 46
	Description Protocol (SDP) Security Descriptions for Media		Description Protocol (SDP) Security Descriptions for Media
	Streams", RFC 4568, July 2006.		Streams", RFC 4568, July 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.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
			[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet,
			"Requirements and Analysis of Media Security Management
			Protocols", RFC 5479, April 2009.
			[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
			Security (DTLS) Extension to Establish Keys for the Secure
			Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
	Authors' Addresses		Authors' Addresses
	Colin Perkins		Colin Perkins
	University of Glasgow		University of Glasgow
	Department of Computing Science		Department of Computing Science
	Glasgow G12 8QQ		Glasgow G12 8QQ
	UK		UK
	Email: csp@csperkins.org		Email: csp@csperkins.org
End of changes. 14 change blocks.
	52 lines changed or deleted		40 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/