< draft-ietf-sipbrandy-rtpsec-06.txt		draft-ietf-sipbrandy-rtpsec-07.txt >
	Network Working Group J. Peterson		Network Working Group J. Peterson
	Internet-Draft Neustar		Internet-Draft Neustar
	Intended status: Best Current Practice R. Barnes		Updates: 4916 (if approved) R. Barnes
	Expires: April 18, 2019 Mozilla		Intended status: Best Current Practice Cisco
	R. Housley		Expires: August 5, 2019 R. Housley
	Vigil Security		Vigil Security
	October 15, 2018		February 01, 2019
	Best Practices for Securing RTP Media Signaled with SIP		Best Practices for Securing RTP Media Signaled with SIP
	draft-ietf-sipbrandy-rtpsec-06		draft-ietf-sipbrandy-rtpsec-07
	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 42 ¶		skipping to change at page 1, line 42 ¶
	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 April 18, 2019.		This Internet-Draft will expire on August 5, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 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 3, line 27 ¶		skipping to change at page 3, line 27 ¶
	solutions, and specifies solutions to address them.		solutions, and specifies solutions to address them.
	Various specifications that user agents must implement to support		Various specifications that user agents must implement to support
	media confidentiality are given in the sections below; a summary of		media confidentiality are given in the sections below; a summary of
	the best current practices appears in Section 8.		the best current practices appears in Section 8.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 RFC 2119 [RFC2119] and RFC 8174 [RFC8174] when, and only when,		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	they appear in all capitals, as shown here.		capitals, as shown here.
	3. Security at the SIP and SDP layer		3. Security at the SIP and SDP layer
	There are two approaches to providing confidentiality for media		There are two approaches to providing confidentiality for media
	sessions set up with SIP: comprehensive protection and opportunistic		sessions set up with SIP: comprehensive protection and opportunistic
	security (as defined in [RFC7435]).		security (as defined in [RFC7435]).
	3.1. Comprehensive Protection		3.1. Comprehensive Protection
	Comprehensive protection for media sessions established by SIP		Comprehensive protection for media sessions established by SIP
	skipping to change at page 5, line 16 ¶		skipping to change at page 5, line 16 ¶
	implemented at an intermediary rather than an endpoint, this		implemented at an intermediary rather than an endpoint, this
	introduces the possibility that the intermediary could act as a man		introduces the possibility that the intermediary could act as a man
	in the middle, altering key fingerprints. As this attack is not in		in the middle, altering key fingerprints. As this attack is not in
	STIR's core threat model, which focuses on impersonation rather than		STIR's core threat model, which focuses on impersonation rather than
	man-in-the-middle attacks, STIR offers no specific protections		man-in-the-middle attacks, STIR offers no specific protections
	against such interference.		against such interference.
	The SIPBRANDY deployment profile of STIR for media confidentiality		The SIPBRANDY deployment profile of STIR for media confidentiality
	thus shifts these responsibilities to the endpoints rather than the		thus shifts these responsibilities to the endpoints rather than the
	intermediaries. While intermediaries MAY provide the verification		intermediaries. While intermediaries MAY provide the verification
	service function of STIR for SIPBRANDY transactions, intermediaries		service function of STIR for SIPBRANDY transactions, the verification
	supporting this specification MUST NOT block or otherwise redirects		needs to be repeated at the endpoint obtain the end-to-end assurance.
	calls if they do not trust the signing credential. The SIPBRANDY		Intermediaries supporting this specification MUST NOT block or
	profile is based on an end-to-end trust model, so it is up to the		otherwise redirects calls if they do not trust the signing
	endpoints to determine if they support signing credentials, not		credential. The SIPBRANDY profile is based on an end-to-end trust
	intermediaries.		model, so it is up to the endpoints to determine if they support
			signing credentials, not intermediaries.
	In order to be compliant with best practices for SIP media		In order to be compliant with best practices for SIP media
	confidentiality with comprehensive protection, user agent		confidentiality with comprehensive protection, user agent
	implementations MUST implement both the authentication service and		implementations MUST implement both the authentication service and
	verification service roles described in [RFC8224]. STIR		verification service roles described in [RFC8224]. STIR
	authentication services MUST signal their compliance with this		authentication services MUST signal their compliance with this
	specification by adding the "msec" header element defined in this		specification by adding the "msec" header element defined in this
	specification to the PASSporT header. Implementations MUST provide		specification to the PASSporT header. Implementations MUST provide
	key fingerprints in SDP and the appropriate signatures over them per		key fingerprints in SDP and the appropriate signatures over them per
	[RFC8225].		[RFC8225].
	skipping to change at page 5, line 45 ¶		skipping to change at page 5, line 46 ¶
	the fingerprint of an appropriate key (see Section 4.1).		the fingerprint of an appropriate key (see Section 4.1).
	4.1. Credentials		4.1. Credentials
	In order to implement the authentication service function in the user		In order to implement the authentication service function in the user
	agent, SIP endpoints will need to acquire the credentials needed to		agent, SIP endpoints will need to acquire the credentials needed to
	sign for their own identity. That identity is typically carried in		sign for their own identity. That identity is typically carried in
	the From header field of a SIP request, and either contains a		the From header field of a SIP request, and either contains a
	greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone		greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone
	number, which can appear in a variety of ways (e.g.		number, which can appear in a variety of ways (e.g.
	"sip:+17004561212@example.com;user=phone"). [RFC8224] Section 8		"sip:+17004561212@example.com;user=phone"). Section 8 of [RFC8224]
	contains guidance for separating the two, and determining what sort		contains guidance for separating the two, and determining what sort
	of credential is needed to sign for each.		of credential is needed to sign for each.
	To date, few commercial certificate authorities issue certificates		To date, few commercial certification authorities (CAs) issue
	for SIP URIs or telephone numbers; though work is ongoing on systems		certificates for SIP URIs or telephone numbers; though work is
	for this purpose (such as [I-D.ietf-acme-telephone]) it is not mature		ongoing on systems for this purpose (such as
	enough to be recommended as a best practice. This is one reason why		[I-D.ietf-acme-telephone]) it is not mature enough to be recommended
	the STIR standard is architected to permit intermediaries to act as		as a best practice. This is one reason why the STIR standard is
	an authentication service on behalf of an entire domain, just as in		architected to permit intermediaries to act as an authentication
	SIP an proxy server can provide domain-level SIP service. While		service on behalf of an entire domain, just as in SIP an proxy server
	certificate authorities that offered proof-of-possession certificates		can provide domain-level SIP service. While CAs that offer proof-of-
	similar to those used in the email world could be offered for SIP,		possession certificates similar to those used in the email world
	either for greenfield identifiers or for telephone numbers, this		could be offered for SIP, either for greenfield identifiers or for
	specification does not require their use.		telephone numbers, this specification does not require their use.
	For users who do not possess such certificates, DTLS-SRTP [RFC5763]		For users who do not possess such certificates, DTLS-SRTP [RFC5763]
	permits the use of self-signed keys. This profile of STIR therefore		permits the use of self-signed keys. This profile of STIR employs
	relaxes the authority requirements of [RFC8224] to allow the use of		more relaxed authority requirements of [RFC8224] to allow the use of
	self-signed keys for authentication services that are composed with		self-signed keys for authentication services that are composed with
	user agents, by generating a certificate (per the guidance of		user agents, by generating a certificate (per the guidance of
	[RFC8226]) with a subject corresponding to the user's identity. Such		[RFC8226]) with a subject corresponding to the user's identity. To
	a credential could be used for trust on first use (see [RFC7435]) by		obtain comprehensive protection with a self-signed certificate, some
	relying parties. Note that relying parties SHOULD NOT use		out-of-band verification is needed as well. Such a credential could
	certificate revocation mechanisms or real-time certificate		be used for trust on first use (see [RFC7435]) by relying parties.
	verification systems for self-signed certificates as they will not		Note that relying parties SHOULD NOT use certificate revocation
	increase confidence in the certificate.		mechanisms or real-time certificate verification systems for self-
			signed certificates as they 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		Generally speaking, without access to out-of-band information about
	which certificates were issued to whom, it will be very difficult for		which certificates were issued to whom, it will be very difficult for
	relying parties to ascertain whether or not the signer of a SIP		relying parties to ascertain whether or not the signer of a SIP
	request is genuinely an "endpoint." Even the term "endpoint" is a		request is genuinely an "endpoint." Even the term "endpoint" is a
	problematic one, as SIP user agents can be composed in a variety of		problematic one, as SIP user agents can be composed in a variety of
	architectures and may not be devices under direct user control.		architectures and may not be devices under direct user control.
	skipping to change at page 7, line 51 ¶		skipping to change at page 8, line 5 ¶
	[RFC4916] are required:		[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		The text in Section 4.4.1 of [RFC4916] regarding the receipt at a
	of error codes 428, 436, 437 and 438 in response to a mid-dialog		UAC of error codes 428, 436, 437 and 438 in response to a mid-
	request RECOMMENDS treating the dialog as terminated. [RFC8224]		dialog request RECOMMENDS treating the dialog as terminated.
	allows the retransmission of requests with repairable error		[RFC8224] allows the retransmission of requests with repairable
	conditions (see section 6.1.1) in a way that can override that		error conditions (see Section 6.1.1) in a way that can override
	SHOULD in RFC4916. In particular, an authentication service MAY		that SHOULD in [RFC4916]. In particular, an authentication
	retry a mid-dialog as [RFC8224] allows rather than treating the		service MAY retry a mid-dialog as [RFC8224] allows rather than
	dialog as terminated, though note that only one such retry is		treating the dialog as terminated, though note that only one such
	permitted.		retry is permitted.
	The examples in RFC4916 are based on the original RFC4474, and		The examples in [RFC4916] are based on the original [RFC4916], and
	will not match signatures using [RFC8224].		will not match signatures using [RFC4474].
	Future work may be done to revise RFC4916 for STIR; that work should		Future work may be done to revise [RFC4916] for STIR; that work
	take into account any impacts on the profile described in this		should take into account any impacts on the profile described in this
	document. The use of RFC4916 has some further interactions with ICE;		document. The use of [RFC4916] has some further interactions with
	see Section 7.		ICE; see Section 7.
	4.4. Authorization Decisions		4.4. Authorization Decisions
	[RFC8224] grants STIR verification services a great deal of latitude		[RFC8224] grants STIR verification services a great deal of latitude
	when making authorization decisions based on the presence of the		when making authorization decisions based on the presence of the
	Identity header field. It is largely a matter of local policy		Identity header field. It is largely a matter of local policy
	whether an endpoint rejects a call based on absence of an Identity		whether an endpoint rejects a call based on absence of an Identity
	header field, or even the presence of a header that fails an		header field, or even the presence of a header that fails an
	integrity check against the request.		integrity check against the request.
	For this profile, however, a compliant verification service that		For this profile, however, a compliant verification service that
	receives a dialog-forming SIP request containing an Identity header		receives a dialog-forming SIP request containing an Identity header
	with a PASSporT type of "msec", after validating the request per the		with a PASSporT type of "msec", after validating the request per the
	steps described in [RFC8224] Section 6.2, MUST reject the request if		steps described in Section 6.2 of [RFC8224], MUST reject the request
	there is any failure in that validation process with the appropriate		if there is any failure in that validation process with the
	status code per Section 6.2.2. If the request is valid, then if a		appropriate status code per Section 6.2.2. If the request is valid,
	terminating user accepts the request, it MUST then follow the steps		then if a terminating user accepts the request, it MUST then follow
	in Section 4.3 to act as an authentication service and send a signed		the steps in Section 4.3 to act as an authentication service and send
	request with the "msec" PASSPorT type in its Identity header as well,		a signed request with the "msec" PASSPorT type in its Identity header
	in order to enable end-to-end bidirectional confidentiality.		as well, in order to enable end-to-end bidirectional confidentiality.
	For the purposes of this profile, the "msec" PASSporT type can be		For the purposes of this profile, the "msec" PASSporT type can be
	used by authentication services in one of two ways: as a mandatory		used by authentication services in one of two ways: as a mandatory
	request for media security, or as a merely opportunistic request for		request for media security, or as a merely opportunistic request for
	media security. As any verification service that receives an		media security. As any verification service that receives an
	Identity header in a SIP request with an unrecognized PASSporT type		Identity header in a SIP request with an unrecognized PASSporT type
	will simply ignore that Identity header, an authentication service		will simply ignore that Identity header, an authentication service
	will know whether or not the terminating side supports "msec" based		will know whether or not the terminating side supports "msec" based
	on whether or not its user agent receives a signed request in the		on whether or not its user agent receives a signed request in the
	backwards direction per Section 4.3. If no such requests are		backwards direction per Section 4.3. If no such requests are
	received, the UA may do one or two things: shut down the dialog, if		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		the policy of the UA requires that "msec" be supported by the
	terminating side for this dialog; or, if policy permits, allow the		terminating side for this dialog; or, if policy permits (e.g. an
	dialog to continue without media security.		explicit acceptance by the user), 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 13, line 46 ¶		skipping to change at page 13, line 46 ¶
	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
	Real-Time Transport Protocol", draft-kaplan-mmusic-best-		Real-Time Transport Protocol", draft-kaplan-mmusic-best-
	effort-srtp-01 (work in progress), October 2006.		effort-srtp-01 (work in progress), October 2006.
			[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
			Authenticated Identity Management in the Session
			Initiation Protocol (SIP)", RFC 4474,
			DOI 10.17487/RFC4474, August 2006,
			<https://www.rfc-editor.org/info/rfc4474>.
	[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,
	<https://www.rfc-editor.org/info/rfc6189>.		<https://www.rfc-editor.org/info/rfc6189>.
	[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate		[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
	Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,		Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
	<https://www.rfc-editor.org/info/rfc6962>.		<https://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,
	skipping to change at page 14, line 26 ¶		skipping to change at page 14, line 31 ¶
	December 2014, <https://www.rfc-editor.org/info/rfc7435>.		December 2014, <https://www.rfc-editor.org/info/rfc7435>.
	Authors' Addresses		Authors' Addresses
	Jon Peterson		Jon Peterson
	Neustar, Inc.		Neustar, Inc.
	Email: jon.peterson@team.neustar		Email: jon.peterson@team.neustar
	Richard Barnes		Richard Barnes
	Mozilla		Cisco
	Email: rlb@ipv.sx		Email: rlb@ipv.sx
	Russ Housley		Russ Housley
	Vigil Security, LLC		Vigil Security, LLC
	Email: housley@vigilsec.com		Email: housley@vigilsec.com
End of changes. 18 change blocks.
	61 lines changed or deleted		71 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/