< draft-campbell-sip-messaging-smime-00.txt   draft-campbell-sip-messaging-smime-01.txt >
Network Working Group B. Campbell Network Working Group B. Campbell
Internet-Draft Independent Internet-Draft Independent
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 October 30, 2017 Intended status: Standards Track November 29, 2017
Expires: May 3, 2018 Expires: June 2, 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-00 draft-campbell-sip-messaging-smime-01
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 May 3, 2018. This Internet-Draft will expire on June 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scope of This Document . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 3
4. Applicability of S/MIME . . . . . . . . . . . . . . . . . . . 4 4. Applicability of S/MIME . . . . . . . . . . . . . . . . . . . 4
4.1. Signed Messages . . . . . . . . . . . . . . . . . . . . . 4 4.1. Signed Messages . . . . . . . . . . . . . . . . . . . . . 5
4.2. Encrypted Messages . . . . . . . . . . . . . . . . . . . 5 4.2. Encrypted Messages . . . . . . . . . . . . . . . . . . . 6
4.3. Signed and Encrypted Messages . . . . . . . . . . . . . . 6 4.3. Signed and Encrypted Messages . . . . . . . . . . . . . . 7
4.4. Certificate Handling . . . . . . . . . . . . . . . . . . 7 4.4. Certificate Handling . . . . . . . . . . . . . . . . . . 7
4.4.1. Subject Alternative Name . . . . . . . . . . . . . . 7 4.4.1. Subject Alternative Name . . . . . . . . . . . . . . 7
4.4.2. Certificate Validation . . . . . . . . . . . . . . . 7 4.4.2. Certificate Validation . . . . . . . . . . . . . . . 7
5. Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 7 5. Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 8
6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 7 6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 8
7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 8 7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 9
7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. User Agent Capabilities . . . . . . . . . . . . . . . . . 9 7.2. User Agent Capabilities . . . . . . . . . . . . . . . . . 9
7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 9 7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 10
8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 10 8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 10
8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 10
8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 10 8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 11
8.3. Indicating support for S/MIME . . . . . . . . . . . . . . 11 8.3. Indicating support for S/MIME . . . . . . . . . . . . . . 11
8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 11 8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 12
8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 12 8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 12
9. S/MIME Interaction with other SIP Messaging Features . . . . 12 9. S/MIME Interaction with other SIP Messaging Features . . . . 13
9.1. Common Profile for Instant Messaging . . . . . . . . . . 12 9.1. Common Profile for Instant Messaging . . . . . . . . . . 13
9.2. Instant Message Delivery Notifications . . . . . . . . . 13 9.2. Instant Message Delivery Notifications . . . . . . . . . 14
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . 14 13.1. Normative References . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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, VoLTE uses the SIP MESSAGE method to send [RFC4975]. For example, Voice over LTE (VoLTE) uses the SIP MESSAGE
Short Message Service (SMS) messages. The Open Mobile Alliance (OMA) method to send Short Message Service (SMS) messages. The Open Mobile
Converged IP Messaging (CPM) system uses the SIP Message Method for Alliance (OMA) Converged IP Messaging (CPM) [CPM], [RCS] system uses
short "pager mode" messages and MSRP for large messages and for the SIP Message Method for short "pager mode" messages and MSRP for
sessions of messages. The GSM Association (GMSA) rich communication large messages and for sessions of messages. The GSM Association
services (RCS) uses CPM for messaging. (GMSA) rich communication services (RCS) uses CPM for messaging.
At the same time, organizations increasingly depend on mobile At the same time, organizations increasingly depend on mobile
messaging systems to send notifications to their customers. Many of messaging systems to send notifications to their customers. Many of
these notifications are security sensitive. For example, such these notifications are security sensitive. For example, such
notifications are commonly used for notice of financial transactions, notifications are commonly used for notice of financial transactions,
notice of login or password change attempts, and sending of two- notice of login or password change attempts, and sending of two-
factor authentication codes. factor authentication codes.
While both SIP and MSRP provide mechanisms for hop-by-hop security,
neither provides native end-to-end protection. Instead, they depend
on S/MIME [RFC5750][RFC5751].
This document updates and provides clarifications to RFC 3261, RFC
3428, and RFC 4975. While each of those documents already describes
the use of S/MIME to some degree, that guidance contains
inconsistencies, and it is out of date in terms of supported and
recommended algorithms. The guidance in RFC 3261 is offered in the
context of signaling applications, and it is not entirely appropriate
for messaging applications.
Both SIP and MSRP can be used to transport any content using Both SIP and MSRP can be used to transport any content using
Multipurpose Internet Mail Extensions (MIME) formats. The SIP Multipurpose Internet Mail Extensions (MIME) formats. The SIP
MESSAGE method is typically limited to short messages (under 1300 MESSAGE method is typically limited to short messages (under 1300
octets for the MESSAGE request). MSRP can carry arbitrarily large octets for the MESSAGE request). MSRP can carry arbitrarily large
messages, and can break large messages into chunks. messages, and can break large messages into chunks.
MSRP sessions are negotiated using the Session Description Protocol While both SIP and MSRP provide mechanisms for hop-by-hop security,
(SDP) [RFC4566] offer/answer mechanism [RFC3264] or similar neither provides native end-to-end protection. Instead, they depend
mechanisms. This document assumes that SIP is used for the offer/ on S/MIME [RFC5750][RFC5751]. However at the time of this writing,
answer exchange. However, the techniques should be adaptable to S/MIME is not in common use for SIP and MSRP based messaging
other signaling protocols. services. This document updates and clarifies RFC 3261, RFC 3428,
and RFC 4975 in an attempt to make the S/MIME for SIP and MSRP easier
to implement and deploy in an interoperable fashion.
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 BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Scope of This Document 3. Problem Statement and Scope
This document discusses the use of S/MIME with SIP based messaging. This document discusses the use of S/MIME with SIP based messaging.
Other standardized messaging protocols exist, such as the Extensible Other standardized messaging protocols exist, such as the Extensible
Messaging and Presence Protocol (XMPP) [RFC6121]. Likewise, other Messaging and Presence Protocol (XMPP) [RFC6121]. Likewise, other
end-to-end protection formats exist, such as JSON Web Signatures end-to-end protection formats exist, such as JSON Web Signatures
[RFC7515] and JSON Web Encryption [RFC7516]. [RFC7515] and JSON Web Encryption [RFC7516].
This document focuses on SIP-based messaging because its use is This document focuses on SIP-based messaging because its use is
becoming more common in mobile environments. It focuses on S/MIME becoming more common in mobile environments. It focuses on S/MIME
since several mobile operating systems already have S/MIME libraries since several mobile operating systems already have S/MIME libraries
installed. While there may also be value in specifying end-to-end installed. While there may also be value in specifying end-to-end
security for other messaging and security mechanisms, it is out of security for other messaging and security mechanisms, it is out of
scope for this document. scope for this document.
MSRP sessions are negotiated using the Session Description Protocol
(SDP) [RFC4566] offer/answer mechanism [RFC3264] or similar
mechanisms. This document assumes that SIP is used for the offer/
answer exchange. However, the techniques should be adaptable to
other signaling protocols.
[RFC3261], [RFC3428], and [RFC4975] already describe the use of
S/MIME. [RFC3853] updates SIP to support the Advanced Encryption
Standard (AES). In aggregate that guidance is incomplete, contains
inconsistencies, and is still out of date in terms of supported and
recommended algorithms.
The guidance in RFC 3261 is based on an implicit assumption that
S/MIME is being used to secure signaling applications. That advice
is not entirely appropriate for messaging application. For example,
it assumes that message decryption always happens before the SIP
transaction completes.
This document offers normative updates and clarifications to the use
of S/MIME with the SIP MESSAGE method and MSRP. It does not attempt
to define a complete secure messaging system. Such system would
require considerable work around user enrollment, certificate and key
generation and management, multiparty chats, device management, etc.
While nothing herein should preclude those efforts, they are out of
scope for this document.
This document primarily covers the sending of single messages, for This document primarily covers the sending of single messages, for
example "pager-mode messages" send using the SIP MESSASGE method and example "pager-mode messages" send using the SIP MESSAGE method and
"large messages" sent in MSRP. Techniques to use a common signing or "large messages" sent in MSRP. Techniques to use a common signing or
encryption across a session of messages are out of scope for this encryption key across a session of messages are out of scope for this
document, but may be discussed in a future version. document, but may be discussed in a future version.
Cryptographic algorithm requirements in this document are intended Cryptographic algorithm requirements in this document are intended
supplement those of SIP and MSRP. supplement those already specified for SIP and MSRP.
4. Applicability of S/MIME 4. Applicability of S/MIME
The Cryptographic Message Syntax (CMS) [RFC5652] is an encapsulation The Cryptographic Message Syntax (CMS) [RFC5652] is an encapsulation
syntax that is used to digitally sign, digest, authenticate, or syntax that is used to digitally sign, digest, authenticate, or
encrypt arbitrary message content. The CMS supports a variety of encrypt arbitrary message content. The CMS supports a variety of
architectures for certificate-based key management, especially the architectures for certificate-based key management, especially the
one defined by the IETF PKIX (Public Key Infrastructure using X.509) one defined by the IETF PKIX (Public Key Infrastructure using X.509)
working group [RFC5280]. The CMS values are generated using ASN.1 working group [RFC5280]. The CMS values are generated using ASN.1
[X680], using the Basic Encoding Rules (BER) and Distinguished [X680], using the Basic Encoding Rules (BER) and Distinguished
Encoding Rules (DER) [X690]. Encoding Rules (DER) [X690].
The S/MIME Message Specification [RFC5751] defines MIME body parts The S/MIME Message Specification version 3.2 [RFC5751] defines MIME
based on the CMS. In this document, the application/pkcs7-mime media body parts based on the CMS. In this document, the application/
type is used to digitally sign an encapsulated body part, and it is pkcs7-mime media type is used to digitally sign an encapsulated body
also is used to encrypt an encapsulated body part. part, and it is also is used to encrypt an encapsulated body part.
4.1. Signed Messages 4.1. Signed Messages
While both SIP and MSRP require support for the multipart/signed While both SIP and MSRP require support for the multipart/signed
format, this document recommends the use of application/pkcs7-mime format, this document recommends the use of application/pkcs7-mime
for most signed messages. Experience with the use of S/MIME in for most signed messages. Experience with the use of S/MIME in
electronic mail has shown that multipart/signed bodies are at greater electronic mail has shown that multipart/signed bodies are at greater
risk of "helpful" tampering by intermediaries, a common cause of risk of "helpful" tampering by intermediaries, a common cause of
signature validation failure. This risk is also present for signature validation failure. This risk is also present for
messaging applications; for example, intermediaries might insert messaging applications; for example, intermediaries might insert
skipping to change at page 5, line 32 skipping to change at page 5, line 46
id-sha256 OBJECT IDENTIFIER ::= { id-sha256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 } csor(3) nistalgorithm(4) hashalgs(2) 1 }
Sending and receiving UAs MAY support other message digest Sending and receiving UAs MAY support other message digest
algorithms. algorithms.
Sending and receiving UAs MUST support the Elliptic Curve Digital Sending and receiving UAs MUST support the Elliptic Curve Digital
Signature Algorithm (ECDSA) using the NIST P256 elliptic curve and Signature Algorithm (ECDSA) using the NIST P256 elliptic curve and
the SHA-256 message digest algorithm [RFC5480][RFC5753]. For the SHA-256 message digest algorithm [RFC5480][RFC5753]. Sending and
convenience, the ECDSA with SHA-256 algorithm identifier and the receiving UAs SHOULD support the Edwards-curve Digital Signature
object identifier for the well-known NIST P256 elliptic curve are Algorithm (EdDSA) with curve25519 (Ed25519)
repeated here: [RFC8032][I-D.ietf-curdle-cms-eddsa-signatures]. For convenience,
the ECDSA with SHA-256 algorithm identifier, the object identifier
for the well-known NIST P256 elliptic curve, and the Ed25519
algorithm identifier are repeated here:
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 2 } ecdsa-with-SHA2(3) 2 }
-- Note: the NIST P256 elliptic curve is also known as secp256r1. -- Note: the NIST P256 elliptic curve is also known as secp256r1.
secp256r1 OBJECT IDENTIFIER ::= { secp256r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 7 } prime(1) 7 }
id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 }
4.2. Encrypted Messages 4.2. Encrypted Messages
When generating an encrypted message, sending UAs MUST follow the When generating an encrypted message, sending UAs MUST follow the
conventions specified in [RFC5751] for the application/pkcs7-mime conventions specified in [RFC5751] for the application/pkcs7-mime
media type with smime-type=enveloped-data. When decrypting a media type with smime-type=enveloped-data. When decrypting a
received message, receiving UAs MUST follow the conventions specified received message, receiving UAs MUST follow the conventions specified
in [RFC5751] for the application/pkcs7-mime media type with smime- in [RFC5751] for the application/pkcs7-mime media type with smime-
type=enveloped-data. type=enveloped-data.
Sending and receiving UAs MUST support the AES-128-CBC for content Sending and receiving UAs MUST support the AES-128-CBC for content
skipping to change at page 6, line 37 skipping to change at page 7, line 7
Sending and receiving UAs MAY support other key encryption Sending and receiving UAs MAY support other key encryption
algorithms. algorithms.
Symmetric key-encryption keys can be distributed before messages are Symmetric key-encryption keys can be distributed before messages are
sent. If sending and receiving UAs support previously distributed sent. If sending and receiving UAs support previously distributed
key-encryption keys, then they MUST assign a KEK identifier [RFC5652] key-encryption keys, then they MUST assign a KEK identifier [RFC5652]
to the previously distributed symmetric key. to the previously distributed symmetric key.
Alternatively, a key agreement algorithm can be used to establish a Alternatively, a key agreement algorithm can be used to establish a
single-use key-encryption key. If sending and receiving UAs support single-use key-encryption key. If sending and receiving UAs support
key agreement, then they MUST the Elliptic Curve Diffie-Hellman key agreement, then they MUST support the Elliptic Curve Diffie-
(ECDH) using the NIST P256 elliptic curve and the ANSI-X9.63-KDF key Hellman (ECDH) using the NIST P256 elliptic curve and the ANSI-
derivation function with the SHA-256 message digest algorithm X9.63-KDF key derivation function with the SHA-256 message digest
[RFC5753]. For convenience, the ECDH using the ANSI-X9.63-KDF with algorithm [RFC5753]. If sending and receiving UAs support key
SHA-256 algorithm identifier is repeated here: agreement, then they SHOULD support the Elliptic Curve Diffie-Hellman
(ECDH) using curve25519 (X25519)
[RFC7748][I-D.ietf-curdle-cms-ecdh-new-curves]. For convenience, the
ECDH using the ANSI-X9.63-KDF with SHA-256 algorithm identifier and
the X25519 algorithm identifier are repeated here:
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) iso(1) identified-organization(3) certicom(132)
schemes(1) 11 1 } schemes(1) 11 1 }
id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 }
4.3. Signed and Encrypted Messages 4.3. Signed and Encrypted Messages
When generating a signed and encrypted message, sending UAs MUST sign When generating a signed and encrypted message, sending UAs MUST sign
the message first, and then encrypt it. the message first, and then encrypt it.
4.4. Certificate Handling 4.4. Certificate Handling
Sending and receiving UAs MUST follow the S/MIME certificate handling Sending and receiving UAs MUST follow the S/MIME certificate handling
procedures [RFC5750], with a few exceptions detailed below. procedures [RFC5750], with a few exceptions detailed below.
4.4.1. Subject Alternative Name 4.4.1. Subject Alternative Name
The subject alternative name extension is used as the preferred means The subject alternative name extension is used as the preferred means
to convey the SIP URI of a message signer. Any SIP URI present MUST to convey the SIP URI of a message signer. Any SIP URI present MUST
be encoded using the uniformResourceIdentifier CHOICE of the be encoded using the uniformResourceIdentifier CHOICE of the
GeneralName type as described in [RFC5280], Section 4.2.1.6. Since GeneralName type as described in [RFC5280], Section 4.2.1.6. Since
the SubjectAltName type is a SEQUENCE OF GeneralName, multiple URIs the SubjectAltName type is a SEQUENCE OF GeneralName, multiple URIs
MAY be present. MAY be present.
Open Issue: Should we consider other means of linking the identity to
the certificate other than a SIP URI? For example, a specially
constructed domain name for a cert issued via an ACME service? One
approach might to be to say to use a SIP URI in the absence of other
mechanisms.
4.4.2. Certificate Validation 4.4.2. Certificate Validation
When validating a certificate, receiving UAs MUST support the When validating a certificate, receiving UAs MUST support the
Elliptic Curve Digital Signature Algorithm (ECDSA) using the NIST Elliptic Curve Digital Signature Algorithm (ECDSA) using the NIST
P256 elliptic curve and the SHA-256 message digest algorithm P256 elliptic curve and the SHA-256 message digest algorithm
[RFC5480]. [RFC5480].
Sending and receiving UAs MAY support other digital signature Sending and receiving UAs MAY support other digital signature
algorithms for certificate validation. algorithms for certificate validation.
skipping to change at page 11, line 31 skipping to change at page 12, line 12
S/MIME media types in the "accept-types" attribute and putting all S/MIME media types in the "accept-types" attribute and putting all
other supported media types in the "accept-wrapped-types" attribute. other supported media types in the "accept-wrapped-types" attribute.
For backwards compatibility, a sender MAY treat a peer that includes For backwards compatibility, a sender MAY treat a peer that includes
an asterisk ("*") in the "accept-types" attribute as potentially an asterisk ("*") in the "accept-types" attribute as potentially
supporting S/MIME. If the peer returns an MSRP 415 response to an supporting S/MIME. If the peer returns an MSRP 415 response to an
attempt to send an S/MIME message, the sender should treat the peer attempt to send an S/MIME message, the sender should treat the peer
as not supporting S/MIME for the duration of the session, as as not supporting S/MIME for the duration of the session, as
indicated in [RFC4975]. indicated in [RFC4975].
While these SDP attributes allow an endpoint to express support for
certain media types only when wrapped in a specified envelope type,
it does not allow the expression of more complex structures. For
example, an endpoint can say that it supports text/plain and text/
html, but only when inside an application/pkcs7 or message/cpim
container, but it cannot express a requirement for the leaf types to
always be contained in an application/pkcs7 container nested inside a
message/cpim container. This has implications for the use of s/mime
with the message/cpim format. (See Section 9.1.)
MSRP allows multiple reporting modes that provide different levels of MSRP allows multiple reporting modes that provide different levels of
feedback. If the sender includes a Failure-Report header field with feedback. If the sender includes a Failure-Report header field with
a value of "no", it will not receive failure reports. This mode a value of "no", it will not receive failure reports. This mode
should not be used carelessly, since such a sender would never see a should not be used carelessly, since such a sender would never see a
415 response as described above, and would have no way to learn that 415 response as described above, and would have no way to learn that
the recipient could not process an S/MIME body. the recipient could not process an S/MIME body.
8.4. MSRP URIs 8.4. MSRP URIs
MSRP URIs are ephemeral. Endpoints MUST NOT use MSRP URIs to MSRP URIs are ephemeral. Endpoints MUST NOT use MSRP URIs to
skipping to change at page 12, line 48 skipping to change at page 13, line 36
The Common Profile for Instant Messages Message Format [RFC3862] The Common Profile for Instant Messages Message Format [RFC3862]
allows UAs to attach transport-neutral metadata to arbitrary MIME allows UAs to attach transport-neutral metadata to arbitrary MIME
content. The format was designed as a canonicalization format to content. The format was designed as a canonicalization format to
allow signed data to cross protocol-converting gateways without loss allow signed data to cross protocol-converting gateways without loss
of metadata needed to verify the signature. While it has not of metadata needed to verify the signature. While it has not
typically been used for that purpose, it has been used for other typically been used for that purpose, it has been used for other
metadata applications, for example, Intant Message Delivery metadata applications, for example, Intant Message Delivery
Notifications (IMDN)[RFC5438] and MSRP Multi-party Chat [RFC7701] Notifications (IMDN)[RFC5438] and MSRP Multi-party Chat [RFC7701]
Signature and encryption operations are typically applied to the In the general case, a sender applies end-to-end signature and
entire CPIM body part, rather than to just the CPIM payload. The use encryption operations to the entire MIME body. However, some
of CPIM metadata fields to identify certificates or to authenticate messaging systems expect to inspect and in some cases add or modify
SIP or MSRP header fields is for further study. metadata in CPIM header fields. For example, CPM and RCS based
service include application servers that may need to insert time
stamps into chat messages, and may use additional metadata to
characterize the content and purpose of a message to determine
application behavior. The former will cause validation failure for
signatures that cover CPIM metadata, while the latter is not possible
if the metadata is encrypted. Clients intended for use in such
networks MAY choose to apply end-to-end signatures and encryption
operations to only the CPIM payload, leaving the CPIM metadata
unprotected from inspection and modification.
If such clients need to provide encrypt or sign CPIM metadata end-to-
end, they can nest a protected CPIM message format payload inside an
unprotected CPIM message envelope.
The use of CPIM metadata fields to identify certificates or to
authenticate SIP or MSRP header fields is out of scope for this
document.
9.2. Instant Message Delivery Notifications 9.2. Instant Message Delivery Notifications
The Instant Message Delivery Notification (IMDN) mechanism[RFC5438] The Instant Message Delivery Notification (IMDN) mechanism[RFC5438]
allows both endpoints and intermediary application servers to request allows both endpoints and intermediary application servers to request
and to generate delivery notifications. The use of S/MIME does not and to generate delivery notifications. The use of S/MIME does not
impact strictly end-to-end use of IMDN. IMDN recommends that devices impact strictly end-to-end use of IMDN. IMDN recommends that devices
that are capable of doing so sign delivery notifications. It further that are capable of doing so sign delivery notifications. It further
requires that delivery notifications that result from encrypted requires that delivery notifications that result from encrypted
messages also be encrypted. messages also be encrypted.
However, IMDN allows intermediary application servers to insert However, IMDN allows intermediary application servers to insert
notification requests into messages, to add routing information to notification requests into messages, to add routing information to
messages, and to act on notification requests. It also allows list messages, and to act on notification requests. It also allows list
servers to aggregate delivery notifications. servers to aggregate delivery notifications.
Such intermediaries will be unable to read end-to-end encrypted Such intermediaries will be unable to read end-to-end encrypted
messages in order to interpret delivery notice requests. messages in order to interpret delivery notice requests.
Intermediaries that insert information into end-to-end signed Intermediaries that insert information into end-to-end signed
messages will cause the signature validation to fail. messages will cause the signature validation to fail. (See
Section 9.1.)
10. Examples 10. Examples
Examples will be added in a future version of this document. Examples will be added in a future version of this document.
11. IANA Considerations 11. IANA Considerations
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.
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 certification authority (CA), using a provided by a chain of trust to a certification authority (CA), using
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 for further study. [I-D.ietf-sipbrandy-rtpsec] are for future study.
When matching an end-entity certificate to the sender or recipient When matching an end-entity certificate to the sender or recipient
identity, the respective SIP AoRs are used. Typically these will identity, the respective SIP AoRs are used. Typically these will
match the SIP From and To header fields. Matching SIP AoRs from match the SIP From and To header fields. Matching SIP AoRs from
other header fields, for example, P-Asserted-Identity [RFC3325], is other header fields, for example, P-Asserted-Identity [RFC3325], is
for further study. for future study.
The secure notification use case discussed in Section 1 has The secure notification use case discussed in Section 1 has
significant vulnerabilities when used in an insecure environment. significant vulnerabilities when used in an insecure environment.
For example, "phishing" messages could be used to trick users into For example, "phishing" messages could be used to trick users into
revealing credentials. Eavesdroppers could learn confirmation codes revealing credentials. Eavesdroppers could learn confirmation codes
from unprotected two-factor authentication messages. Unsolicited from unprotected two-factor authentication messages. Unsolicited
messages sent by impersonators could tarnish the reputation of an messages sent by impersonators could tarnish the reputation of an
organization. While hop-by-hop protection can mitigate some of those organization. While hop-by-hop protection can mitigate some of those
risks, it still leaves messages vulnerabile to malicious or risks, it still leaves messages vulnerabile to malicious or
compromised intermediaries. compromised intermediaries.
Mobile messaging is typically an online application; online Mobile messaging is typically an online application; online
certificate revocation checks should usually be feasible. certificate revocation checks should usually be feasible.
Certain messaging services, for example those based on CPM and RCS,
may include intermediaries that attach metadata to user generated
messages. In certain cases this metadata may reveal information to
third parties that would have otherwise been encrypted. Implementors
and operators should consider whether this metadata may create
privacy leaks. Such an analysis is beyond the scope of this
document.
13. References 13. References
13.1. Normative References 13.1. Normative References
[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,
skipping to change at page 16, line 20 skipping to change at page 17, line 39
One (ASN.1): Specification of basic notation", One (ASN.1): Specification of basic notation",
ITU-T Recommendation X.680, 2015. ITU-T Recommendation X.680, 2015.
[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
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-02 (work in progress), March draft-ietf-sipbrandy-rtpsec-03 (work in progress), October
2017. 2017.
[I-D.ietf-stir-rfc4474bis] [I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-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,
Version 2.0", June 2017.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002, DOI 10.17487/RFC3325, November 2002,
<https://www.rfc-editor.org/info/rfc3325>. <https://www.rfc-editor.org/info/rfc3325>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004, DOI 10.17487/RFC3840, August 2004,
skipping to change at page 17, line 42 skipping to change at page 19, line 32
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015, RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>. <https://www.rfc-editor.org/info/rfc7516>.
[RFC7701] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi- [RFC7701] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-
party Chat Using the Message Session Relay Protocol party Chat Using the Message Session Relay Protocol
(MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015, (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015,
<https://www.rfc-editor.org/info/rfc7701>. <https://www.rfc-editor.org/info/rfc7701>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
Authors' Addresses Authors' Addresses
Ben Campbell Ben Campbell
Independent Independent
204 Touchdown Dr 204 Touchdown Dr
Irving, TX 75063 Irving, TX 75063
US US
Email: ben@nostrum.com Email: ben@nostrum.com
Russ Housley Russ Housley
 End of changes. 35 change blocks. 
75 lines changed or deleted 170 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/