draft-ietf-sipbrandy-osrtp-03.txt		draft-ietf-sipbrandy-osrtp-04.txt
	SIPBRANDY Working Group A. Johnston		SIPBRANDY Working Group A. Johnston
	Internet-Draft Rowan University		Internet-Draft Rowan University
	Intended status: Informational B. Aboba		Intended status: Informational B. Aboba
	Expires: March 22, 2018 Microsoft		Expires: September 16, 2018 Microsoft
	A. Hutton		A. Hutton
	Unify / Atos		Atos
	R. Jesske		R. Jesske
	Deutsche Telekom		Deutsche Telekom
	T. Stach		T. Stach
	Unaffiliated		Unaffiliated
	September 18, 2017		March 15, 2018
	An Opportunistic Approach for Secure Real-time Transport Protocol		An Opportunistic Approach for Secure Real-time Transport Protocol
	(OSRTP)		(OSRTP)
	draft-ietf-sipbrandy-osrtp-03		draft-ietf-sipbrandy-osrtp-04
	Abstract		Abstract
	Opportunistic Secure Real-time Transport Protocol (OSRTP) is an		Opportunistic Secure Real-time Transport Protocol (OSRTP) is an
	implementation of the Opportunistic Security mechanism, as defined in		implementation of the Opportunistic Security mechanism, as defined in
	RFC 7435, applied to Real-time Transport Protocol (RTP). OSRTP		RFC 7435, applied to Real-time Transport Protocol (RTP). OSRTP
	allows encrypted media to be used in environments where support for		allows encrypted media to be used in environments where support for
	encryption is not known in advance, and not required. OSRTP does not		encryption is not known in advance, and not required. OSRTP does not
	require SDP extensions or features and is fully backwards compatible		require SDP extensions or features and is fully backwards compatible
	with existing implementations using encrypted and authenticated media		with existing implementations using encrypted and authenticated media
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 March 22, 2018.		This Internet-Draft will expire on September 16, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	skipping to change at page 4, line 39 ¶		skipping to change at page 4, line 39 ¶
	particular SRTP key agreement approach are relaxed when that key		particular SRTP key agreement approach are relaxed when that key
	agreement is used with OSRTP. For example:		agreement is used with OSRTP. For example:
	For DTLS-SRTP key agreement [RFC5763], an authenticated signaling		For DTLS-SRTP key agreement [RFC5763], an authenticated signaling
	channel does not need to be used with OSRTP if it is not		channel does not need to be used with OSRTP if it is not
	available.		available.
	For SDP Security Descriptions key agreement [RFC4568], an		For SDP Security Descriptions key agreement [RFC4568], an
	authenticated signaling channel does not need to be used with		authenticated signaling channel does not need to be used with
	OSRTP if it is not available, although an encrypted signaling		OSRTP if it is not available, although an encrypted signaling
	channel must still be used. The use of SDP Security Descriptions		channel must still be used.
	using the RTP/AVP profile is defined in
	[I-D.mmusic-opportunistic-negotiation].
	For ZRTP key agreement [RFC6189], the security considerations are		For ZRTP key agreement [RFC6189], the security considerations are
	unchanged, since ZRTP does not rely on the security of the		unchanged, since ZRTP does not rely on the security of the
	signaling channel.		signaling channel.
	As discussed in [RFC7435], OSRTP is used in cases where support for		As discussed in [RFC7435], OSRTP is used in cases where support for
	encryption by the other party is not known in advance, and not		encryption by the other party is not known in advance, and not
	required. For cases where it is known that the other party supports		required. For cases where it is known that the other party supports
	SRTP or SRTP needs to be used, OSRTP MUST NOT be used. Instead, a		SRTP or SRTP needs to be used, OSRTP MUST NOT be used. Instead, a
	secure profile of RTP is used in the offer.		secure profile of RTP is used in the offer.
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	who is greatly missed in our community. His work on improving		who is greatly missed in our community. His work on improving
	security in SIP and RTP provided the foundation for this work.		security in SIP and RTP provided the foundation for this work.
	Thanks to Eric Rescorla, Martin Thomson, and Richard Barnes for their		Thanks to Eric Rescorla, Martin Thomson, and Richard Barnes for their
	comments.		comments.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.mmusic-opportunistic-negotiation]
	Hutton, A., Jesske, R., Johnston, A., Salgueiro, G., and
	B. Aboba, "Negotiating SRTP and RTCP Feedback using the
	RTP/AVP Profile", draft-mmusic-opportunistic-
	negotiation-00 (work in progress), June 2017.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model		[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
	with Session Description Protocol (SDP)", RFC 3264,		with Session Description Protocol (SDP)", RFC 3264,
	DOI 10.17487/RFC3264, June 2002,		DOI 10.17487/RFC3264, June 2002,
	<https://www.rfc-editor.org/info/rfc3264>.		<https://www.rfc-editor.org/info/rfc3264>.
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 13 ¶
	Email: alan.b.johnston@gmail.com		Email: alan.b.johnston@gmail.com
	Bernard Aboba		Bernard Aboba
	Microsoft		Microsoft
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	USA		USA
	Email: bernard.aboba@gmail.com		Email: bernard.aboba@gmail.com
	Andrew Hutton		Andrew Hutton
	Unify / Atos		Atos
	4 Triton Square		4 Triton Square
	London NW1 3HG		London NW1 3HG
	UK		UK
	Email: andrew.hutton@atos.net		Email: andrew.hutton@atos.net
	Roland Jesske		Roland Jesske
	Deutsche Telekom		Deutsche Telekom
	Heinrich-Hertz-Strasse 3-7		Heinrich-Hertz-Strasse 3-7
	Darmstadt 64295		Darmstadt 64295
End of changes. 9 change blocks.
	16 lines changed or deleted		8 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/