draft-ietf-avt-srtp-not-mandatory-06.txt		draft-ietf-avt-srtp-not-mandatory-07.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: January 1, 2011 Ericsson		Expires: January 2, 2011 Ericsson
	June 30, 2010		July 1, 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-06.txt		draft-ietf-avt-srtp-not-mandatory-07.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
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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 January 1, 2011.		This Internet-Draft will expire on January 2, 2011.
	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 5, line 46		skipping to change at page 5, line 46
	solutions have been developed in this space:		solutions have been developed in this space:
	o A common use case for RTP is probably point-to-point voice calls		o A common use case for RTP is probably point-to-point voice calls
	or centralised group conferences, negotiated using SIP [RFC3261]		or centralised group conferences, negotiated using SIP [RFC3261]
	with the SDP offer/answer model [RFC3264], operating on a trusted		with the SDP offer/answer model [RFC3264], operating on a trusted
	infrastructure. In such environments, SDP security descriptions		infrastructure. In such environments, SDP security descriptions
	[RFC4568] or the MIKEY [RFC4567] protocol are appropriate keying		[RFC4568] or the MIKEY [RFC4567] protocol are appropriate keying
	mechanisms, piggybacked onto the SDP [RFC4566] exchange. The		mechanisms, piggybacked onto the SDP [RFC4566] exchange. The
	infrastructure may be secured by protecting the SIP exchange using		infrastructure may be secured by protecting the SIP exchange using
	TLS or S/MIME, for example [RFC3261]. Protocols such as DTLS		TLS or S/MIME, for example [RFC3261]. Protocols such as DTLS
	[RFC5764] or ZRTP [I-D.zimmermann-avt-zrtp] may also be		[RFC5764] or ZRTP [I-D.zimmermann-avt-zrtp] are also appropriate
	appropriate in such environments.		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 [RFC5764] or ZRTP [I-D.zimmermann-avt-zrtp]
	are useful here.		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
End of changes. 4 change blocks.
	6 lines changed or deleted		6 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/