idnits 2.17.00 (12 Aug 2021) /tmp/idnits56379/draft-campbell-sip-messaging-smime-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC4975, but the abstract doesn't seem to directly say this. It does mention RFC4975 though, so this could be OK. -- The draft header indicates that this document updates RFC3428, but the abstract doesn't seem to directly say this. It does mention RFC3428 though, so this could be OK. -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to directly say this. It does mention RFC3261 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 29, 2017) is 1634 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5750 (Obsoleted by RFC 8550) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) ** Downref: Normative reference to an Informational RFC: RFC 5753 -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' == Outdated reference: draft-ietf-curdle-cms-ecdh-new-curves has been published as RFC 8418 == Outdated reference: draft-ietf-curdle-cms-eddsa-signatures has been published as RFC 8419 == Outdated reference: draft-ietf-sipbrandy-rtpsec has been published as RFC 8862 == Outdated reference: draft-ietf-stir-rfc4474bis has been published as RFC 8224 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Campbell 3 Internet-Draft Independent 4 Updates: RFC 3261, RFC 3428, RFC 4975 R. Housley 5 (if approved) Vigil Security 6 Intended status: Standards Track November 29, 2017 7 Expires: June 2, 2018 9 Securing Session Initiation Protocol (SIP) based Messaging with S/MIME 10 draft-campbell-sip-messaging-smime-01 12 Abstract 14 Mobile messaging applications used with the Session Initiation 15 Protocol (SIP) commonly use some combination of the SIP MESSAGE 16 method and the Message Session Relay Protocol (MSRP). While these 17 provide mechanisms for hop-by-hop security, neither natively provides 18 end-to-end protection. This document offers guidance on how to 19 provide end-to-end authentication, integrity protection, and 20 confidentiality using the Secure/Multipurpose Internet Mail 21 Extensions (S/MIME). It updates and provides clarifications for RFC 22 3261, RFC 3428, and RFC 4975. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 2, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 3 61 4. Applicability of S/MIME . . . . . . . . . . . . . . . . . . . 4 62 4.1. Signed Messages . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Encrypted Messages . . . . . . . . . . . . . . . . . . . 6 64 4.3. Signed and Encrypted Messages . . . . . . . . . . . . . . 7 65 4.4. Certificate Handling . . . . . . . . . . . . . . . . . . 7 66 4.4.1. Subject Alternative Name . . . . . . . . . . . . . . 7 67 4.4.2. Certificate Validation . . . . . . . . . . . . . . . 7 68 5. Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 8 69 6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 8 70 7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 9 71 7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 9 72 7.2. User Agent Capabilities . . . . . . . . . . . . . . . . . 9 73 7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 10 74 8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 10 75 8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 11 77 8.3. Indicating support for S/MIME . . . . . . . . . . . . . . 11 78 8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 12 79 8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 12 80 9. S/MIME Interaction with other SIP Messaging Features . . . . 13 81 9.1. Common Profile for Instant Messaging . . . . . . . . . . 13 82 9.2. Instant Message Delivery Notifications . . . . . . . . . 14 83 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 88 13.2. Informative References . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 Several Mobile Messaging systems use the Session Initiation Protocol 94 (SIP) [RFC3261], typically as some combination of the SIP MESSAGE 95 method [RFC3428] and the Message Session Relay Protocol (MSRP) 96 [RFC4975]. For example, Voice over LTE (VoLTE) uses the SIP MESSAGE 97 method to send Short Message Service (SMS) messages. The Open Mobile 98 Alliance (OMA) Converged IP Messaging (CPM) [CPM], [RCS] system uses 99 the SIP Message Method for short "pager mode" messages and MSRP for 100 large messages and for sessions of messages. The GSM Association 101 (GMSA) rich communication services (RCS) uses CPM for messaging. 103 At the same time, organizations increasingly depend on mobile 104 messaging systems to send notifications to their customers. Many of 105 these notifications are security sensitive. For example, such 106 notifications are commonly used for notice of financial transactions, 107 notice of login or password change attempts, and sending of two- 108 factor authentication codes. 110 Both SIP and MSRP can be used to transport any content using 111 Multipurpose Internet Mail Extensions (MIME) formats. The SIP 112 MESSAGE method is typically limited to short messages (under 1300 113 octets for the MESSAGE request). MSRP can carry arbitrarily large 114 messages, and can break large messages into chunks. 116 While both SIP and MSRP provide mechanisms for hop-by-hop security, 117 neither provides native end-to-end protection. Instead, they depend 118 on S/MIME [RFC5750][RFC5751]. However at the time of this writing, 119 S/MIME is not in common use for SIP and MSRP based messaging 120 services. This document updates and clarifies RFC 3261, RFC 3428, 121 and RFC 4975 in an attempt to make the S/MIME for SIP and MSRP easier 122 to implement and deploy in an interoperable fashion. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119][RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 3. Problem Statement and Scope 134 This document discusses the use of S/MIME with SIP based messaging. 135 Other standardized messaging protocols exist, such as the Extensible 136 Messaging and Presence Protocol (XMPP) [RFC6121]. Likewise, other 137 end-to-end protection formats exist, such as JSON Web Signatures 138 [RFC7515] and JSON Web Encryption [RFC7516]. 140 This document focuses on SIP-based messaging because its use is 141 becoming more common in mobile environments. It focuses on S/MIME 142 since several mobile operating systems already have S/MIME libraries 143 installed. While there may also be value in specifying end-to-end 144 security for other messaging and security mechanisms, it is out of 145 scope for this document. 147 MSRP sessions are negotiated using the Session Description Protocol 148 (SDP) [RFC4566] offer/answer mechanism [RFC3264] or similar 149 mechanisms. This document assumes that SIP is used for the offer/ 150 answer exchange. However, the techniques should be adaptable to 151 other signaling protocols. 153 [RFC3261], [RFC3428], and [RFC4975] already describe the use of 154 S/MIME. [RFC3853] updates SIP to support the Advanced Encryption 155 Standard (AES). In aggregate that guidance is incomplete, contains 156 inconsistencies, and is still out of date in terms of supported and 157 recommended algorithms. 159 The guidance in RFC 3261 is based on an implicit assumption that 160 S/MIME is being used to secure signaling applications. That advice 161 is not entirely appropriate for messaging application. For example, 162 it assumes that message decryption always happens before the SIP 163 transaction completes. 165 This document offers normative updates and clarifications to the use 166 of S/MIME with the SIP MESSAGE method and MSRP. It does not attempt 167 to define a complete secure messaging system. Such system would 168 require considerable work around user enrollment, certificate and key 169 generation and management, multiparty chats, device management, etc. 170 While nothing herein should preclude those efforts, they are out of 171 scope for this document. 173 This document primarily covers the sending of single messages, for 174 example "pager-mode messages" send using the SIP MESSAGE method and 175 "large messages" sent in MSRP. Techniques to use a common signing or 176 encryption key across a session of messages are out of scope for this 177 document, but may be discussed in a future version. 179 Cryptographic algorithm requirements in this document are intended 180 supplement those already specified for SIP and MSRP. 182 4. Applicability of S/MIME 184 The Cryptographic Message Syntax (CMS) [RFC5652] is an encapsulation 185 syntax that is used to digitally sign, digest, authenticate, or 186 encrypt arbitrary message content. The CMS supports a variety of 187 architectures for certificate-based key management, especially the 188 one defined by the IETF PKIX (Public Key Infrastructure using X.509) 189 working group [RFC5280]. The CMS values are generated using ASN.1 190 [X680], using the Basic Encoding Rules (BER) and Distinguished 191 Encoding Rules (DER) [X690]. 193 The S/MIME Message Specification version 3.2 [RFC5751] defines MIME 194 body parts based on the CMS. In this document, the application/ 195 pkcs7-mime media type is used to digitally sign an encapsulated body 196 part, and it is also is used to encrypt an encapsulated body part. 198 4.1. Signed Messages 200 While both SIP and MSRP require support for the multipart/signed 201 format, this document recommends the use of application/pkcs7-mime 202 for most signed messages. Experience with the use of S/MIME in 203 electronic mail has shown that multipart/signed bodies are at greater 204 risk of "helpful" tampering by intermediaries, a common cause of 205 signature validation failure. This risk is also present for 206 messaging applications; for example, intermediaries might insert 207 Instant Message Delivery notification requests into messages (see 208 Section 9.2). The application/pkcs7-mime format is also more 209 compact, which can be important for messaging applications, 210 especially when using the SIP MESSAGE method (see Section 7.1). The 211 use of multipart/signed may still make sense if the message needs to 212 be readable by receiving agents that do not support S/MIME. 214 When generating a signed message, sending user agents (UAs) SHOULD 215 follow the conventions specified in [RFC5751] for the application/ 216 pkcs7-mime media type with smime-type=signed-data. When validating a 217 signed message, receiving UAs MUST follow the conventions specified 218 in [RFC5751] for the application/pkcs7-mime media type with smime- 219 type=signed-data. 221 Sending and receiving UAs MUST support the SHA-256 message digest 222 algorithm [RFC5754]. For convenience, the SHA-256 algorithm 223 identifier is repeated here: 225 id-sha256 OBJECT IDENTIFIER ::= { 226 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 227 csor(3) nistalgorithm(4) hashalgs(2) 1 } 229 Sending and receiving UAs MAY support other message digest 230 algorithms. 232 Sending and receiving UAs MUST support the Elliptic Curve Digital 233 Signature Algorithm (ECDSA) using the NIST P256 elliptic curve and 234 the SHA-256 message digest algorithm [RFC5480][RFC5753]. Sending and 235 receiving UAs SHOULD support the Edwards-curve Digital Signature 236 Algorithm (EdDSA) with curve25519 (Ed25519) 237 [RFC8032][I-D.ietf-curdle-cms-eddsa-signatures]. For convenience, 238 the ECDSA with SHA-256 algorithm identifier, the object identifier 239 for the well-known NIST P256 elliptic curve, and the Ed25519 240 algorithm identifier are repeated here: 242 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 243 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 244 ecdsa-with-SHA2(3) 2 } 246 -- Note: the NIST P256 elliptic curve is also known as secp256r1. 248 secp256r1 OBJECT IDENTIFIER ::= { 249 iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) 250 prime(1) 7 } 252 id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 } 254 4.2. Encrypted Messages 256 When generating an encrypted message, sending UAs MUST follow the 257 conventions specified in [RFC5751] for the application/pkcs7-mime 258 media type with smime-type=enveloped-data. When decrypting a 259 received message, receiving UAs MUST follow the conventions specified 260 in [RFC5751] for the application/pkcs7-mime media type with smime- 261 type=enveloped-data. 263 Sending and receiving UAs MUST support the AES-128-CBC for content 264 encryption [RFC3565]. For convenience, the AES-128-CBC algorithm 265 identifier is repeated here: 267 id-aes128-CBC OBJECT IDENTIFIER ::= { 268 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 269 csor(3) nistAlgorithm(4) aes(1) 2 } 271 Sending and receiving UAs MAY support other content encryption 272 algorithms. 274 Sending and receiving UAs MUST support the AES-128-WRAP for 275 encryption of one AES key with another AES key [RFC3565]. For 276 convenience, the AES-128-WRAP algorithm identifier is repeated here: 278 id-aes128-wrap OBJECT IDENTIFIER ::= { 279 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 280 csor(3) nistAlgorithm(4) aes(1) 5 } 282 Sending and receiving UAs MAY support other key encryption 283 algorithms. 285 Symmetric key-encryption keys can be distributed before messages are 286 sent. If sending and receiving UAs support previously distributed 287 key-encryption keys, then they MUST assign a KEK identifier [RFC5652] 288 to the previously distributed symmetric key. 290 Alternatively, a key agreement algorithm can be used to establish a 291 single-use key-encryption key. If sending and receiving UAs support 292 key agreement, then they MUST support the Elliptic Curve Diffie- 293 Hellman (ECDH) using the NIST P256 elliptic curve and the ANSI- 294 X9.63-KDF key derivation function with the SHA-256 message digest 295 algorithm [RFC5753]. If sending and receiving UAs support key 296 agreement, then they SHOULD support the Elliptic Curve Diffie-Hellman 297 (ECDH) using curve25519 (X25519) 298 [RFC7748][I-D.ietf-curdle-cms-ecdh-new-curves]. For convenience, the 299 ECDH using the ANSI-X9.63-KDF with SHA-256 algorithm identifier and 300 the X25519 algorithm identifier are repeated here: 302 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 303 iso(1) identified-organization(3) certicom(132) 304 schemes(1) 11 1 } 306 id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 } 308 4.3. Signed and Encrypted Messages 310 When generating a signed and encrypted message, sending UAs MUST sign 311 the message first, and then encrypt it. 313 4.4. Certificate Handling 315 Sending and receiving UAs MUST follow the S/MIME certificate handling 316 procedures [RFC5750], with a few exceptions detailed below. 318 4.4.1. Subject Alternative Name 320 The subject alternative name extension is used as the preferred means 321 to convey the SIP URI of a message signer. Any SIP URI present MUST 322 be encoded using the uniformResourceIdentifier CHOICE of the 323 GeneralName type as described in [RFC5280], Section 4.2.1.6. Since 324 the SubjectAltName type is a SEQUENCE OF GeneralName, multiple URIs 325 MAY be present. 327 Open Issue: Should we consider other means of linking the identity to 328 the certificate other than a SIP URI? For example, a specially 329 constructed domain name for a cert issued via an ACME service? One 330 approach might to be to say to use a SIP URI in the absence of other 331 mechanisms. 333 4.4.2. Certificate Validation 335 When validating a certificate, receiving UAs MUST support the 336 Elliptic Curve Digital Signature Algorithm (ECDSA) using the NIST 337 P256 elliptic curve and the SHA-256 message digest algorithm 338 [RFC5480]. 340 Sending and receiving UAs MAY support other digital signature 341 algorithms for certificate validation. 343 5. Transfer Encoding 345 SIP and MSRP UAs are always capable of receiving binary data. Inner 346 S/MIME entities do not require base64 encoding [RFC4648]. 348 Both SIP and MSRP provide 8-bit safe transport channels; base64 349 encoding is not generally needed for the outer S/MIME entities. 350 However, if there is a chance a message might cross a 7-bit transport 351 (for example, gateways that convert to a 7-bit transport for 352 intermediate transfer), base64 encoding may be needed for the outer 353 entity. 355 6. User Agent Capabilities 357 Messaging UAs may implement a subset of S/MIME capabilities. Even 358 when implemented, some features may not be available due to 359 configuration. For example, UAs that do not have user certificates 360 cannot sign messages on behalf of the user or decrypt encrypted 361 messages sent to the user. At a minimum, a UA that supports S/MIME 362 MUST be able to validate a signed message. 364 End-user certificates have long been a barrier to large-scale 365 S/MIME deployment. But since UAs can validate signatures even 366 without local certificates, the use case of organizations sending 367 secure notifications to their users becomes a sort of "low hanging 368 fruit". 370 SIP and MSRP UAs advertise their level of support for S/MIME by 371 indicating their capability to receive the "application/pkcs7-mime" 372 media type. 374 The fact that a UA indicates support for the "multipart/signed" media 375 type does not necessarily imply support for S/MIME. The UA might 376 just be able to display clear-signed content without validating the 377 signature. UAs that wish to indicate the ability to validate 378 signatures for clear-signed messages MUST also indicate support for 379 "application/pkcs7-signature". 381 A UA can indicate that it can receive all smime-types by advertising 382 "application/pkcs7-mime" with no parameters. If a UA does not accept 383 all smime-types, it advertises the media type with the appropriate 384 parameters. If more than one are supported, the UA includes a 385 separate instance of the media-type string, appropriately 386 parameterized, for each. 388 For example, a UA that can only received signed-data would advertise 389 "application/pkcs7-mime; smime-type=signed-data". 391 SIP signaling can fork to multiple destinations for a given Address 392 of Record (AoR). A user might have multiple UAs with different 393 capabilities; the capabilities remembered from an interaction with 394 one such UA might not apply to another. 396 UAs can also advertise or discover S/MIME using out of band 397 mechanisms. Such mechanisms are beyond the scope of this document. 399 7. Using S/MIME with the SIP MESSAGE Method 401 The use of S/MIME with the SIP MESSAGE method is described in section 402 11.3 of [RFC3428], and for SIP in general in section 23 of [RFC3261]. 403 This section and its child sections offer clarifications for the use 404 of S/MIME with the SIP MESSAGE method, along with related updates to 405 RFC 3261 and RFC 3428. 407 7.1. Size Limit 409 SIP MESSAGE requests are typically limited to 1300 octets. That 410 limit applies to the entire message, including both SIP header fields 411 and the message content. This is due to the potential for 412 fragmentation of larger requests sent over UDP. In general, it is 413 hard to be sure that no proxy or other intermediary will forward a 414 SIP request over UDP somewhere along the path. Therefore, S/MIME 415 messages sent via SIP MESSAGE should be kept as small as possible. 417 [RFC3261] says that a SignedData message MUST contain a certificate 418 to be used to validate the signature. In order to reduce the message 419 size, this document updates that to say that a SignedData message 420 sent in a SIP MESSAGE request SHOULD contain the certificate, but MAY 421 omit it if the sender has reason to believe that the recipient 422 already has the certificate in its keychain, or has some other method 423 of accessing the certificate. 425 7.2. User Agent Capabilities 427 SIP user agents (UA) can indicate support for S/MIME by including the 428 appropriate media type or types in the SIP Accept header field in a 429 response to an OPTIONS request, or in a 415 response to a SIP request 430 that contained an unsupported media type in the body. 432 UAs might be able to use the user agent capabilities framework 433 [RFC3840] to indicate support. However doing so would require the 434 registration of one or more media feature tags with IANA. 436 UAs MAY use other out-of-band methods to indicate their level of 437 support for S/MIME. 439 7.3. Failure Cases 441 [RFC3261] requires that the recipient of a SIP request that includes 442 a body part of an unsupported media type and a Content-Disposition 443 header "handling" parameter of "required" return a 415 "Unsupported 444 Media Type" response. Given that SIP MESSAGE exists for no reason 445 other than to deliver content in the body, it is reasonable to treat 446 the top-level body part as always required. However [RFC3428] makes 447 no such assertion. This document updates [RFC3428] to say that a UAC 448 that receives a SIP MESSAGE request with an unsupported media type 449 MUST return a 415 Unsupported Media Type" response. 451 [RFC3261] says that if a recipient receives an S/MIME body encrypted 452 to the wrong certificate, it MUST return a SIP 493 (Undecipherable) 453 response, and SHOULD send a valid certificate in that response. This 454 is not always possible in practice for SIP MESSAGE requests. The 455 User Agent Server (UAS) may choose not to decrypt a message until the 456 user is ready to read it. Messages may be delivered to a message 457 store, or sent via a store-and-forward service. This document 458 updates RFC 3261 to say that the UAS SHOULD return a SIP 493 response 459 if it immediately attempts to decrypt the message and determines the 460 message was encrypted to the wrong certificate. However, it MAY 461 return a 2XX class response if decryption is deferred. 463 8. Using S/MIME with MSRP 465 MSRP has features that interact with the use of S/MIME. In 466 particular, the ability to send messages in chunks, the ability to 467 send messages of unknown size, and the use of SDP to indicate media- 468 type support create considerations for the use of S/MIME. 470 8.1. Chunking 472 MSRP allows a message to be broken into "chunks" for transmission. 473 In this context, the term "message" refers to an entire message that 474 one user might send to another. A chunk is a fragment of that 475 message sent in a single MSRP SEND request. All of the chunks that 476 make up a particular message share the same Message-ID value. 478 The sending user agent may break a message into chunks, which the 479 receiving user agent will reassemble to form the complete message. 481 Intermediaries such as MSRP Relays [RFC4976] might break chunks into 482 smaller chunks, or might reassemble chunks into larger ones; 483 therefore the message received by the recipient may be broken into a 484 different number of chunks than were sent by the recipient. 485 Intermediaries might also cause chunks to be received in a different 486 order than sent. 488 The sender MUST apply any S/MIME operations to the whole message 489 prior to breaking it into chunks. Likewise, the receiver needs to 490 reassemble the message from its chunks prior to decrypting, 491 validating a signature, etc. 493 MSRP chunks are framed using an end-line. The end-line comprises 494 seven hyphens, a 64-bit random value taken from the start line, and a 495 continuation flag. MRSP requires the sending user agent to scan data 496 sent in a specific chunk to be sent ensure that the end-line does not 497 accidentally occur as part of the sent data. This scanning occurs on 498 a chunk rather than a whole message, consequently it must occur after 499 the sender applies any S/MIME operations. 501 8.2. Streamed Data 503 MSRP allows a mode of operation where a UA sends some chunks of a 504 message prior to knowing the full length of the message. For 505 example, a sender might send streamed data over MSRP as a single 506 message, even though it doesn't know the full length of that data in 507 advance. This mode is incompatible with S/MIME, since a sending UA 508 must apply S/MIME operations to the entire message in advance of 509 breaking it into chunks. 511 Therefore, when sending a message in an S/MIME format, the sender 512 MUST include the Byte-Range header field for every chunk, including 513 the first chunk. The Byte-Range header field MUST include the total 514 length of the message. 516 A higher layer could choose to break such streamed data into a series 517 of messages prior to applying S/MIME operation, so that each fragment 518 appears as a distinct S/MIME separate message in MSRP. Such 519 mechanisms are beyond the scope for this document. 521 8.3. Indicating support for S/MIME 523 A UA that supports this specification MUST explicitly include the 524 appropriate media type or types in the "accept-types" attribute in 525 any SDP offer or answer that proposes MSRP. It MAY indicate that it 526 requires S/MIME wrappers for all messages by putting appropriate 527 S/MIME media types in the "accept-types" attribute and putting all 528 other supported media types in the "accept-wrapped-types" attribute. 530 For backwards compatibility, a sender MAY treat a peer that includes 531 an asterisk ("*") in the "accept-types" attribute as potentially 532 supporting S/MIME. If the peer returns an MSRP 415 response to an 533 attempt to send an S/MIME message, the sender should treat the peer 534 as not supporting S/MIME for the duration of the session, as 535 indicated in [RFC4975]. 537 While these SDP attributes allow an endpoint to express support for 538 certain media types only when wrapped in a specified envelope type, 539 it does not allow the expression of more complex structures. For 540 example, an endpoint can say that it supports text/plain and text/ 541 html, but only when inside an application/pkcs7 or message/cpim 542 container, but it cannot express a requirement for the leaf types to 543 always be contained in an application/pkcs7 container nested inside a 544 message/cpim container. This has implications for the use of s/mime 545 with the message/cpim format. (See Section 9.1.) 547 MSRP allows multiple reporting modes that provide different levels of 548 feedback. If the sender includes a Failure-Report header field with 549 a value of "no", it will not receive failure reports. This mode 550 should not be used carelessly, since such a sender would never see a 551 415 response as described above, and would have no way to learn that 552 the recipient could not process an S/MIME body. 554 8.4. MSRP URIs 556 MSRP URIs are ephemeral. Endpoints MUST NOT use MSRP URIs to 557 identify certificates, or insert MSRP URIs into certificate Subject 558 Alternative Name fields. When MSRP sessions are negotiated using SIP 559 [RFC3261], the SIP Addresses of Record (AoRs) of the peers are used 560 instead. 562 Note that MSRP allows messages to be sent between peers in either 563 direction. A given MSRP message might be sent from the SIP offerer 564 to the SIP answer. Thus, the the sender and recipient roles may 565 reverse between one message and another in a given session. 567 8.5. Failure Cases 569 Successful delivery of an S/MIME message does not indicate that the 570 recipient successfully decrypted the contents or validated a 571 signature. Decryption and/or validation may not occur immediately on 572 receipt, since since the recipient may not immediately view the 573 message, and the user agent may choose not to attempt decryption or 574 validation until the user requests it. 576 Likewise, successful delivery of S/MIME enveloped data does not, on 577 its own, indicate that the recipient supports the enclosed media 578 type. If the peer only implicitly indicated support for the enclosed 579 media type through the use of a wildcard in the "accept-types" or 580 "accept-wrapped types" SDP attributes, it may not decrypt the message 581 in time to send a 415 response. 583 9. S/MIME Interaction with other SIP Messaging Features 585 9.1. Common Profile for Instant Messaging 587 The Common Profile for Instant Messaging (CPIM) [RFC3860] defines an 588 abstract messaging service, with the goal of creating gateways 589 between different messaging protocols that could relay instant 590 messages without change. The SIP MESSAGE method and MSRP were 591 initially designed to map to the CPIM abstractions. However, at the 592 time of this writing, CPIM compliant gateways have not been deployed. 593 To the authors' knowledge, no other IM protocols have been explicitly 594 mapped to CPIM. 596 CPIM also defines the abstract messaging URI scheme "im:". As of the 597 time of this writing, the "im:" scheme is not in common use. The use 598 of "im:" URIs as subject alternative names in certificates is for 599 future study. 601 The Common Profile for Instant Messages Message Format [RFC3862] 602 allows UAs to attach transport-neutral metadata to arbitrary MIME 603 content. The format was designed as a canonicalization format to 604 allow signed data to cross protocol-converting gateways without loss 605 of metadata needed to verify the signature. While it has not 606 typically been used for that purpose, it has been used for other 607 metadata applications, for example, Intant Message Delivery 608 Notifications (IMDN)[RFC5438] and MSRP Multi-party Chat [RFC7701] 610 In the general case, a sender applies end-to-end signature and 611 encryption operations to the entire MIME body. However, some 612 messaging systems expect to inspect and in some cases add or modify 613 metadata in CPIM header fields. For example, CPM and RCS based 614 service include application servers that may need to insert time 615 stamps into chat messages, and may use additional metadata to 616 characterize the content and purpose of a message to determine 617 application behavior. The former will cause validation failure for 618 signatures that cover CPIM metadata, while the latter is not possible 619 if the metadata is encrypted. Clients intended for use in such 620 networks MAY choose to apply end-to-end signatures and encryption 621 operations to only the CPIM payload, leaving the CPIM metadata 622 unprotected from inspection and modification. 624 If such clients need to provide encrypt or sign CPIM metadata end-to- 625 end, they can nest a protected CPIM message format payload inside an 626 unprotected CPIM message envelope. 628 The use of CPIM metadata fields to identify certificates or to 629 authenticate SIP or MSRP header fields is out of scope for this 630 document. 632 9.2. Instant Message Delivery Notifications 634 The Instant Message Delivery Notification (IMDN) mechanism[RFC5438] 635 allows both endpoints and intermediary application servers to request 636 and to generate delivery notifications. The use of S/MIME does not 637 impact strictly end-to-end use of IMDN. IMDN recommends that devices 638 that are capable of doing so sign delivery notifications. It further 639 requires that delivery notifications that result from encrypted 640 messages also be encrypted. 642 However, IMDN allows intermediary application servers to insert 643 notification requests into messages, to add routing information to 644 messages, and to act on notification requests. It also allows list 645 servers to aggregate delivery notifications. 647 Such intermediaries will be unable to read end-to-end encrypted 648 messages in order to interpret delivery notice requests. 649 Intermediaries that insert information into end-to-end signed 650 messages will cause the signature validation to fail. (See 651 Section 9.1.) 653 10. Examples 655 Examples will be added in a future version of this document. 657 11. IANA Considerations 659 This document makes no requests of the IANA. 661 12. Security Considerations 663 The security considerations from S/MIME [RFC5750][RFC5751] and 664 elliptic curves in CMS [RFC5753] apply. The S/MIME related security 665 considerations from SIP [RFC3261][RFC3853], SIP MESSAGE [RFC3428], 666 and MSRP [RFC4975] apply. 668 This document assumes that end-entity certificate validation is 669 provided by a chain of trust to a certification authority (CA), using 670 a public key infrastructure. The security considerations from 671 [RFC5280] apply. However, other validations methods may be possible; 672 for example sending a signed fingerprint for the end-entity in SDP. 673 The relationship of this work and the techniques discussed in 674 [RFC4474], [I-D.ietf-stir-rfc4474bis], and 675 [I-D.ietf-sipbrandy-rtpsec] are for future study. 677 When matching an end-entity certificate to the sender or recipient 678 identity, the respective SIP AoRs are used. Typically these will 679 match the SIP From and To header fields. Matching SIP AoRs from 680 other header fields, for example, P-Asserted-Identity [RFC3325], is 681 for future study. 683 The secure notification use case discussed in Section 1 has 684 significant vulnerabilities when used in an insecure environment. 685 For example, "phishing" messages could be used to trick users into 686 revealing credentials. Eavesdroppers could learn confirmation codes 687 from unprotected two-factor authentication messages. Unsolicited 688 messages sent by impersonators could tarnish the reputation of an 689 organization. While hop-by-hop protection can mitigate some of those 690 risks, it still leaves messages vulnerabile to malicious or 691 compromised intermediaries. 693 Mobile messaging is typically an online application; online 694 certificate revocation checks should usually be feasible. 696 Certain messaging services, for example those based on CPM and RCS, 697 may include intermediaries that attach metadata to user generated 698 messages. In certain cases this metadata may reveal information to 699 third parties that would have otherwise been encrypted. Implementors 700 and operators should consider whether this metadata may create 701 privacy leaks. Such an analysis is beyond the scope of this 702 document. 704 13. References 706 13.1. Normative References 708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 709 Requirement Levels", BCP 14, RFC 2119, 710 DOI 10.17487/RFC2119, March 1997, 711 . 713 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 714 A., Peterson, J., Sparks, R., Handley, M., and E. 715 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 716 DOI 10.17487/RFC3261, June 2002, 717 . 719 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 720 with Session Description Protocol (SDP)", RFC 3264, 721 DOI 10.17487/RFC3264, June 2002, 722 . 724 [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., 725 Huitema, C., and D. Gurle, "Session Initiation Protocol 726 (SIP) Extension for Instant Messaging", RFC 3428, 727 DOI 10.17487/RFC3428, December 2002, 728 . 730 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 731 Encryption Algorithm in Cryptographic Message Syntax 732 (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, 733 . 735 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 736 Requirement for the Session Initiation Protocol (SIP)", 737 RFC 3853, DOI 10.17487/RFC3853, July 2004, 738 . 740 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 741 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 742 July 2006, . 744 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 745 "The Message Session Relay Protocol (MSRP)", RFC 4975, 746 DOI 10.17487/RFC4975, September 2007, 747 . 749 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 750 Housley, R., and W. Polk, "Internet X.509 Public Key 751 Infrastructure Certificate and Certificate Revocation List 752 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 753 . 755 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 756 "Elliptic Curve Cryptography Subject Public Key 757 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 758 . 760 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 761 RFC 5652, DOI 10.17487/RFC5652, September 2009, 762 . 764 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 765 Mail Extensions (S/MIME) Version 3.2 Certificate 766 Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, 767 . 769 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 770 Mail Extensions (S/MIME) Version 3.2 Message 771 Specification", RFC 5751, DOI 10.17487/RFC5751, January 772 2010, . 774 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 775 Cryptography (ECC) Algorithms in Cryptographic Message 776 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 777 2010, . 779 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 780 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 781 2010, . 783 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 784 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 785 May 2017, . 787 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 788 One (ASN.1): Specification of basic notation", 789 ITU-T Recommendation X.680, 2015. 791 [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: 792 Specification of Basic Encoding Rules (BER), Canonical 793 Encoding Rules (CER) and Distinguished Encoding Rules 794 (DER)", ITU-T Recommendation X.690, 2015. 796 13.2. Informative References 798 [CPM] Open Mobile Alliance, "OMA Converged IP Messaging System 799 Description, Candidate Version 2.2", September 2017. 801 [I-D.ietf-curdle-cms-ecdh-new-curves] 802 Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key 803 Agreement Algorithm with X25519 and X448 in the 804 Cryptographic Message Syntax (CMS)", draft-ietf-curdle- 805 cms-ecdh-new-curves-10 (work in progress), August 2017. 807 [I-D.ietf-curdle-cms-eddsa-signatures] 808 Housley, R., "Use of EdDSA Signatures in the Cryptographic 809 Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa- 810 signatures-08 (work in progress), October 2017. 812 [I-D.ietf-sipbrandy-rtpsec] 813 Peterson, J., Rescorla, E., Barnes, R., and R. Housley, 814 "Best Practices for Securing RTP Media Signaled with SIP", 815 draft-ietf-sipbrandy-rtpsec-03 (work in progress), October 816 2017. 818 [I-D.ietf-stir-rfc4474bis] 819 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 820 "Authenticated Identity Management in the Session 821 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 822 (work in progress), February 2017. 824 [RCS] GSMA, "RCS Universal Profile Service Definition Document, 825 Version 2.0", June 2017. 827 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 828 Extensions to the Session Initiation Protocol (SIP) for 829 Asserted Identity within Trusted Networks", RFC 3325, 830 DOI 10.17487/RFC3325, November 2002, 831 . 833 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 834 "Indicating User Agent Capabilities in the Session 835 Initiation Protocol (SIP)", RFC 3840, 836 DOI 10.17487/RFC3840, August 2004, 837 . 839 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 840 (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004, 841 . 843 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 844 Messaging (CPIM): Message Format", RFC 3862, 845 DOI 10.17487/RFC3862, August 2004, 846 . 848 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 849 Authenticated Identity Management in the Session 850 Initiation Protocol (SIP)", RFC 4474, 851 DOI 10.17487/RFC4474, August 2006, 852 . 854 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 855 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 856 . 858 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 859 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 860 DOI 10.17487/RFC4976, September 2007, 861 . 863 [RFC5438] Burger, E. and H. Khartabil, "Instant Message Disposition 864 Notification (IMDN)", RFC 5438, DOI 10.17487/RFC5438, 865 February 2009, . 867 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 868 Protocol (XMPP): Instant Messaging and Presence", 869 RFC 6121, DOI 10.17487/RFC6121, March 2011, 870 . 872 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 873 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 874 2015, . 876 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 877 RFC 7516, DOI 10.17487/RFC7516, May 2015, 878 . 880 [RFC7701] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi- 881 party Chat Using the Message Session Relay Protocol 882 (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015, 883 . 885 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 886 for Security", RFC 7748, DOI 10.17487/RFC7748, January 887 2016, . 889 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 890 Signature Algorithm (EdDSA)", RFC 8032, 891 DOI 10.17487/RFC8032, January 2017, 892 . 894 Authors' Addresses 896 Ben Campbell 897 Independent 898 204 Touchdown Dr 899 Irving, TX 75063 900 US 902 Email: ben@nostrum.com 903 Russ Housley 904 Vigil Security 905 918 Spring Knoll Drive 906 Herndon, VA 20170 907 US 909 Email: housley@vigilsec.com