Skip to main content

Securing Session Initiation Protocol (SIP) based Messaging with S/MIME
draft-campbell-sip-messaging-smime-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8591.
Authors Ben Campbell , Russ Housley
Last updated 2017-10-30
RFC stream (None)
Formats
Reviews
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 8591 (Proposed Standard)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-campbell-sip-messaging-smime-00
Network Working Group                                        B. Campbell
Internet-Draft                                               Independent
Updates: RFC 3261, RFC 3428, RFC 4975                         R. Housley
         (if approved)                                    Vigil Security
Intended status: Standards Track                        October 30, 2017
Expires: May 3, 2018

 Securing Session Initiation Protocol (SIP) based Messaging with S/MIME
                 draft-campbell-sip-messaging-smime-00

Abstract

   Mobile messaging applications used with the Session Initiation
   Protocol (SIP) commonly use some combination of the SIP MESSAGE
   method and the Message Session Relay Protocol (MSRP).  While these
   provide mechanisms for hop-by-hop security, neither natively provides
   end-to-end protection.  This document offers guidance on how to
   provide end-to-end authentication, integrity protection, and
   confidentiality using the Secure/Multipurpose Internet Mail
   Extensions (S/MIME).  It updates and provides clarifications for RFC
   3261, RFC 3428, and RFC 4975.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 3, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of

Campbell & Housley         Expires May 3, 2018                  [Page 1]
Internet-Draft          S/MIME for SIP Messaging            October 2017

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Scope of This Document  . . . . . . . . . . . . . . . . . . .   4
   4.  Applicability of S/MIME . . . . . . . . . . . . . . . . . . .   4
     4.1.  Signed Messages . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Encrypted Messages  . . . . . . . . . . . . . . . . . . .   5
     4.3.  Signed and Encrypted Messages . . . . . . . . . . . . . .   6
     4.4.  Certificate Handling  . . . . . . . . . . . . . . . . . .   7
       4.4.1.  Subject Alternative Name  . . . . . . . . . . . . . .   7
       4.4.2.  Certificate Validation  . . . . . . . . . . . . . . .   7
   5.  Transfer Encoding . . . . . . . . . . . . . . . . . . . . . .   7
   6.  User Agent Capabilities . . . . . . . . . . . . . . . . . . .   7
   7.  Using S/MIME with the SIP MESSAGE Method  . . . . . . . . . .   8
     7.1.  Size Limit  . . . . . . . . . . . . . . . . . . . . . . .   8
     7.2.  User Agent Capabilities . . . . . . . . . . . . . . . . .   9
     7.3.  Failure Cases . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Using S/MIME with MSRP  . . . . . . . . . . . . . . . . . . .  10
     8.1.  Chunking  . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.2.  Streamed Data . . . . . . . . . . . . . . . . . . . . . .  10
     8.3.  Indicating support for S/MIME . . . . . . . . . . . . . .  11
     8.4.  MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.5.  Failure Cases . . . . . . . . . . . . . . . . . . . . . .  12
   9.  S/MIME Interaction with other SIP Messaging Features  . . . .  12
     9.1.  Common Profile for Instant Messaging  . . . . . . . . . .  12
     9.2.  Instant Message Delivery Notifications  . . . . . . . . .  13
   10. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     13.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   Several Mobile Messaging systems use the Session Initiation Protocol
   (SIP) [RFC3261], typically as some combination of the SIP MESSAGE
   method [RFC3428] and the Message Session Relay Protocol (MSRP)
   [RFC4975].  For example, VoLTE uses the SIP MESSAGE method to send

Campbell & Housley         Expires May 3, 2018                  [Page 2]
Internet-Draft          S/MIME for SIP Messaging            October 2017

   Short Message Service (SMS) messages.  The Open Mobile Alliance (OMA)
   Converged IP Messaging (CPM) system uses the SIP Message Method for
   short "pager mode" messages and MSRP for large messages and for
   sessions of messages.  The GSM Association (GMSA) rich communication
   services (RCS) uses CPM for messaging.

   At the same time, organizations increasingly depend on mobile
   messaging systems to send notifications to their customers.  Many of
   these notifications are security sensitive.  For example, such
   notifications are commonly used for notice of financial transactions,
   notice of login or password change attempts, and sending of two-
   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
   Multipurpose Internet Mail Extensions (MIME) formats.  The SIP
   MESSAGE method is typically limited to short messages (under 1300
   octets for the MESSAGE request).  MSRP can carry arbitrarily large
   messages, and can break large messages into chunks.

   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.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Campbell & Housley         Expires May 3, 2018                  [Page 3]
Internet-Draft          S/MIME for SIP Messaging            October 2017

3.  Scope of This Document

   This document discusses the use of S/MIME with SIP based messaging.
   Other standardized messaging protocols exist, such as the Extensible
   Messaging and Presence Protocol (XMPP) [RFC6121].  Likewise, other
   end-to-end protection formats exist, such as JSON Web Signatures
   [RFC7515] and JSON Web Encryption [RFC7516].

   This document focuses on SIP-based messaging because its use is
   becoming more common in mobile environments.  It focuses on S/MIME
   since several mobile operating systems already have S/MIME libraries
   installed.  While there may also be value in specifying end-to-end
   security for other messaging and security mechanisms, it is out of
   scope for this document.

   This document primarily covers the sending of single messages, for
   example "pager-mode messages" send using the SIP MESSASGE method and
   "large messages" sent in MSRP.  Techniques to use a common signing or
   encryption across a session of messages are out of scope for this
   document, but may be discussed in a future version.

   Cryptographic algorithm requirements in this document are intended
   supplement those of SIP and MSRP.

4.  Applicability of S/MIME

   The Cryptographic Message Syntax (CMS) [RFC5652] is an encapsulation
   syntax that is used to digitally sign, digest, authenticate, or
   encrypt arbitrary message content.  The CMS supports a variety of
   architectures for certificate-based key management, especially the
   one defined by the IETF PKIX (Public Key Infrastructure using X.509)
   working group [RFC5280].  The CMS values are generated using ASN.1
   [X680], using the Basic Encoding Rules (BER) and Distinguished
   Encoding Rules (DER) [X690].

   The S/MIME Message Specification [RFC5751] defines MIME body parts
   based on the CMS.  In this document, the application/pkcs7-mime media
   type is used to digitally sign an encapsulated body part, and it is
   also is used to encrypt an encapsulated body part.

4.1.  Signed Messages

   While both SIP and MSRP require support for the multipart/signed
   format, this document recommends the use of application/pkcs7-mime
   for most signed messages.  Experience with the use of S/MIME in
   electronic mail has shown that multipart/signed bodies are at greater
   risk of "helpful" tampering by intermediaries, a common cause of
   signature validation failure.  This risk is also present for

Campbell & Housley         Expires May 3, 2018                  [Page 4]
Internet-Draft          S/MIME for SIP Messaging            October 2017

   messaging applications; for example, intermediaries might insert
   Instant Message Delivery notification requests into messages (see
   Section 9.2).  The application/pkcs7-mime format is also more
   compact, which can be important for messaging applications,
   especially when using the SIP MESSAGE method (see Section 7.1).  The
   use of multipart/signed may still make sense if the message needs to
   be readable by receiving agents that do not support S/MIME.

   When generating a signed message, sending user agents (UAs) SHOULD
   follow the conventions specified in [RFC5751] for the application/
   pkcs7-mime media type with smime-type=signed-data.  When validating a
   signed message, receiving UAs MUST follow the conventions specified
   in [RFC5751] for the application/pkcs7-mime media type with smime-
   type=signed-data.

   Sending and receiving UAs MUST support the SHA-256 message digest
   algorithm [RFC5754].  For convenience, the SHA-256 algorithm
   identifier is repeated here:

       id-sha256 OBJECT IDENTIFIER ::= {
         joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
         csor(3) nistalgorithm(4) hashalgs(2) 1 }

   Sending and receiving UAs MAY support other message digest
   algorithms.

   Sending and receiving UAs MUST support the Elliptic Curve Digital
   Signature Algorithm (ECDSA) using the NIST P256 elliptic curve and
   the SHA-256 message digest algorithm [RFC5480][RFC5753].  For
   convenience, the ECDSA with SHA-256 algorithm identifier and the
   object identifier for the well-known NIST P256 elliptic curve are
   repeated here:

       ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
         iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
         ecdsa-with-SHA2(3) 2 }

       -- Note: the NIST P256 elliptic curve is also known as secp256r1.

       secp256r1 OBJECT IDENTIFIER ::= {
         iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
         prime(1) 7 }

4.2.  Encrypted Messages

   When generating an encrypted message, sending UAs MUST follow the
   conventions specified in [RFC5751] for the application/pkcs7-mime
   media type with smime-type=enveloped-data.  When decrypting a

Campbell & Housley         Expires May 3, 2018                  [Page 5]
Internet-Draft          S/MIME for SIP Messaging            October 2017

   received message, receiving UAs MUST follow the conventions specified
   in [RFC5751] for the application/pkcs7-mime media type with smime-
   type=enveloped-data.

   Sending and receiving UAs MUST support the AES-128-CBC for content
   encryption [RFC3565].  For convenience, the AES-128-CBC algorithm
   identifier is repeated here:

       id-aes128-CBC OBJECT IDENTIFIER ::=  {
         joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
         csor(3) nistAlgorithm(4) aes(1) 2 }

   Sending and receiving UAs MAY support other content encryption
   algorithms.

   Sending and receiving UAs MUST support the AES-128-WRAP for
   encryption of one AES key with another AES key [RFC3565].  For
   convenience, the AES-128-WRAP algorithm identifier is repeated here:

       id-aes128-wrap OBJECT IDENTIFIER ::=  {
         joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
         csor(3) nistAlgorithm(4) aes(1) 5 }

   Sending and receiving UAs MAY support other key encryption
   algorithms.

   Symmetric key-encryption keys can be distributed before messages are
   sent.  If sending and receiving UAs support previously distributed
   key-encryption keys, then they MUST assign a KEK identifier [RFC5652]
   to the previously distributed symmetric key.

   Alternatively, a key agreement algorithm can be used to establish a
   single-use key-encryption key.  If sending and receiving UAs support
   key agreement, then they MUST the Elliptic Curve Diffie-Hellman
   (ECDH) using the NIST P256 elliptic curve and the ANSI-X9.63-KDF key
   derivation function with the SHA-256 message digest algorithm
   [RFC5753].  For convenience, the ECDH using the ANSI-X9.63-KDF with
   SHA-256 algorithm identifier is repeated here:

        dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
          iso(1) identified-organization(3) certicom(132)
          schemes(1) 11 1 }

4.3.  Signed and Encrypted Messages

   When generating a signed and encrypted message, sending UAs MUST sign
   the message first, and then encrypt it.

Campbell & Housley         Expires May 3, 2018                  [Page 6]
Internet-Draft          S/MIME for SIP Messaging            October 2017

4.4.  Certificate Handling

   Sending and receiving UAs MUST follow the S/MIME certificate handling
   procedures [RFC5750], with a few exceptions detailed below.

4.4.1.  Subject Alternative Name

   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
   be encoded using the uniformResourceIdentifier CHOICE of the
   GeneralName type as described in [RFC5280], Section 4.2.1.6.  Since
   the SubjectAltName type is a SEQUENCE OF GeneralName, multiple URIs
   MAY be present.

4.4.2.  Certificate Validation

   When validating a certificate, receiving UAs MUST support the
   Elliptic Curve Digital Signature Algorithm (ECDSA) using the NIST
   P256 elliptic curve and the SHA-256 message digest algorithm
   [RFC5480].

   Sending and receiving UAs MAY support other digital signature
   algorithms for certificate validation.

5.  Transfer Encoding

   SIP and MSRP UAs are always capable of receiving binary data.  Inner
   S/MIME entities do not require base64 encoding [RFC4648].

   Both SIP and MSRP provide 8-bit safe transport channels; base64
   encoding is not generally needed for the outer S/MIME entities.
   However, if there is a chance a message might cross a 7-bit transport
   (for example, gateways that convert to a 7-bit transport for
   intermediate transfer), base64 encoding may be needed for the outer
   entity.

6.  User Agent Capabilities

   Messaging UAs may implement a subset of S/MIME capabilities.  Even
   when implemented, some features may not be available due to
   configuration.  For example, UAs that do not have user certificates
   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
   MUST be able to validate a signed message.

      End-user certificates have long been a barrier to large-scale
      S/MIME deployment.  But since UAs can validate signatures even
      without local certificates, the use case of organizations sending

Campbell & Housley         Expires May 3, 2018                  [Page 7]
Internet-Draft          S/MIME for SIP Messaging            October 2017

      secure notifications to their users becomes a sort of "low hanging
      fruit".

   SIP and MSRP UAs advertise their level of support for S/MIME by
   indicating their capability to receive the "application/pkcs7-mime"
   media type.

   The fact that a UA indicates support for the "multipart/signed" media
   type does not necessarily imply support for S/MIME.  The UA might
   just be able to display clear-signed content without validating the
   signature.  UAs that wish to indicate the ability to validate
   signatures for clear-signed messages MUST also indicate support for
   "application/pkcs7-signature".

   A UA can indicate that it can receive all smime-types by advertising
   "application/pkcs7-mime" with no parameters.  If a UA does not accept
   all smime-types, it advertises the media type with the appropriate
   parameters.  If more than one are supported, the UA includes a
   separate instance of the media-type string, appropriately
   parameterized, for each.

   For example, a UA that can only received signed-data would advertise
   "application/pkcs7-mime; smime-type=signed-data".

   SIP signaling can fork to multiple destinations for a given Address
   of Record (AoR).  A user might have multiple UAs with different
   capabilities; the capabilities remembered from an interaction with
   one such UA might not apply to another.

   UAs can also advertise or discover S/MIME using out of band
   mechanisms.  Such mechanisms are beyond the scope of this document.

7.  Using S/MIME with the SIP MESSAGE Method

   The use of S/MIME with the SIP MESSAGE method is described in section
   11.3 of [RFC3428], and for SIP in general in section 23 of [RFC3261].
   This section and its child sections offer clarifications for the use
   of S/MIME with the SIP MESSAGE method, along with related updates to
   RFC 3261 and RFC 3428.

7.1.  Size Limit

   SIP MESSAGE requests are typically limited to 1300 octets.  That
   limit applies to the entire message, including both SIP header fields
   and the message content.  This is due to the potential for
   fragmentation of larger requests sent over UDP.  In general, it is
   hard to be sure that no proxy or other intermediary will forward a

Campbell & Housley         Expires May 3, 2018                  [Page 8]
Internet-Draft          S/MIME for SIP Messaging            October 2017

   SIP request over UDP somewhere along the path.  Therefore, S/MIME
   messages sent via SIP MESSAGE should be kept as small as possible.

   [RFC3261] says that a SignedData message MUST contain a certificate
   to be used to validate the signature.  In order to reduce the message
   size, this document updates that to say that a SignedData message
   sent in a SIP MESSAGE request SHOULD contain the certificate, but MAY
   omit it if the sender has reason to believe that the recipient
   already has the certificate in its keychain, or has some other method
   of accessing the certificate.

7.2.  User Agent Capabilities

   SIP user agents (UA) can indicate support for S/MIME by including the
   appropriate media type or types in the SIP Accept header field in a
   response to an OPTIONS request, or in a 415 response to a SIP request
   that contained an unsupported media type in the body.

   UAs might be able to use the user agent capabilities framework
   [RFC3840] to indicate support.  However doing so would require the
   registration of one or more media feature tags with IANA.

   UAs MAY use other out-of-band methods to indicate their level of
   support for S/MIME.

7.3.  Failure Cases

   [RFC3261] requires that the recipient of a SIP request that includes
   a body part of an unsupported media type and a Content-Disposition
   header "handling" parameter of "required" return a 415 "Unsupported
   Media Type" response.  Given that SIP MESSAGE exists for no reason
   other than to deliver content in the body, it is reasonable to treat
   the top-level body part as always required.  However [RFC3428] makes
   no such assertion.  This document updates [RFC3428] to say that a UAC
   that receives a SIP MESSAGE request with an unsupported media type
   MUST return a 415 Unsupported Media Type" response.

   [RFC3261] says that if a recipient receives an S/MIME body encrypted
   to the wrong certificate, it MUST return a SIP 493 (Undecipherable)
   response, and SHOULD send a valid certificate in that response.  This
   is not always possible in practice for SIP MESSAGE requests.  The
   User Agent Server (UAS) may choose not to decrypt a message until the
   user is ready to read it.  Messages may be delivered to a message
   store, or sent via a store-and-forward service.  This document
   updates RFC 3261 to say that the UAS SHOULD return a SIP 493 response
   if it immediately attempts to decrypt the message and determines the
   message was encrypted to the wrong certificate.  However, it MAY
   return a 2XX class response if decryption is deferred.

Campbell & Housley         Expires May 3, 2018                  [Page 9]
Internet-Draft          S/MIME for SIP Messaging            October 2017

8.  Using S/MIME with MSRP

   MSRP has features that interact with the use of S/MIME.  In
   particular, the ability to send messages in chunks, the ability to
   send messages of unknown size, and the use of SDP to indicate media-
   type support create considerations for the use of S/MIME.

8.1.  Chunking

   MSRP allows a message to be broken into "chunks" for transmission.
   In this context, the term "message" refers to an entire message that
   one user might send to another.  A chunk is a fragment of that
   message sent in a single MSRP SEND request.  All of the chunks that
   make up a particular message share the same Message-ID value.

   The sending user agent may break a message into chunks, which the
   receiving user agent will reassemble to form the complete message.
   Intermediaries such as MSRP Relays [RFC4976] might break chunks into
   smaller chunks, or might reassemble chunks into larger ones;
   therefore the message received by the recipient may be broken into a
   different number of chunks than were sent by the recipient.
   Intermediaries might also cause chunks to be received in a different
   order than sent.

   The sender MUST apply any S/MIME operations to the whole message
   prior to breaking it into chunks.  Likewise, the receiver needs to
   reassemble the message from its chunks prior to decrypting,
   validating a signature, etc.

   MSRP chunks are framed using an end-line.  The end-line comprises
   seven hyphens, a 64-bit random value taken from the start line, and a
   continuation flag.  MRSP requires the sending user agent to scan data
   sent in a specific chunk to be sent ensure that the end-line does not
   accidentally occur as part of the sent data.  This scanning occurs on
   a chunk rather than a whole message, consequently it must occur after
   the sender applies any S/MIME operations.

8.2.  Streamed Data

   MSRP allows a mode of operation where a UA sends some chunks of a
   message prior to knowing the full length of the message.  For
   example, a sender might send streamed data over MSRP as a single
   message, even though it doesn't know the full length of that data in
   advance.  This mode is incompatible with S/MIME, since a sending UA
   must apply S/MIME operations to the entire message in advance of
   breaking it into chunks.

Campbell & Housley         Expires May 3, 2018                 [Page 10]
Internet-Draft          S/MIME for SIP Messaging            October 2017

   Therefore, when sending a message in an S/MIME format, the sender
   MUST include the Byte-Range header field for every chunk, including
   the first chunk.  The Byte-Range header field MUST include the total
   length of the message.

   A higher layer could choose to break such streamed data into a series
   of messages prior to applying S/MIME operation, so that each fragment
   appears as a distinct S/MIME separate message in MSRP.  Such
   mechanisms are beyond the scope for this document.

8.3.  Indicating support for S/MIME

   A UA that supports this specification MUST explicitly include the
   appropriate media type or types in the "accept-types" attribute in
   any SDP offer or answer that proposes MSRP.  It MAY indicate that it
   requires S/MIME wrappers for all messages by putting appropriate
   S/MIME media types in the "accept-types" attribute and putting all
   other supported media types in the "accept-wrapped-types" attribute.

   For backwards compatibility, a sender MAY treat a peer that includes
   an asterisk ("*") in the "accept-types" attribute as potentially
   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
   as not supporting S/MIME for the duration of the session, as
   indicated in [RFC4975].

   MSRP allows multiple reporting modes that provide different levels of
   feedback.  If the sender includes a Failure-Report header field with
   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
   415 response as described above, and would have no way to learn that
   the recipient could not process an S/MIME body.

8.4.  MSRP URIs

   MSRP URIs are ephemeral.  Endpoints MUST NOT use MSRP URIs to
   identify certificates, or insert MSRP URIs into certificate Subject
   Alternative Name fields.  When MSRP sessions are negotiated using SIP
   [RFC3261], the SIP Addresses of Record (AoRs) of the peers are used
   instead.

   Note that MSRP allows messages to be sent between peers in either
   direction.  A given MSRP message might be sent from the SIP offerer
   to the SIP answer.  Thus, the the sender and recipient roles may
   reverse between one message and another in a given session.

Campbell & Housley         Expires May 3, 2018                 [Page 11]
Internet-Draft          S/MIME for SIP Messaging            October 2017

8.5.  Failure Cases

   Successful delivery of an S/MIME message does not indicate that the
   recipient successfully decrypted the contents or validated a
   signature.  Decryption and/or validation may not occur immediately on
   receipt, since since the recipient may not immediately view the
   message, and the user agent may choose not to attempt decryption or
   validation until the user requests it.

   Likewise, successful delivery of S/MIME enveloped data does not, on
   its own, indicate that the recipient supports the enclosed media
   type.  If the peer only implicitly indicated support for the enclosed
   media type through the use of a wildcard in the "accept-types" or
   "accept-wrapped types" SDP attributes, it may not decrypt the message
   in time to send a 415 response.

9.  S/MIME Interaction with other SIP Messaging Features

9.1.  Common Profile for Instant Messaging

   The Common Profile for Instant Messaging (CPIM) [RFC3860] defines an
   abstract messaging service, with the goal of creating gateways
   between different messaging protocols that could relay instant
   messages without change.  The SIP MESSAGE method and MSRP were
   initially designed to map to the CPIM abstractions.  However, at the
   time of this writing, CPIM compliant gateways have not been deployed.
   To the authors' knowledge, no other IM protocols have been explicitly
   mapped to CPIM.

   CPIM also defines the abstract messaging URI scheme "im:".  As of the
   time of this writing, the "im:" scheme is not in common use.  The use
   of "im:" URIs as subject alternative names in certificates is for
   future study.

   The Common Profile for Instant Messages Message Format [RFC3862]
   allows UAs to attach transport-neutral metadata to arbitrary MIME
   content.  The format was designed as a canonicalization format to
   allow signed data to cross protocol-converting gateways without loss
   of metadata needed to verify the signature.  While it has not
   typically been used for that purpose, it has been used for other
   metadata applications, for example, Intant Message Delivery
   Notifications (IMDN)[RFC5438] and MSRP Multi-party Chat [RFC7701]

   Signature and encryption operations are typically applied to the
   entire CPIM body part, rather than to just the CPIM payload.  The use
   of CPIM metadata fields to identify certificates or to authenticate
   SIP or MSRP header fields is for further study.

Campbell & Housley         Expires May 3, 2018                 [Page 12]
Internet-Draft          S/MIME for SIP Messaging            October 2017

9.2.  Instant Message Delivery Notifications

   The Instant Message Delivery Notification (IMDN) mechanism[RFC5438]
   allows both endpoints and intermediary application servers to request
   and to generate delivery notifications.  The use of S/MIME does not
   impact strictly end-to-end use of IMDN.  IMDN recommends that devices
   that are capable of doing so sign delivery notifications.  It further
   requires that delivery notifications that result from encrypted
   messages also be encrypted.

   However, IMDN allows intermediary application servers to insert
   notification requests into messages, to add routing information to
   messages, and to act on notification requests.  It also allows list
   servers to aggregate delivery notifications.

   Such intermediaries will be unable to read end-to-end encrypted
   messages in order to interpret delivery notice requests.
   Intermediaries that insert information into end-to-end signed
   messages will cause the signature validation to fail.

10.  Examples

   Examples will be added in a future version of this document.

11.  IANA Considerations

   This document makes no requests of the IANA.

12.  Security Considerations

   The security considerations from S/MIME [RFC5750][RFC5751] and
   elliptic curves in CMS [RFC5753] apply.  The S/MIME related security
   considerations from SIP [RFC3261][RFC3853], SIP MESSAGE [RFC3428],
   and MSRP [RFC4975] apply.

   This document assumes that end-entity certificate validation is
   provided by a chain of trust to certification authority (CA), using a
   public key infrastructure.  The security considerations from
   [RFC5280] apply.  However, other validations methods may be possible;
   for example sending a signed fingerprint for the end-entity in SDP.
   The relationship of this work and the techniques discussed in
   [RFC4474], [I-D.ietf-stir-rfc4474bis], and
   [I-D.ietf-sipbrandy-rtpsec] are for further study.

   When matching an end-entity certificate to the sender or recipient
   identity, the respective SIP AoRs are used.  Typically these will
   match the SIP From and To header fields.  Matching SIP AoRs from

Campbell & Housley         Expires May 3, 2018                 [Page 13]
Internet-Draft          S/MIME for SIP Messaging            October 2017

   other header fields, for example, P-Asserted-Identity [RFC3325], is
   for further study.

   The secure notification use case discussed in Section 1 has
   significant vulnerabilities when used in an insecure environment.
   For example, "phishing" messages could be used to trick users into
   revealing credentials.  Eavesdroppers could learn confirmation codes
   from unprotected two-factor authentication messages.  Unsolicited
   messages sent by impersonators could tarnish the reputation of an
   organization.  While hop-by-hop protection can mitigate some of those
   risks, it still leaves messages vulnerabile to malicious or
   compromised intermediaries.

   Mobile messaging is typically an online application; online
   certificate revocation checks should usually be feasible.

13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <https://www.rfc-editor.org/info/rfc3261>.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <https://www.rfc-editor.org/info/rfc3264>.

   [RFC3428]  Campbell, B., Ed., Rosenberg, J., Schulzrinne, H.,
              Huitema, C., and D. Gurle, "Session Initiation Protocol
              (SIP) Extension for Instant Messaging", RFC 3428,
              DOI 10.17487/RFC3428, December 2002,
              <https://www.rfc-editor.org/info/rfc3428>.

   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
              Encryption Algorithm in Cryptographic Message Syntax
              (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,
              <https://www.rfc-editor.org/info/rfc3565>.

Campbell & Housley         Expires May 3, 2018                 [Page 14]
Internet-Draft          S/MIME for SIP Messaging            October 2017

   [RFC3853]  Peterson, J., "S/MIME Advanced Encryption Standard (AES)
              Requirement for the Session Initiation Protocol (SIP)",
              RFC 3853, DOI 10.17487/RFC3853, July 2004,
              <https://www.rfc-editor.org/info/rfc3853>.

   [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>.

   [RFC4975]  Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
              "The Message Session Relay Protocol (MSRP)", RFC 4975,
              DOI 10.17487/RFC4975, September 2007,
              <https://www.rfc-editor.org/info/rfc4975>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
              <https://www.rfc-editor.org/info/rfc5480>.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/info/rfc5652>.

   [RFC5750]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Certificate
              Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010,
              <https://www.rfc-editor.org/info/rfc5750>.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, DOI 10.17487/RFC5751, January
              2010, <https://www.rfc-editor.org/info/rfc5751>.

   [RFC5753]  Turner, S. and D. Brown, "Use of Elliptic Curve
              Cryptography (ECC) Algorithms in Cryptographic Message
              Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
              2010, <https://www.rfc-editor.org/info/rfc5753>.

   [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic
              Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
              2010, <https://www.rfc-editor.org/info/rfc5754>.

Campbell & Housley         Expires May 3, 2018                 [Page 15]
Internet-Draft          S/MIME for SIP Messaging            October 2017

   [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>.

   [X680]     ITU-T, "Information technology -- Abstract Syntax Notation
              One (ASN.1): Specification of basic notation",
              ITU-T Recommendation X.680, 2015.

   [X690]     ITU-T, "Information Technology -- ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ITU-T Recommendation X.690, 2015.

13.2.  Informative References

   [I-D.ietf-sipbrandy-rtpsec]
              Peterson, J., Rescorla, E., Barnes, R., and R. Housley,
              "Best Practices for Securing RTP Media Signaled with SIP",
              draft-ietf-sipbrandy-rtpsec-02 (work in progress), March
              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.

   [RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
              Extensions to the Session Initiation Protocol (SIP) for
              Asserted Identity within Trusted Networks", RFC 3325,
              DOI 10.17487/RFC3325, November 2002,
              <https://www.rfc-editor.org/info/rfc3325>.

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840,
              DOI 10.17487/RFC3840, August 2004,
              <https://www.rfc-editor.org/info/rfc3840>.

   [RFC3860]  Peterson, J., "Common Profile for Instant Messaging
              (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004,
              <https://www.rfc-editor.org/info/rfc3860>.

   [RFC3862]  Klyne, G. and D. Atkins, "Common Presence and Instant
              Messaging (CPIM): Message Format", RFC 3862,
              DOI 10.17487/RFC3862, August 2004,
              <https://www.rfc-editor.org/info/rfc3862>.

Campbell & Housley         Expires May 3, 2018                 [Page 16]
Internet-Draft          S/MIME for SIP Messaging            October 2017

   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474,
              DOI 10.17487/RFC4474, August 2006,
              <https://www.rfc-editor.org/info/rfc4474>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC4976]  Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
              for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
              DOI 10.17487/RFC4976, September 2007,
              <https://www.rfc-editor.org/info/rfc4976>.

   [RFC5438]  Burger, E. and H. Khartabil, "Instant Message Disposition
              Notification (IMDN)", RFC 5438, DOI 10.17487/RFC5438,
              February 2009, <https://www.rfc-editor.org/info/rfc5438>.

   [RFC6121]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence",
              RFC 6121, DOI 10.17487/RFC6121, March 2011,
              <https://www.rfc-editor.org/info/rfc6121>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <https://www.rfc-editor.org/info/rfc7516>.

   [RFC7701]  Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-
              party Chat Using the Message Session Relay Protocol
              (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015,
              <https://www.rfc-editor.org/info/rfc7701>.

Authors' Addresses

   Ben Campbell
   Independent
   204 Touchdown Dr
   Irving, TX  75063
   US

   Email: ben@nostrum.com

Campbell & Housley         Expires May 3, 2018                 [Page 17]
Internet-Draft          S/MIME for SIP Messaging            October 2017

   Russ Housley
   Vigil Security
   918 Spring Knoll Drive
   Herndon, VA  20170
   US

   Email: housley@vigilsec.com

Campbell & Housley         Expires May 3, 2018                 [Page 18]