< draft-campbell-sip-messaging-smime-02.txt		draft-campbell-sip-messaging-smime-03.txt >
	Network Working Group B. Campbell		Network Working Group B. Campbell
	Internet-Draft Standard Velocity		Internet-Draft Standard Velocity
	Updates: RFC 3261, RFC 3428, RFC 4975 R. Housley		Updates: RFC 3261, RFC 3428, RFC 4975 R. Housley
	(if approved) Vigil Security		(if approved) Vigil Security
	Intended status: Standards Track December 26, 2017		Intended status: Standards Track June 25, 2018
	Expires: June 29, 2018		Expires: December 27, 2018
	Securing Session Initiation Protocol (SIP) based Messaging with S/MIME		Securing Session Initiation Protocol (SIP) based Messaging with S/MIME
	draft-campbell-sip-messaging-smime-02		draft-campbell-sip-messaging-smime-03
	Abstract		Abstract
	Mobile messaging applications used with the Session Initiation		Mobile messaging applications used with the Session Initiation
	Protocol (SIP) commonly use some combination of the SIP MESSAGE		Protocol (SIP) commonly use some combination of the SIP MESSAGE
	method and the Message Session Relay Protocol (MSRP). While these		method and the Message Session Relay Protocol (MSRP). While these
	provide mechanisms for hop-by-hop security, neither natively provides		provide mechanisms for hop-by-hop security, neither natively provides
	end-to-end protection. This document offers guidance on how to		end-to-end protection. This document offers guidance on how to
	provide end-to-end authentication, integrity protection, and		provide end-to-end authentication, integrity protection, and
	confidentiality using the Secure/Multipurpose Internet Mail		confidentiality using the Secure/Multipurpose Internet Mail
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 June 29, 2018.		This Internet-Draft will expire on December 27, 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 25 ¶		skipping to change at page 2, line 25 ¶
	3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 4		3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 4
	4. Applicability of S/MIME . . . . . . . . . . . . . . . . . . . 5		4. Applicability of S/MIME . . . . . . . . . . . . . . . . . . . 5
	4.1. Signed Messages . . . . . . . . . . . . . . . . . . . . . 5		4.1. Signed Messages . . . . . . . . . . . . . . . . . . . . . 5
	4.2. Encrypted Messages . . . . . . . . . . . . . . . . . . . 6		4.2. Encrypted Messages . . . . . . . . . . . . . . . . . . . 6
	4.3. Signed and Encrypted Messages . . . . . . . . . . . . . . 7		4.3. Signed and Encrypted Messages . . . . . . . . . . . . . . 7
	4.4. Certificate Handling . . . . . . . . . . . . . . . . . . 8		4.4. Certificate Handling . . . . . . . . . . . . . . . . . . 8
	4.4.1. Subject Alternative Name . . . . . . . . . . . . . . 8		4.4.1. Subject Alternative Name . . . . . . . . . . . . . . 8
	4.4.2. Certificate Validation . . . . . . . . . . . . . . . 8		4.4.2. Certificate Validation . . . . . . . . . . . . . . . 8
	5. Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 8		5. Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 8
	6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 9		6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 9
	7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 10		7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 9
	7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 10		7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 10
	7.2. User Agent Capabilities . . . . . . . . . . . . . . . . . 10		7.2. User Agent Capabilities . . . . . . . . . . . . . . . . . 10
	7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 10		7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 10
	8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 11		8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 11
	8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 11		8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 12		8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 12
	8.3. Indicating support for S/MIME . . . . . . . . . . . . . . 12		8.3. Indicating support for S/MIME . . . . . . . . . . . . . . 12
	8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 13		8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 13		8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 13
	9. S/MIME Interaction with other SIP Messaging Features . . . . 13		9. S/MIME Interaction with other SIP Messaging Features . . . . 13
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 19		Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 19
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 21		12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	13.1. Normative References . . . . . . . . . . . . . . . . . . 22		13.1. Normative References . . . . . . . . . . . . . . . . . . 22
	13.2. Informative References . . . . . . . . . . . . . . . . . 24		13.2. Informative References . . . . . . . . . . . . . . . . . 24
	Appendix A. Message Details . . . . . . . . . . . . . . . . . . 26		Appendix A. Message Details . . . . . . . . . . . . . . . . . . 26
	A.1. Signed Message . . . . . . . . . . . . . . . . . . . . . 26		A.1. Signed Message . . . . . . . . . . . . . . . . . . . . . 26
	A.2. Short Signed Message . . . . . . . . . . . . . . . . . . 29		A.2. Short Signed Message . . . . . . . . . . . . . . . . . . 29
	A.3. Signed and Encrypted Message . . . . . . . . . . . . . . 30		A.3. Signed and Encrypted Message . . . . . . . . . . . . . . 30
	A.3.1. Signed Message Prior to Encryption . . . . . . . . . 30		A.3.1. Signed Message Prior to Encryption . . . . . . . . . 31
	A.3.2. Encrypted Message . . . . . . . . . . . . . . . . . . 33		A.3.2. Encrypted Message . . . . . . . . . . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
	1. Introduction		1. Introduction
	Several Mobile Messaging systems use the Session Initiation Protocol		Several Mobile Messaging systems use the Session Initiation Protocol
	(SIP) [RFC3261], typically as some combination of the SIP MESSAGE		(SIP) [RFC3261], typically as some combination of the SIP MESSAGE
	method [RFC3428] and the Message Session Relay Protocol (MSRP)		method [RFC3428] and the Message Session Relay Protocol (MSRP)
	[RFC4975]. For example, Voice over LTE (VoLTE) uses the SIP MESSAGE		[RFC4975]. For example, Voice over LTE (VoLTE) uses the SIP MESSAGE
	method to send Short Message Service (SMS) messages. The Open Mobile		method to send Short Message Service (SMS) messages. The Open Mobile
	skipping to change at page 9, line 14 ¶		skipping to change at page 9, line 14 ¶
	6. User Agent Capabilities		6. User Agent Capabilities
	Messaging UAs may implement a subset of S/MIME capabilities. Even		Messaging UAs may implement a subset of S/MIME capabilities. Even
	when implemented, some features may not be available due to		when implemented, some features may not be available due to
	configuration. For example, UAs that do not have user certificates		configuration. For example, UAs that do not have user certificates
	cannot sign messages on behalf of the user or decrypt encrypted		cannot sign messages on behalf of the user or decrypt encrypted
	messages sent to the user. At a minimum, a UA that supports S/MIME		messages sent to the user. At a minimum, a UA that supports S/MIME
	MUST be able to validate a signed message.		MUST be able to validate a signed message.
	End-user certificates have long been a barrier to large-scale		End-user certificates have long been a barrier to large-scale S/MIME
	S/MIME deployment. But since UAs can validate signatures even		deployment. But since UAs can validate signatures even without local
	without local certificates, the use case of organizations sending		certificates, the use case of organizations sending secure
	secure notifications to their users becomes a sort of "low hanging		notifications to their users becomes a sort of "low hanging fruit".
	fruit".
	SIP and MSRP UAs advertise their level of support for S/MIME by		SIP and MSRP UAs advertise their level of support for S/MIME by
	indicating their capability to receive the "application/pkcs7-mime"		indicating their capability to receive the "application/pkcs7-mime"
	media type.		media type.
	The fact that a UA indicates support for the "multipart/signed" media		The fact that a UA indicates support for the "multipart/signed" media
	type does not necessarily imply support for S/MIME. The UA might		type does not necessarily imply support for S/MIME. The UA might
	just be able to display clear-signed content without validating the		just be able to display clear-signed content without validating the
	signature. UAs that wish to indicate the ability to validate		signature. UAs that wish to indicate the ability to validate
	signatures for clear-signed messages MUST also indicate support for		signatures for clear-signed messages MUST also indicate support for
	skipping to change at page 21, line 26 ¶		skipping to change at page 21, line 26 ¶
	This document makes no requests of the IANA.		This document makes no requests of the IANA.
	12. Security Considerations		12. Security Considerations
	The security considerations from S/MIME [RFC5750][RFC5751] and		The security considerations from S/MIME [RFC5750][RFC5751] and
	elliptic curves in CMS [RFC5753] apply. The S/MIME related security		elliptic curves in CMS [RFC5753] apply. The S/MIME related security
	considerations from SIP [RFC3261][RFC3853], SIP MESSAGE [RFC3428],		considerations from SIP [RFC3261][RFC3853], SIP MESSAGE [RFC3428],
	and MSRP [RFC4975] apply.		and MSRP [RFC4975] apply.
			The security considerations from algorithms recommended in this
			document also apply, see [RFC3565], [RFC5480], [RFC5753], [RFC5754],
			[RFC7748], [RFC8032], [I-D.ietf-curdle-cms-eddsa-signatures], and
			[I-D.ietf-curdle-cms-ecdh-new-curves].
	This document assumes that end-entity certificate validation is		This document assumes that end-entity certificate validation is
	provided by a chain of trust to a certification authority (CA), using		provided by a chain of trust to a certification authority (CA), using
	a public key infrastructure. The security considerations from		a public key infrastructure. The security considerations from
	[RFC5280] apply. However, other validations methods may be possible;		[RFC5280] apply. However, other validations methods may be possible;
	for example sending a signed fingerprint for the end-entity in SDP.		for example sending a signed fingerprint for the end-entity in SDP.
	The relationship of this work and the techniques discussed in		The relationship of this work and the techniques discussed in
	[RFC4474], [I-D.ietf-stir-rfc4474bis], and		[RFC4474], [I-D.ietf-stir-rfc4474bis], and
	[I-D.ietf-sipbrandy-rtpsec] are out of scope for this document.		[I-D.ietf-sipbrandy-rtpsec] are out of scope for this document.
	When matching an end-entity certificate to the sender or recipient		When matching an end-entity certificate to the sender or recipient
	skipping to change at page 22, line 20 ¶		skipping to change at page 22, line 25 ¶
	messages. In certain cases this metadata may reveal information to		messages. In certain cases this metadata may reveal information to
	third parties that would have otherwise been encrypted. Implementors		third parties that would have otherwise been encrypted. Implementors
	and operators should consider whether this metadata may create		and operators should consider whether this metadata may create
	privacy leaks. Such an analysis is beyond the scope of this		privacy leaks. Such an analysis is beyond the scope of this
	document.		document.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
			[I-D.ietf-curdle-cms-ecdh-new-curves]
			Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key
			Agreement Algorithm with X25519 and X448 in the
			Cryptographic Message Syntax (CMS)", draft-ietf-curdle-
			cms-ecdh-new-curves-10 (work in progress), August 2017.
			[I-D.ietf-curdle-cms-eddsa-signatures]
			Housley, R., "Use of EdDSA Signatures in the Cryptographic
			Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa-
			signatures-08 (work in progress), October 2017.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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,
	<https://www.rfc-editor.org/info/rfc3261>.		<https://www.rfc-editor.org/info/rfc3261>.
	skipping to change at page 24, line 19 ¶		skipping to change at page 24, line 37 ¶
	[X690] ITU-T, "Information Technology -- ASN.1 encoding rules:		[X690] ITU-T, "Information Technology -- ASN.1 encoding rules:
	Specification of Basic Encoding Rules (BER), Canonical		Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules		Encoding Rules (CER) and Distinguished Encoding Rules
	(DER)", ITU-T Recommendation X.690, 2015.		(DER)", ITU-T Recommendation X.690, 2015.
	13.2. Informative References		13.2. Informative References
	[CPM] Open Mobile Alliance, "OMA Converged IP Messaging System		[CPM] Open Mobile Alliance, "OMA Converged IP Messaging System
	Description, Candidate Version 2.2", September 2017.		Description, Candidate Version 2.2", September 2017.
	[I-D.ietf-curdle-cms-ecdh-new-curves]
	Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key
	Agreement Algorithm with X25519 and X448 in the
	Cryptographic Message Syntax (CMS)", draft-ietf-curdle-
	cms-ecdh-new-curves-10 (work in progress), August 2017.
	[I-D.ietf-curdle-cms-eddsa-signatures]
	Housley, R., "Use of EdDSA Signatures in the Cryptographic
	Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa-
	signatures-08 (work in progress), October 2017.
	[I-D.ietf-sipbrandy-rtpsec]		[I-D.ietf-sipbrandy-rtpsec]
	Peterson, J., Rescorla, E., Barnes, R., and R. Housley,		Peterson, J., Rescorla, E., Barnes, R., and R. Housley,
	"Best Practices for Securing RTP Media Signaled with SIP",		"Best Practices for Securing RTP Media Signaled with SIP",
	draft-ietf-sipbrandy-rtpsec-03 (work in progress), October		draft-ietf-sipbrandy-rtpsec-04 (work in progress), May
	2017.		2018.
	[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-16		Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
	(work in progress), February 2017.		(work in progress), February 2017.
	[RCS] GSMA, "RCS Universal Profile Service Definition Document,		[RCS] GSMA, "RCS Universal Profile Service Definition Document,
	Version 2.0", June 2017.		Version 2.0", June 2017.
End of changes. 11 change blocks.
	25 lines changed or deleted		29 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/