< draft-ietf-sipbrandy-rtpsec-01.txt		draft-ietf-sipbrandy-rtpsec-02.txt >
	Network Working Group J. Peterson		Network Working Group J. Peterson
	Internet-Draft Neustar		Internet-Draft Neustar
	Intended status: Best Current Practice E. Rescorla		Intended status: Best Current Practice E. Rescorla
	Expires: May 4, 2017 R. Barnes		Expires: September 14, 2017 R. Barnes
	Mozilla		Mozilla
	R. Housley		R. Housley
	Vigilsec		Vigilsec
	October 31, 2016		March 13, 2017
	Best Practices for Securing RTP Media Signaled with SIP		Best Practices for Securing RTP Media Signaled with SIP
	draft-ietf-sipbrandy-rtpsec-01.txt		draft-ietf-sipbrandy-rtpsec-02.txt
	Abstract		Abstract
	Although the Session Initiation Protocol (SIP) includes a suite of		Although the Session Initiation Protocol (SIP) includes a suite of
	security services that has been expanded by numerous specifications		security services that has been expanded by numerous specifications
	over the years, there is no single place that explains how to use SIP		over the years, there is no single place that explains how to use SIP
	to establish confidential media sessions. Additionally, existing		to establish confidential media sessions. Additionally, existing
	mechanisms have some feature gaps that need to be identified and		mechanisms have some feature gaps that need to be identified and
	resolved in order for them to address the pervasive monitoring threat		resolved in order for them to address the pervasive monitoring threat
	model. This specification describes best practices for negotiating		model. This specification describes best practices for negotiating
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 May 4, 2017.		This Internet-Draft will expire on September 14, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Security at the SIP and SDP layer . . . . . . . . . . . . . . 3		3. Security at the SIP and SDP layer . . . . . . . . . . . . . . 3
	3.1. Comprehensive Protection . . . . . . . . . . . . . . . . 3		3.1. Comprehensive Protection . . . . . . . . . . . . . . . . 3
	3.2. Opportunistic Security . . . . . . . . . . . . . . . . . 4		3.2. Opportunistic Security . . . . . . . . . . . . . . . . . 4
	4. STIR Profile for Endpoint Authentication and Verification		4. STIR Profile for Endpoint Authentication and Verification
	Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4		Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. Credentials . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. Credentials . . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. Anonymous Communications . . . . . . . . . . . . . . . . 6		4.2. Anonymous Communications . . . . . . . . . . . . . . . . 6
	4.3. Connected Identity Usage . . . . . . . . . . . . . . . . 6		4.3. Connected Identity Usage . . . . . . . . . . . . . . . . 7
	4.4. Authorization Decisions . . . . . . . . . . . . . . . . . 7		4.4. Authorization Decisions . . . . . . . . . . . . . . . . . 8
	4.4.1. Opportunistic STIR . . . . . . . . . . . . . . . . . 7
	5. Media Security Protocols . . . . . . . . . . . . . . . . . . 8		5. Media Security Protocols . . . . . . . . . . . . . . . . . . 8
	6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 8		6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 9
	7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 9		7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 9
	8. Best Current Practices . . . . . . . . . . . . . . . . . . . 9		8. Best Current Practices . . . . . . . . . . . . . . . . . . . 10
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 10		11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	12. Informative References . . . . . . . . . . . . . . . . . . . 10		12. Informative References . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The Session Initiation Protocol (SIP) [RFC3261] includes a suite of		The Session Initiation Protocol (SIP) [RFC3261] includes a suite of
	security services, ranging from Digest authentication for		security services, ranging from Digest authentication for
	authenticating entities with a shared secret, to TLS for transport		authenticating entities with a shared secret, to TLS for transport
	security, to S/MIME (optionally) for body security. SIP is		security, to S/MIME (optionally) for body security. SIP is
	frequently used to establish media sessions, in particular audio or		frequently used to establish media sessions, in particular audio or
	audiovisual sessions, which have their own security mechanisms		audiovisual sessions, which have their own security mechanisms
	available, such as Secure RTP [RFC3711]. However, the practices		available, such as Secure RTP [RFC3711]. However, the practices
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 15 ¶
	[I-D.ietf-stir-certificates]) with a subject corresponding to the		[I-D.ietf-stir-certificates]) with a subject corresponding to the
	user's identity. Such a credential could be used for trust on first		user's identity. Such a credential could be used for trust on first
	use (see [RFC7435]) by relying parties. Note that relying parties		use (see [RFC7435]) by relying parties. Note that relying parties
	SHOULD NOT use certificate revocation mechanisms or real-time		SHOULD NOT use certificate revocation mechanisms or real-time
	certificate verification systems for self-signed certificates as they		certificate verification systems for self-signed certificates as they
	will not increase confidence in the certificate.		will not increase confidence in the certificate.
	Users who wish to remain anonymous can instead generate self-signed		Users who wish to remain anonymous can instead generate self-signed
	certificates as described in Section 4.2.		certificates as described in Section 4.2.
			Generally speaking, without access to out-of-band information about
			which certificates were issued to whom, it will be very difficult for
			relying parties to ascertain whether or not the signer of a SIP
			request is genuinely an "endpoint." Even the term "endpoint" is a
			problematic one, as SIP user agents can be composed in a variety of
			architectures and may not be devices under direct user control.
			While it is possible that techniques based on certificate
			transparency [RFC6962] or similar practices could help user agents to
			recognize one another's certificates, those operational systems will
			need to ramp up with the certificate authorities that issue
			credentials to end user devices going forward.
	4.2. Anonymous Communications		4.2. Anonymous Communications
	In some cases, the identity of the initiator of a SIP session may be		In some cases, the identity of the initiator of a SIP session may be
	withheld due to user or provider policy. Per the recommendations of		withheld due to user or provider policy. Per the recommendations of
	[RFC3323], this may involve using an identity such as		[RFC3323], this may involve using an identity such as
	"anonymous@anonymous.invalid" in the identity fields of a SIP		"anonymous@anonymous.invalid" in the identity fields of a SIP
	request. [I-D.ietf-stir-rfc4474bis] does not currently permit		request. [I-D.ietf-stir-rfc4474bis] does not currently permit
	authentication services to sign for requests that supply this		authentication services to sign for requests that supply this
	identity. It does however permit signing for valid domains, such as		identity. It does however permit signing for valid domains, such as
	"anonymous@example.com," as a way of implementation an anonymization		"anonymous@example.com," as a way of implementation an anonymization
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 39 ¶
	following updates to [RFC4916] are required:		following updates to [RFC4916] are required:
	The UPDATE carrying signed SDP with a fingerprint in the backwards		The UPDATE carrying signed SDP with a fingerprint in the backwards
	direction MUST be sent during dialog establishment, following the		direction MUST be sent during dialog establishment, following the
	receipt of a PRACK after a provisional 1xx response.		receipt of a PRACK after a provisional 1xx response.
	For use with this STIR Profile for media confidentiality, the UAS		For use with this STIR Profile for media confidentiality, the UAS
	that responds to the INVITE request MUST act as an authentication		that responds to the INVITE request MUST act as an authentication
	service for the UPDATE sent in the backwards direction.		service for the UPDATE sent in the backwards direction.
			The text in RFC4916 Section 4.4.1 regarding the receipt at a UAC
			of error codes 428, 436, 437 and 438 in response to a mid-dialog
			request RECOMMENDS treating the dialog as terminated.
			[I-D.ietf-stir-rfc4474bis] allows the retransmission of requests
			with repairable error conditions (see section 6.1.1) in a way that
			can override that SHOULD in RFC4916. In particular, an
			authentication service MAY retry a mid-dialog as
			[I-D.ietf-stir-rfc4474bis] allows rather than treating the dialog
			as terminated, though note that only one such retry is permitted.
			The examples in RFC4916 are based on the original RFC4474, and
			will not match signatures using [I-D.ietf-stir-rfc4474bis].
	The use of RFC4916 has some further interactions with ICE; see		The use of RFC4916 has some further interactions with ICE; see
	Section 7.		Section 7.
	4.4. Authorization Decisions		4.4. Authorization Decisions
	[I-D.ietf-stir-rfc4474bis] grants STIR verification services a great		[I-D.ietf-stir-rfc4474bis] grants STIR verification services a great
	deal of latitude when making authorization decisions based on the		deal of latitude when making authorization decisions based on the
	presence of the Identity header field. It is largely a matter of		presence of the Identity header field. It is largely a matter of
	local policy whether an endpoint rejects a call based on absence of		local policy whether an endpoint rejects a call based on absence of
	an Identity header field, or even the presence of a header that fails		an Identity header field, or even the presence of a header that fails
	an integrity check against the request.		an integrity check against the request.
	For the purposes of this STIR profile,		For this profile, however, a compliant verification service that
			receives a dialog-forming SIP request containing an Identity header
	4.4.1. Opportunistic STIR		with a PASSporT type of "msec", after validating the request per the
			steps described in [I-D.ietf-stir-rfc4474bis] Section 6.2, MUST
			reject the request if there is any failure in that validation process
			with the appropriate status code per Section 6.2.2. If the request
			is valid, then if a terminating user accepts the request, it MUST
			then follow the steps in Section 4.3 to act as an authentication
			service and send a signed request with the "msec" PASSPorT type in
			its Identity header as well, in order to enable end-to-end
			bidirectional confidentiality.
	When the PASSporT object used by STIR contains the "mkey" attribute,		For the purposes of this profile, the "msec" PASSporT type can be
	which protects the "a=fingerprint" attributes of SDP, STIR validation		used by authentication services in one of two ways: as a mandatory
	will consequently fail when those attributes have been removed or		request for media security, or as a merely opportunistic request for
	altered in transit. It would however be possible to convey with a		media security. As any verification service that receives an
	PASSporT attribute that the sender of an Identity-protected request		Identity header in a SIP request with an unrecognized PASSporT type
	is using security on a best-effort basis, and that the originator of		will simply ignore that Identity header, an authentication service
	the call would still like the call to connect even if it is not		will know whether or not the terminating side supports "msec" based
	possible to establish end-to-end confidentiality. In effect, this		on whether or not its user agent receives a signed request in the
	would allow this profile of STIR for media confidentiality to behave		backwards direction per Section 4.3. If no such requests are
	opportunistically.		received, the UA may do one or two things: shut down the dialog, if
			the policy of the UA requires that "msec" be supported by the
			terminating side for this dialog; or, if policy permits, allow the
			dialog to continue without media security.
	5. Media Security Protocols		5. Media Security Protocols
	As there are several ways to negotiate media security with SDP, any		As there are several ways to negotiate media security with SDP, any
	of which might be used with either opportunistic or comprehensive		of which might be used with either opportunistic or comprehensive
	protection, further guidance to implementers is needed. In		protection, further guidance to implementers is needed. In
	[I-D.johnston-dispatch-osrtp], opportunistic approaches considered		[I-D.johnston-dispatch-osrtp], opportunistic approaches considered
	include DTLS-SRTP, security descriptions [RFC4568], and ZRTP		include DTLS-SRTP, security descriptions [RFC4568], and ZRTP
	[RFC6189].		[RFC6189].
	skipping to change at page 9, line 41 ¶		skipping to change at page 10, line 32 ¶
	8. Best Current Practices		8. Best Current Practices
	The following are the best practices for SIP user agents to provide		The following are the best practices for SIP user agents to provide
	media confidentiality for SIP sessions.		media confidentiality for SIP sessions.
	Implementations MUST support the STIR endpoint profile given in		Implementations MUST support the STIR endpoint profile given in
	Section 4, and signal that in PASSporT with the "msec" header		Section 4, and signal that in PASSporT with the "msec" header
	element.		element.
			Implementations MUST follow the authorization decision behavior in
			Section 4.4.
	Implementations MUST support DTLS-SRTP for key-management, as		Implementations MUST support DTLS-SRTP for key-management, as
	described in Section 5.		described in Section 5.
	Implementations MUST support the ICE, and the STUN consent freshness		Implementations MUST support the ICE, and the STUN consent freshness
	mechanism, as specified in Section 7.		mechanism, as specified in Section 7.
	9. Acknowledgments		9. Acknowledgments
	We would like to thank Adam Roach, Andrew Hutton, and Ben Campbell		We would like to thank Adam Roach, Andrew Hutton, and Ben Campbell
	for contributions to this problem statement and framework.		for contributions to this problem statement and framework.
	skipping to change at page 10, line 28 ¶		skipping to change at page 11, line 23 ¶
	This document describes the security features that provide media		This document describes the security features that provide media
	sessions established with SIP with confidentiality, integrity, and		sessions established with SIP with confidentiality, integrity, and
	authentication.		authentication.
	12. Informative References		12. Informative References
	[I-D.ietf-ice-rfc5245bis]		[I-D.ietf-ice-rfc5245bis]
	Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive		Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
	Connectivity Establishment (ICE): A Protocol for Network		Connectivity Establishment (ICE): A Protocol for Network
	Address Translator (NAT) Traversal", draft-ietf-ice-		Address Translator (NAT) Traversal", draft-ietf-ice-
	rfc5245bis-04 (work in progress), June 2016.		rfc5245bis-08 (work in progress), December 2016.
	[I-D.ietf-mmusic-trickle-ice-sip]		[I-D.ietf-mmusic-trickle-ice-sip]
	Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A		Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
	Session Initiation Protocol (SIP) usage for Trickle ICE",		Session Initiation Protocol (SIP) usage for Trickle ICE",
	draft-ietf-mmusic-trickle-ice-sip-05 (work in progress),		draft-ietf-mmusic-trickle-ice-sip-07 (work in progress),
	August 2016.		March 2017.
	[I-D.ietf-stir-certificates]		[I-D.ietf-stir-certificates]
	Peterson, J. and S. Turner, "Secure Telephone Identity		Peterson, J. and S. Turner, "Secure Telephone Identity
	Credentials: Certificates", draft-ietf-stir-		Credentials: Certificates", draft-ietf-stir-
	certificates-10 (work in progress), October 2016.		certificates-11 (work in progress), October 2016.
	[I-D.ietf-stir-passport]		[I-D.ietf-stir-passport]
	Wendt, C. and J. Peterson, "Personal Assertion Token		Wendt, C. and J. Peterson, "Personal Assertion Token
	(PASSporT)", draft-ietf-stir-passport-10 (work in		(PASSporT)", draft-ietf-stir-passport-11 (work in
	progress), October 2016.		progress), February 2017.
	[I-D.ietf-stir-rfc4474bis]		[I-D.ietf-stir-rfc4474bis]
	Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,		Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
	"Authenticated Identity Management in the Session		"Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-14		Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
	(work in progress), October 2016.		(work in progress), February 2017.
	[I-D.johnston-dispatch-osrtp]		[I-D.johnston-dispatch-osrtp]
	Johnston, A., Ph.D., D., Hutton, A., Liess, L., and T.		Johnston, A., Ph.D., D., Hutton, A., Liess, L., and T.
	Stach, "An Opportunistic Approach for Secure Real-time		Stach, "An Opportunistic Approach for Secure Real-time
	Transport Protocol (OSRTP)", draft-johnston-dispatch-		Transport Protocol (OSRTP)", draft-johnston-dispatch-
	osrtp-02 (work in progress), February 2016.		osrtp-02 (work in progress), February 2016.
	[I-D.kaplan-mmusic-best-effort-srtp]		[I-D.kaplan-mmusic-best-effort-srtp]
	Audet, F. and H. Kaplan, "Session Description Protocol		Audet, F. and H. Kaplan, "Session Description Protocol
	(SDP) Offer/Answer Negotiation For Best-Effort Secure		(SDP) Offer/Answer Negotiation For Best-Effort Secure
	skipping to change at page 12, line 36 ¶		skipping to change at page 13, line 32 ¶
	[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:		[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
	Media Path Key Agreement for Unicast Secure RTP",		Media Path Key Agreement for Unicast Secure RTP",
	RFC 6189, DOI 10.17487/RFC6189, April 2011,		RFC 6189, DOI 10.17487/RFC6189, April 2011,
	<http://www.rfc-editor.org/info/rfc6189>.		<http://www.rfc-editor.org/info/rfc6189>.
	[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words		[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
	for Use in RFCs to Indicate Requirement Levels", RFC 6919,		for Use in RFCs to Indicate Requirement Levels", RFC 6919,
	DOI 10.17487/RFC6919, April 2013,		DOI 10.17487/RFC6919, April 2013,
	<http://www.rfc-editor.org/info/rfc6919>.		<http://www.rfc-editor.org/info/rfc6919>.
			[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
			Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
			<http://www.rfc-editor.org/info/rfc6962>.
	[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor,		[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor,
	"An Architecture for Media Recording Using the Session		"An Architecture for Media Recording Using the Session
	Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May		Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May
	2014, <http://www.rfc-editor.org/info/rfc7245>.		2014, <http://www.rfc-editor.org/info/rfc7245>.
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
	2014, <http://www.rfc-editor.org/info/rfc7258>.		2014, <http://www.rfc-editor.org/info/rfc7258>.
	[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection		[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
End of changes. 20 change blocks.
	35 lines changed or deleted		77 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/