< draft-ietf-sipbrandy-rtpsec-03.txt		draft-ietf-sipbrandy-rtpsec-04.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 3, 2018 R. Barnes		Expires: November 2, 2018 Mozilla
	Mozilla		R. Barnes
			Cisco
	R. Housley		R. Housley
	Vigilsec		Vigil Security
	October 30, 2017		May 1, 2018
	Best Practices for Securing RTP Media Signaled with SIP		Best Practices for Securing RTP Media Signaled with SIP
	draft-ietf-sipbrandy-rtpsec-03.txt		draft-ietf-sipbrandy-rtpsec-04.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 44 ¶
	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 May 3, 2018.		This Internet-Draft will expire on November 2, 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 2, line 28 ¶		skipping to change at page 2, line 33 ¶
	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 . . . . . . . . . . . . . . . . 7		4.3. Connected Identity Usage . . . . . . . . . . . . . . . . 7
	4.4. Authorization Decisions . . . . . . . . . . . . . . . . . 8		4.4. Authorization Decisions . . . . . . . . . . . . . . . . . 8
	5. Media Security Protocols . . . . . . . . . . . . . . . . . . 8		5. Media Security Protocols . . . . . . . . . . . . . . . . . . 9
	6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 9		6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 9
	7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 9		7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 10
	8. Best Current Practices . . . . . . . . . . . . . . . . . . . 10		8. Best Current Practices . . . . . . . . . . . . . . . . . . . 10
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 11		11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	12. Informative References . . . . . . . . . . . . . . . . . . . 11		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
			12.1. Normative References . . . . . . . . . . . . . . . . . . 11
			12.2. Informative References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		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
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 44 ¶
	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
	requires the interaction of three protocols: SIP, the Session		requires the interaction of three protocols: SIP, the Session
	Description Protocol (SDP), and the Real-time Protocol, in particular		Description Protocol (SDP) [RFC4566], and the Real-time Protocol
	its secure profile SRTP. Broadly, it is the responsibility of SIP to		(RTP) [RFC3550], in particular its secure profile Secure RTP (SRTP)
	provide integrity protection for the media keying attributes conveyed		[RFC3711]. Broadly, it is the responsibility of SIP to provide
	by SDP, and those attributes will in turn identify the keys used by		integrity protection for the media keying attributes conveyed by SDP,
	endpoints in the RTP media session(s) that SDP negotiates. In that		and those attributes will in turn identify the keys used by endpoints
	way, once SIP and SDP have exchanged the necessary information to		in the RTP media session(s) that SDP negotiates. Note that this
	initiate a session, media endpoints will have a strong assurance that		framework does not apply to keys that also require confidentiality
	the keys they exchange have not been tampered with by third parties,		protection in the signaling layer, such as the SDP "k=" line, which
	and that end-to-end confidentiality is available.		MUST NOT be used in conjunction with this profile. In that way, once
			SIP and SDP have exchanged the necessary information to initiate a
			session, media endpoints will have a strong assurance that the keys
			they exchange have not been tampered with by third parties, and that
			end-to-end confidentiality is available.
	Our current target mechanism for establishing the identity of the		To establishing the identity of the endpoints of a SIP session, this
	endpoints of a SIP session is the use of STIR		specification uses STIR [RFC8224]. The STIR Identity header has been
	[I-D.ietf-stir-rfc4474bis]. The STIR Identity header has been
	designed to prevent a class of impersonation attacks that are		designed to prevent a class of impersonation attacks that are
	commonly used in robocalling, voicemail hacking, and related threats.		commonly used in robocalling, voicemail hacking, and related threats.
	STIR generates a signature over certain features of SIP requests,		STIR generates a signature over certain features of SIP requests,
	including header field values that contain an identity for the		including header field values that contain an identity for the
	originator of the request, such as the From header field or P-		originator of the request, such as the From header field or P-
	Asserted-Identity field, and also over the media keys in SDP if they		Asserted-Identity field, and also over the media keys in SDP if they
	are present. As currently defined, STIR only provides a signature		are present. As currently defined, STIR only provides a signature
	over the "a=fingerprint" attribute, which is a key fingerprint		over the "a=fingerprint" attribute, which is a key fingerprint
	utilized by DTLS-SRTP [RFC5763]; consequently, STIR only offers		utilized by DTLS-SRTP [RFC5763]; consequently, STIR only offers
	comprehensive protection for SIP sessions, in concert with SDP and		comprehensive protection for SIP sessions, in concert with SDP and
	SRTP, when DTLS-SRTP is the media security service. The underlying		SRTP, when DTLS-SRTP is the media security service. The underlying
	PASSporT [I-D.ietf-stir-passport] object used by STIR is extensible,		PASSporT [RFC8225] object used by STIR is extensible, however, and it
	however, and it would be possible to provide signatures over other		would be possible to provide signatures over other SDP attributes
	SDP attributes that contain alternate keying material. A profile for		that contain alternate keying material. A profile for using STIR to
	using STIR to provide media confidentiality is given in Section 4.		provide media confidentiality is given in Section 4.
	3.2. Opportunistic Security		3.2. Opportunistic Security
	Work is already underway on defining approaches to opportunistic		Work is already underway on defining approaches to opportunistic
	media security for SIP in [I-D.johnston-dispatch-osrtp], which builds		media security for SIP in [I-D.johnston-dispatch-osrtp], which builds
	on the prior efforts of [I-D.kaplan-mmusic-best-effort-srtp]. The		on the prior efforts of [I-D.kaplan-mmusic-best-effort-srtp]. The
	major protocol change proposed by that draft is to signal the use of		major protocol change proposed by that specification is to signal the
	opportunistic encryption by negotiating the AVP profile in SDP,		use of opportunistic encryption by negotiating the AVP profile in
	rather than the SAVP profile (as specified in [RFC3711]) that would		SDP, rather than the SAVP profile (as specified in [RFC3711]) that
	ordinarily be used when negotiating SRTP.		would ordinarily be used when negotiating SRTP.
	Opportunistic encryption approaches typically have no integrity		Opportunistic encryption approaches typically have no integrity
	protection for the keying material in SDP. Sending SIP over TLS hop-		protection for the keying material in SDP. Sending SIP over TLS hop-
	by-hop between user agents and any intermediaries will reduce the		by-hop between user agents and any intermediaries will reduce the
	prospect that active attackers can alter keys for session requests on		prospect that active attackers can alter keys for session requests on
	the wire. However, opportunistic confidentiality for media will		the wire. However, opportunistic confidentiality for media will
	prevent passive attacks of the form most common in the threat of		prevent passive attacks of the form most common in the threat of
	pervasive monitoring.		pervasive monitoring.
	4. STIR Profile for Endpoint Authentication and Verification Services		4. STIR Profile for Endpoint Authentication and Verification Services
	STIR [I-D.ietf-stir-rfc4474bis] defines the Identity header field for		STIR [RFC8224] defines the Identity header field for SIP, which
	SIP, which provides a cryptographic attestation of the source of		provides a cryptographic attestation of the source of communications.
	communications. This profile assumes that a STIR verification		This profile of STIR assumes that a STIR verification service will
	service will act in concert with an SRTP media endpoint to ensure		act in concert with an SRTP media endpoint to ensure that the key
	that the key fingerprints, as given in SDP, match the keys exchanged		fingerprints, as given in SDP, match the keys exchanged to establish
	to establish DTLS-SRTP. To satisfy this condition, the verification		DTLS-SRTP. To satisfy this condition, the verification service
	service function would in this case be implemented in the SIP UAS,		function would in this case be implemented in the SIP UAS, which
	which would be composed with the media endpoint. If the STIR		would be composed with the media endpoint. If the STIR
	authentication service or verification service functions are		authentication service or verification service functions are
	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. The SIPBRANDY deployment profile of STIR		against such interference.
	for media confidentiality thus shifts these responsibilities to the
	endpoints rather than the intermediaries.		The SIPBRANDY deployment profile of STIR for media confidentiality
			thus shifts these responsibilities to the endpoints rather than the
			intermediaries. While intermediaries MAY provide the verification
			service function of STIR for SIPBRANDY transactions, intermediaries
			supporting this specification MUST NOT block or otherwise redirects
			calls if they do not trust the signing credential. The SIPBRANDY
			profile is based on an end-to-end trust 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 [I-D.ietf-stir-rfc4474bis].		verification service roles described in [RFC8224]. STIR
	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
	[I-D.ietf-stir-passport].		[RFC8225].
	When generating either an offer or an answer, compliant		When generating either an offer or an answer, compliant
	implementations MUST include an "a=fingerprint" attribute containing		implementations MUST include an "a=fingerprint" attribute containing
	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 must acquire the credentials needed to sign for		agent, SIP endpoints will need to acquire the credentials needed to
	their own identity. That identity is typically carried in the From		sign for their own identity. That identity is typically carried in
	header field of a SIP request, and either contains a greenfield SIP		the From header field of a SIP request, and either contains a
	URI (e.g. "sip:alice@example.com") or a telephone number, which can		greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone
	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").		"sip:+17004561212@example.com;user=phone"). [RFC8224] Section 8
	[I-D.ietf-stir-rfc4474bis] Section 8 contains guidance for separating		contains guidance for separating the two, and determining what sort
	the two, and determining what sort of credential is needed to sign		of credential is needed to sign for each.
	for each.
	To date, few commercial certificate authorities issue certificates		To date, few commercial certificate authorities issue certificates
	for SIP URIs or telephone numbers; though work is ongoing on systems		for SIP URIs or telephone numbers; though work is ongoing on systems
	for this purpose (such as [I-D.peterson-acme-telephone]) it is not		for this purpose (such as [I-D.ietf-acme-telephone]) it is not mature
	mature enough to be recommended as a best practice. This is one		enough to be recommended as a best practice. This is one reason why
	reason why the STIR standard is architected to permit intermediaries		the STIR standard is architected to permit intermediaries to act as
	to act as an authentication service on behalf of an entire domain,		an authentication service on behalf of an entire domain, just as in
	just as in SIP an proxy server can provide domain-level SIP service.		SIP an proxy server can provide domain-level SIP service. While
	While certificate authorities that offered proof-of-possession		certificate authorities that offered proof-of-possession certificates
	certificates similar to those used in the email world could be		similar to those used in the email world could be offered for SIP,
	offered for SIP, either for greenfield identifiers or for telephone		either for greenfield identifiers or for telephone numbers, this
	numbers, this specification does not require their use.		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 for media		permits the use of self-signed keys. This profile of STIR therefore
	confidentiality therefore relaxes the authority requirements of		relaxes the authority requirements of [RFC8224] to allow the use of
	[I-D.ietf-stir-rfc4474bis] to allow the use of self-signed keys for		self-signed keys for authentication services that are composed with
	authentication services that are composed with user agents, by		user agents, by generating a certificate (per the guidance of
	generating a certificate (per the guidance of		[RFC8226]) with a subject corresponding to the user's identity. Such
	[I-D.ietf-stir-certificates]) with a subject corresponding to the		a credential could be used for trust on first use (see [RFC7435]) by
	user's identity. Such a credential could be used for trust on first		relying parties. Note that relying parties SHOULD NOT use
	use (see [RFC7435]) by relying parties. Note that relying parties		certificate revocation mechanisms or real-time certificate
	SHOULD NOT use certificate revocation mechanisms or real-time		verification systems for self-signed certificates as they will not
	certificate verification systems for self-signed certificates as they		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		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 6, line 33 ¶		skipping to change at page 6, line 50 ¶
	recognize one another's certificates, those operational systems will		recognize one another's certificates, those operational systems will
	need to ramp up with the certificate authorities that issue		need to ramp up with the certificate authorities that issue
	credentials to end user devices going forward.		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. [RFC8224] does not currently permit authentication services
	authentication services to sign for requests that supply this		to sign for requests that supply this identity. It does however
	identity. It does however permit signing for valid domains, such as		permit signing for valid domains, such as "anonymous@example.com," as
	"anonymous@example.com," as a way of implementation an anonymization		a way of implementation an anonymization service as specified in
	service as specified in [RFC3323].		[RFC3323].
	Even for anonymous sessions, providing media confidentiality and		Even for anonymous sessions, providing media confidentiality and
	partial SDP integrity is still desirable. This specification		partial SDP integrity is still desirable. This specification
	RECOMMENDS using one-time self-signed certificates for anonymous		RECOMMENDS using one-time self-signed certificates for anonymous
	communications, with a subjectAltName of		communications, with a subjectAltName of
	"sip:anonymous@anonymous.invalid". After a session is terminated,		"sip:anonymous@anonymous.invalid". After a session is terminated,
	the certificate should be discarded, and a new one, with new keying		the certificate SHOULD be discarded, and a new one, with new keying
	material, should be generated before each future anonymous call. As		material, SHOULD be generated before each future anonymous call. As
	with self-signed certificates, relying parties SHOULD NOT use		with self-signed certificates, relying parties SHOULD NOT use
	certificate revocation mechanisms or real-time certificate		certificate revocation mechanisms or real-time certificate
	verification systems for anonymous certificates as they will not		verification systems for anonymous certificates as they will not
	increase confidence in the certificate.		increase confidence in the certificate.
	Note that when using one-time anonymous self-signed certificates, any		Note that when using one-time anonymous self-signed certificates, any
	man in the middle could strip the Identity header and replace it with		man in the middle could strip the Identity header and replace it with
	one signed by its own one-time certificate, changing the "mkey"		one signed by its own one-time certificate, changing the "mkey"
	parameters of PASSporT and any "a=fingerprint" attributes in SDP as		parameters of PASSporT and any "a=fingerprint" attributes in SDP as
	it chooses. This signature only provides protection against non-		it chooses. This signature only provides protection against non-
	Identity aware entities that might modify SDP without altering the		Identity aware entities that might modify SDP without altering the
	PASSporT conveyed in the Identity header.		PASSporT conveyed in the Identity header.
	4.3. Connected Identity Usage		4.3. Connected Identity Usage
	STIR [I-D.ietf-stir-rfc4474bis] provides integrity protection for the		STIR [RFC8224] provides integrity protection for the SDP bodies of
	SDP bodies of SIP requests, but not SIP responses. When a session is		SIP requests, but not SIP responses. When a session is established,
	established, therefore, any SDP body carried by a 200 class response		therefore, any SDP body carried by a 200 class response in the
	in the backwards direction will not be protected by an authentication		backwards direction will not be protected by an authentication
	service and cannot be verified. Thus, sending a secured SDP body in		service and cannot be verified. Thus, sending a secured SDP body in
	the backwards direction will require an extra RTT, typically a		the backwards direction will require an extra RTT, typically a
	request sent in the backwards direction.		request sent in the backwards direction.
	The problem of providing "Connected Identity" for the original		The problem of providing "Connected Identity" for the original
	RFC4474 was explored in [RFC4916], which uses a provisional or mid-		RFC4474 was explored in [RFC4916], which uses a provisional or mid-
	dialog UPDATE request in the backwards direction to convey an		dialog UPDATE request in the backwards direction to convey an
	Identity header for the recipient of an INVITE. The procedures in		Identity header for the recipient of an INVITE. The procedures in
	that specification are largely compatible with the revision of the		that specification are largely compatible with the revision of the
	Identity header in [I-D.ietf-stir-rfc4474bis]. However, the		Identity header in [RFC8224]. However, the following updates to
	following updates to [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 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		of error codes 428, 436, 437 and 438 in response to a mid-dialog
	request RECOMMENDS treating the dialog as terminated.		request RECOMMENDS treating the dialog as terminated. [RFC8224]
	[I-D.ietf-stir-rfc4474bis] allows the retransmission of requests		allows the retransmission of requests with repairable error
	with repairable error conditions (see section 6.1.1) in a way that		conditions (see section 6.1.1) in a way that can override that
	can override that SHOULD in RFC4916. In particular, an		SHOULD in RFC4916. In particular, an authentication service MAY
	authentication service MAY retry a mid-dialog as		retry a mid-dialog as [RFC8224] allows rather than treating the
	[I-D.ietf-stir-rfc4474bis] allows rather than treating the dialog		dialog as terminated, though note that only one such retry is
	as terminated, though note that only one such retry is permitted.		permitted.
	The examples in RFC4916 are based on the original RFC4474, and		The examples in RFC4916 are based on the original RFC4474, and
	will not match signatures using [I-D.ietf-stir-rfc4474bis].		will not match signatures using [RFC8224].
	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 should
	take into account any impacts on the profile described in this		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 ICE;
	see Section 7.		see Section 7.
	4.4. Authorization Decisions		4.4. Authorization Decisions
	[I-D.ietf-stir-rfc4474bis] grants STIR verification services a great		[RFC8224] grants STIR verification services a great deal of latitude
	deal of latitude when making authorization decisions based on the		when making authorization decisions based on the presence of the
	presence of the Identity header field. It is largely a matter of		Identity header field. It is largely a matter of local policy
	local policy whether an endpoint rejects a call based on absence of		whether an endpoint rejects a call based on absence of an Identity
	an Identity header field, or even the presence of a header that fails		header field, or even the presence of a header that fails an
	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 [I-D.ietf-stir-rfc4474bis] Section 6.2, MUST		steps described in [RFC8224] Section 6.2, MUST reject the request if
	reject the request if there is any failure in that validation process		there is any failure in that validation process with the appropriate
	with the appropriate status code per Section 6.2.2. If the request		status code per Section 6.2.2. If the request is valid, then if a
	is valid, then if a terminating user accepts the request, it MUST		terminating user accepts the request, it MUST then follow the steps
	then follow the steps in Section 4.3 to act as an authentication		in Section 4.3 to act as an authentication service and send a signed
	service and send a signed request with the "msec" PASSPorT type in		request with the "msec" PASSPorT type in its Identity header as well,
	its Identity header as well, in order to enable end-to-end		in order to enable end-to-end bidirectional confidentiality.
	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
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 17 ¶
	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].
	DTLS-SRTP is the only Standards Track Internet protocol for media		Support for DTLS-SRTP is REQUIRED by this specification.
	security. For that reason, this specification REQUIRES support for
	DTLS-SRTP.
	The "mkey" claim of PASSporT provides integrity protection for		The "mkey" claim of PASSporT provides integrity protection for
	"a=fingerprint" attributes in SDP, including cases where multiple		"a=fingerprint" attributes in SDP, including cases where multiple
	"a=fingerprint" attributes appear in the same SDP.		"a=fingerprint" attributes appear in the same SDP.
	6. Relayed Media and Conferencing		6. Relayed Media and Conferencing
	Providing end-to-end media confidentiality for SIP is complicated by		Providing end-to-end media confidentiality for SIP is complicated by
	the presence of many forms of media relays. While many media relays		the presence of many forms of media relays. While many media relays
	merely proxy media to a destination, others present themselves as		merely proxy media to a destination, others present themselves as
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 22 ¶
	This specification defines a new values for the PASSporT Type		This specification defines a new values for the PASSporT Type
	registry called "msec," and the IANA is requested to add that to the		registry called "msec," and the IANA is requested to add that to the
	registry with a value pointing to [RFCThis].		registry with a value pointing to [RFCThis].
	11. Security Considerations		11. Security Considerations
	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. References
	[I-D.ietf-ice-rfc5245bis]
	Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
	Connectivity Establishment (ICE): A Protocol for Network
	Address Translator (NAT) Traversal", draft-ietf-ice-
	rfc5245bis-14 (work in progress), October 2017.
	[I-D.ietf-mmusic-trickle-ice-sip]
	Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
	Session Initiation Protocol (SIP) usage for Trickle ICE",
	draft-ietf-mmusic-trickle-ice-sip-10 (work in progress),
	October 2017.
	[I-D.ietf-stir-certificates]
	Peterson, J. and S. Turner, "Secure Telephone Identity
	Credentials: Certificates", draft-ietf-stir-
	certificates-14 (work in progress), May 2017.
	[I-D.ietf-stir-passport]
	Wendt, C. and J. Peterson, "Personal Assertion Token
	(PASSporT)", draft-ietf-stir-passport-11 (work in
	progress), February 2017.
	[I-D.ietf-stir-rfc4474bis]
	Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
	"Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
	(work in progress), February 2017.
	[I-D.johnston-dispatch-osrtp]
	Johnston, A., Ph.D., D., Hutton, A., Liess, L., and T.
	Stach, "An Opportunistic Approach for Secure Real-time
	Transport Protocol (OSRTP)", draft-johnston-dispatch-
	osrtp-02 (work in progress), February 2016.
	[I-D.kaplan-mmusic-best-effort-srtp]
	Audet, F. and H. Kaplan, "Session Description Protocol
	(SDP) Offer/Answer Negotiation For Best-Effort Secure
	Real-Time Transport Protocol", draft-kaplan-mmusic-best-
	effort-srtp-01 (work in progress), October 2006.
	[I-D.peterson-acme-telephone]		12.1. Normative References
	Peterson, J. and R. Barnes, "ACME Identifiers and
	Challenges for Telephone Numbers", draft-peterson-acme-
	telephone-00 (work in progress), October 2016.
	[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>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002,
	skipping to change at page 12, line 37 ¶		skipping to change at page 11, line 47 ¶
	[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>.
	[RFC3323] Peterson, J., "A Privacy Mechanism for the Session		[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
	Initiation Protocol (SIP)", RFC 3323,		Initiation Protocol (SIP)", RFC 3323,
	DOI 10.17487/RFC3323, November 2002,		DOI 10.17487/RFC3323, November 2002,
	<https://www.rfc-editor.org/info/rfc3323>.		<https://www.rfc-editor.org/info/rfc3323>.
			[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
			Jacobson, "RTP: A Transport Protocol for Real-Time
			Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
			July 2003, <https://www.rfc-editor.org/info/rfc3550>.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, DOI 10.17487/RFC3711, March 2004,		RFC 3711, DOI 10.17487/RFC3711, March 2004,
	<https://www.rfc-editor.org/info/rfc3711>.		<https://www.rfc-editor.org/info/rfc3711>.
			[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
			Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
			July 2006, <https://www.rfc-editor.org/info/rfc4566>.
	[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session		[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
	Description Protocol (SDP) Security Descriptions for Media		Description Protocol (SDP) Security Descriptions for Media
	Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,		Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
	<https://www.rfc-editor.org/info/rfc4568>.		<https://www.rfc-editor.org/info/rfc4568>.
	[RFC4916] Elwell, J., "Connected Identity in the Session Initiation		[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
	Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June		Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
	2007, <https://www.rfc-editor.org/info/rfc4916>.		2007, <https://www.rfc-editor.org/info/rfc4916>.
	[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for		[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
	skipping to change at page 14, line 10 ¶		skipping to change at page 13, line 28 ¶
	[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M.		[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M.
	Thomson, "Session Traversal Utilities for NAT (STUN) Usage		Thomson, "Session Traversal Utilities for NAT (STUN) Usage
	for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675,		for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675,
	October 2015, <https://www.rfc-editor.org/info/rfc7675>.		October 2015, <https://www.rfc-editor.org/info/rfc7675>.
	[RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V.,		[RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V.,
	and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back		and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back
	User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016,		User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016,
	<https://www.rfc-editor.org/info/rfc7879>.		<https://www.rfc-editor.org/info/rfc7879>.
			[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
			"Authenticated Identity Management in the Session
			Initiation Protocol (SIP)", RFC 8224,
			DOI 10.17487/RFC8224, February 2018,
			<https://www.rfc-editor.org/info/rfc8224>.
			[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
			Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
			<https://www.rfc-editor.org/info/rfc8225>.
			[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
			Credentials: Certificates", RFC 8226,
			DOI 10.17487/RFC8226, February 2018,
			<https://www.rfc-editor.org/info/rfc8226>.
			12.2. Informative References
			[I-D.ietf-acme-telephone]
			Peterson, J. and R. Barnes, "ACME Identifiers and
			Challenges for Telephone Numbers", draft-ietf-acme-
			telephone-01 (work in progress), October 2017.
			[I-D.ietf-ice-rfc5245bis]
			Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
			Connectivity Establishment (ICE): A Protocol for Network
			Address Translator (NAT) Traversal", draft-ietf-ice-
			rfc5245bis-20 (work in progress), March 2018.
			[I-D.ietf-mmusic-trickle-ice-sip]
			Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
			Session Initiation Protocol (SIP) Usage for Trickle ICE",
			draft-ietf-mmusic-trickle-ice-sip-14 (work in progress),
			February 2018.
			[I-D.johnston-dispatch-osrtp]
			Johnston, A., Ph.D., D., Hutton, A., Liess, L., and T.
			Stach, "An Opportunistic Approach for Secure Real-time
			Transport Protocol (OSRTP)", draft-johnston-dispatch-
			osrtp-02 (work in progress), February 2016.
			[I-D.kaplan-mmusic-best-effort-srtp]
			Audet, F. and H. Kaplan, "Session Description Protocol
			(SDP) Offer/Answer Negotiation For Best-Effort Secure
			Real-Time Transport Protocol", draft-kaplan-mmusic-best-
			effort-srtp-01 (work in progress), October 2006.
	Authors' Addresses		Authors' Addresses
	Jon Peterson		Jon Peterson
	Neustar, Inc.		Neustar, Inc.
	1800 Sutter St Suite 570
	Concord, CA 94520
	US
	Email: jon.peterson@neustar.biz		Email: jon.peterson@team.neustar
	Eric Rescorla		Eric Rescorla
	Mozilla		Mozilla
	Email: ekr@rtfm.com		Email: ekr@rtfm.com
	Richard Barnes		Richard Barnes
	Mozilla		Cisco
	Email: rlb@ipv.sx		Email: rlb@ipv.sx
	Russ Housley		Russ Housley
	Vigilsec		Vigil Security, LLC
	Email: housley@vigilsec.com		Email: housley@vigilsec.com
End of changes. 39 change blocks.
	164 lines changed or deleted		181 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/