< draft-ietf-sipbrandy-rtpsec-05.txt		draft-ietf-sipbrandy-rtpsec-06.txt >
	Network Working Group J. Peterson		Network Working Group J. Peterson
	Internet-Draft Neustar		Internet-Draft Neustar
	Intended status: Best Current Practice R. Barnes		Intended status: Best Current Practice R. Barnes
	Expires: April 15, 2019 Mozilla		Expires: April 18, 2019 Mozilla
	R. Housley		R. Housley
	Vigil Security		Vigil Security
	October 12, 2018		October 15, 2018
	Best Practices for Securing RTP Media Signaled with SIP		Best Practices for Securing RTP Media Signaled with SIP
	draft-ietf-sipbrandy-rtpsec-05		draft-ietf-sipbrandy-rtpsec-06
	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 15, 2019.		This Internet-Draft will expire on April 18, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	skipping to change at page 3, line 25 ¶		skipping to change at page 3, line 25 ¶
	implementers should use to negotiate secure media with SIP. It		implementers should use to negotiate secure media with SIP. It
	moreover gives a gap analysis of the limitations of existing		moreover gives a gap analysis of the limitations of existing
	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
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as		"OPTIONAL" in this document are to be interpreted as described in BCP
	described in RFC 2119 [RFC2119] and RFC 6919 [RFC6919].		14 RFC 2119 [RFC2119] and RFC 8174 [RFC8174] when, and only when,
			they appear in all 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 33 ¶		skipping to change at page 5, line 33 ¶
	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].
	When generating either an offer or an answer, compliant		When generating either an offer or an answer [RFC3264], 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 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
	skipping to change at page 10, line 15 ¶		skipping to change at page 10, line 15 ¶
	sent elsewhere (see [RFC7245]).		sent elsewhere (see [RFC7245]).
	7. ICE and Connected Identity		7. ICE and Connected Identity
	Providing confidentiality for media with comprehensive protection		Providing confidentiality for media with comprehensive protection
	requires careful timing of when media streams should be sent and when		requires careful timing of when media streams should be sent and when
	a user interface should signify that confidentiality is in place.		a user interface should signify that confidentiality is in place.
	In order to best enable end-to-end connectivity between user agents,		In order to best enable end-to-end connectivity between user agents,
	and to avoid media relays as much as possible, implementations of		and to avoid media relays as much as possible, implementations of
	this specification must support ICE [I-D.ietf-ice-rfc5245bis]. To		this specification must support ICE [RFC8445]. To speed up call
	speed up call establishment, it is RECOMMENDED that implementations		establishment, it is RECOMMENDED that implementations support trickle
	support trickle ICE [I-D.ietf-mmusic-trickle-ice-sip].		ICE [I-D.ietf-mmusic-trickle-ice-sip].
	Note that in the comprehensive protection case, the use of Connected		Note that in the comprehensive protection case, the use of Connected
	Identity [RFC4916] with ICE entails that the answer containing the		Identity [RFC4916] with ICE entails that the answer containing the
	key fingerprints, and thus the STIR signature, will come in an UPDATE		key fingerprints, and thus the STIR signature, will come in an UPDATE
	sent in the backwards direction a provisional response and		sent in the backwards direction a provisional response and
	acknowledgment (PRACK), rather than in any earlier SDP body. Only at		acknowledgment (PRACK), rather than in any earlier SDP body. Only at
	such a time as that UPDATE is received will the media keys be		such a time as that UPDATE is received will the media keys be
	considered exchanged in this case.		considered exchanged in this case.
	Similarly, in order to prevent, or at least mitigate, the denial-of-		Similarly, in order to prevent, or at least mitigate, the denial-of-
	service attack envisioned in [RFC5245] Section 18.5.1, this		service attack described in Section 19.5.1 of [RFC8445], this
	specification incorporates best practices for ensuring that		specification incorporates best practices for ensuring that
	recipients of media flows have consented to receive such flows.		recipients of media flows have consented to receive such flows.
	Implementations of this specification MUST implement the STUN usage		Implementations of this specification MUST implement the STUN usage
	for consent freshness defined in [RFC7675].		for consent freshness defined in [RFC7675].
	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.
	skipping to change at page 12, line 23 ¶		skipping to change at page 12, line 23 ¶
	[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
	Real-time Transport Control Protocol (RTCP)-Based Feedback
	(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
	2008, <https://www.rfc-editor.org/info/rfc5124>.
	[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols", RFC 5245,
	DOI 10.17487/RFC5245, April 2010,
	<https://www.rfc-editor.org/info/rfc5245>.
	[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework		[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
	for Establishing a Secure Real-time Transport Protocol		for Establishing a Secure Real-time Transport Protocol
	(SRTP) Security Context Using Datagram Transport Layer		(SRTP) Security Context Using Datagram Transport Layer
	Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May		Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
	2010, <https://www.rfc-editor.org/info/rfc5763>.		2010, <https://www.rfc-editor.org/info/rfc5763>.
	[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
	Media Path Key Agreement for Unicast Secure RTP",
	RFC 6189, DOI 10.17487/RFC6189, April 2011,
	<https://www.rfc-editor.org/info/rfc6189>.
	[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
	for Use in RFCs to Indicate Requirement Levels", RFC 6919,
	DOI 10.17487/RFC6919, April 2013,
	<https://www.rfc-editor.org/info/rfc6919>.
	[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
	Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
	<https://www.rfc-editor.org/info/rfc6962>.
	[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor,
	"An Architecture for Media Recording Using the Session
	Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May
	2014, <https://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, <https://www.rfc-editor.org/info/rfc7258>.		2014, <https://www.rfc-editor.org/info/rfc7258>.
	[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
	Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
	December 2014, <https://www.rfc-editor.org/info/rfc7435>.
	[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>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,		[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
	"Authenticated Identity Management in the Session		"Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 8224,		Initiation Protocol (SIP)", RFC 8224,
	DOI 10.17487/RFC8224, February 2018,		DOI 10.17487/RFC8224, February 2018,
	<https://www.rfc-editor.org/info/rfc8224>.		<https://www.rfc-editor.org/info/rfc8224>.
	[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion		[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
	Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,		Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
	<https://www.rfc-editor.org/info/rfc8225>.		<https://www.rfc-editor.org/info/rfc8225>.
	[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity		[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
	Credentials: Certificates", RFC 8226,		Credentials: Certificates", RFC 8226,
	DOI 10.17487/RFC8226, February 2018,		DOI 10.17487/RFC8226, February 2018,
	<https://www.rfc-editor.org/info/rfc8226>.		<https://www.rfc-editor.org/info/rfc8226>.
			[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
			Connectivity Establishment (ICE): A Protocol for Network
			Address Translator (NAT) Traversal", RFC 8445,
			DOI 10.17487/RFC8445, July 2018,
			<https://www.rfc-editor.org/info/rfc8445>.
	12.2. Informative References		12.2. Informative References
	[I-D.ietf-acme-telephone]		[I-D.ietf-acme-telephone]
	Peterson, J. and R. Barnes, "ACME Identifiers and		Peterson, J. and R. Barnes, "ACME Identifiers and
	Challenges for Telephone Numbers", draft-ietf-acme-		Challenges for Telephone Numbers", draft-ietf-acme-
	telephone-01 (work in progress), October 2017.		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]		[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 Incremental		Session Initiation Protocol (SIP) Usage for Incremental
	Provisioning of Candidates for the Interactive		Provisioning of Candidates for the Interactive
	Connectivity Establishment (Trickle ICE)", draft-ietf-		Connectivity Establishment (Trickle ICE)", draft-ietf-
	mmusic-trickle-ice-sip-18 (work in progress), June 2018.		mmusic-trickle-ice-sip-18 (work in progress), June 2018.
	[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
	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.
			[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
			Media Path Key Agreement for Unicast Secure RTP",
			RFC 6189, DOI 10.17487/RFC6189, April 2011,
			<https://www.rfc-editor.org/info/rfc6189>.
			[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
			Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
			<https://www.rfc-editor.org/info/rfc6962>.
			[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor,
			"An Architecture for Media Recording Using the Session
			Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May
			2014, <https://www.rfc-editor.org/info/rfc7245>.
			[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
			Most of the Time", RFC 7435, DOI 10.17487/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		Mozilla
End of changes. 15 change blocks.
	53 lines changed or deleted		42 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/