idnits 2.17.00 (12 Aug 2021) /tmp/idnits60100/draft-campbell-sip-messaging-smime-00.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 (October 30, 2017) is 1664 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-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 (~~), 4 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 October 30, 2017 7 Expires: May 3, 2018 9 Securing Session Initiation Protocol (SIP) based Messaging with S/MIME 10 draft-campbell-sip-messaging-smime-00 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 May 3, 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. Scope of This Document . . . . . . . . . . . . . . . . . . . 4 61 4. Applicability of S/MIME . . . . . . . . . . . . . . . . . . . 4 62 4.1. Signed Messages . . . . . . . . . . . . . . . . . . . . . 4 63 4.2. Encrypted Messages . . . . . . . . . . . . . . . . . . . 5 64 4.3. Signed and Encrypted Messages . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . 7 69 6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 7 70 7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 8 71 7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 8 72 7.2. User Agent Capabilities . . . . . . . . . . . . . . . . . 9 73 7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 9 74 8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 10 75 8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 10 77 8.3. Indicating support for S/MIME . . . . . . . . . . . . . . 11 78 8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 12 80 9. S/MIME Interaction with other SIP Messaging Features . . . . 12 81 9.1. Common Profile for Instant Messaging . . . . . . . . . . 12 82 9.2. Instant Message Delivery Notifications . . . . . . . . . 13 83 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 88 13.2. Informative References . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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, VoLTE uses the SIP MESSAGE method to send 97 Short Message Service (SMS) messages. The Open Mobile Alliance (OMA) 98 Converged IP Messaging (CPM) system uses the SIP Message Method for 99 short "pager mode" messages and MSRP for large messages and for 100 sessions of messages. The GSM Association (GMSA) rich communication 101 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 While both SIP and MSRP provide mechanisms for hop-by-hop security, 111 neither provides native end-to-end protection. Instead, they depend 112 on S/MIME [RFC5750][RFC5751]. 114 This document updates and provides clarifications to RFC 3261, RFC 115 3428, and RFC 4975. While each of those documents already describes 116 the use of S/MIME to some degree, that guidance contains 117 inconsistencies, and it is out of date in terms of supported and 118 recommended algorithms. The guidance in RFC 3261 is offered in the 119 context of signaling applications, and it is not entirely appropriate 120 for messaging applications. 122 Both SIP and MSRP can be used to transport any content using 123 Multipurpose Internet Mail Extensions (MIME) formats. The SIP 124 MESSAGE method is typically limited to short messages (under 1300 125 octets for the MESSAGE request). MSRP can carry arbitrarily large 126 messages, and can break large messages into chunks. 128 MSRP sessions are negotiated using the Session Description Protocol 129 (SDP) [RFC4566] offer/answer mechanism [RFC3264] or similar 130 mechanisms. This document assumes that SIP is used for the offer/ 131 answer exchange. However, the techniques should be adaptable to 132 other signaling protocols. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119][RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 3. Scope of This Document 144 This document discusses the use of S/MIME with SIP based messaging. 145 Other standardized messaging protocols exist, such as the Extensible 146 Messaging and Presence Protocol (XMPP) [RFC6121]. Likewise, other 147 end-to-end protection formats exist, such as JSON Web Signatures 148 [RFC7515] and JSON Web Encryption [RFC7516]. 150 This document focuses on SIP-based messaging because its use is 151 becoming more common in mobile environments. It focuses on S/MIME 152 since several mobile operating systems already have S/MIME libraries 153 installed. While there may also be value in specifying end-to-end 154 security for other messaging and security mechanisms, it is out of 155 scope for this document. 157 This document primarily covers the sending of single messages, for 158 example "pager-mode messages" send using the SIP MESSASGE method and 159 "large messages" sent in MSRP. Techniques to use a common signing or 160 encryption across a session of messages are out of scope for this 161 document, but may be discussed in a future version. 163 Cryptographic algorithm requirements in this document are intended 164 supplement those of SIP and MSRP. 166 4. Applicability of S/MIME 168 The Cryptographic Message Syntax (CMS) [RFC5652] is an encapsulation 169 syntax that is used to digitally sign, digest, authenticate, or 170 encrypt arbitrary message content. The CMS supports a variety of 171 architectures for certificate-based key management, especially the 172 one defined by the IETF PKIX (Public Key Infrastructure using X.509) 173 working group [RFC5280]. The CMS values are generated using ASN.1 174 [X680], using the Basic Encoding Rules (BER) and Distinguished 175 Encoding Rules (DER) [X690]. 177 The S/MIME Message Specification [RFC5751] defines MIME body parts 178 based on the CMS. In this document, the application/pkcs7-mime media 179 type is used to digitally sign an encapsulated body part, and it is 180 also is used to encrypt an encapsulated body part. 182 4.1. Signed Messages 184 While both SIP and MSRP require support for the multipart/signed 185 format, this document recommends the use of application/pkcs7-mime 186 for most signed messages. Experience with the use of S/MIME in 187 electronic mail has shown that multipart/signed bodies are at greater 188 risk of "helpful" tampering by intermediaries, a common cause of 189 signature validation failure. This risk is also present for 190 messaging applications; for example, intermediaries might insert 191 Instant Message Delivery notification requests into messages (see 192 Section 9.2). The application/pkcs7-mime format is also more 193 compact, which can be important for messaging applications, 194 especially when using the SIP MESSAGE method (see Section 7.1). The 195 use of multipart/signed may still make sense if the message needs to 196 be readable by receiving agents that do not support S/MIME. 198 When generating a signed message, sending user agents (UAs) SHOULD 199 follow the conventions specified in [RFC5751] for the application/ 200 pkcs7-mime media type with smime-type=signed-data. When validating a 201 signed message, receiving UAs MUST follow the conventions specified 202 in [RFC5751] for the application/pkcs7-mime media type with smime- 203 type=signed-data. 205 Sending and receiving UAs MUST support the SHA-256 message digest 206 algorithm [RFC5754]. For convenience, the SHA-256 algorithm 207 identifier is repeated here: 209 id-sha256 OBJECT IDENTIFIER ::= { 210 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 211 csor(3) nistalgorithm(4) hashalgs(2) 1 } 213 Sending and receiving UAs MAY support other message digest 214 algorithms. 216 Sending and receiving UAs MUST support the Elliptic Curve Digital 217 Signature Algorithm (ECDSA) using the NIST P256 elliptic curve and 218 the SHA-256 message digest algorithm [RFC5480][RFC5753]. For 219 convenience, the ECDSA with SHA-256 algorithm identifier and the 220 object identifier for the well-known NIST P256 elliptic curve are 221 repeated here: 223 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 224 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 225 ecdsa-with-SHA2(3) 2 } 227 -- Note: the NIST P256 elliptic curve is also known as secp256r1. 229 secp256r1 OBJECT IDENTIFIER ::= { 230 iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) 231 prime(1) 7 } 233 4.2. Encrypted Messages 235 When generating an encrypted message, sending UAs MUST follow the 236 conventions specified in [RFC5751] for the application/pkcs7-mime 237 media type with smime-type=enveloped-data. When decrypting a 238 received message, receiving UAs MUST follow the conventions specified 239 in [RFC5751] for the application/pkcs7-mime media type with smime- 240 type=enveloped-data. 242 Sending and receiving UAs MUST support the AES-128-CBC for content 243 encryption [RFC3565]. For convenience, the AES-128-CBC algorithm 244 identifier is repeated here: 246 id-aes128-CBC OBJECT IDENTIFIER ::= { 247 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 248 csor(3) nistAlgorithm(4) aes(1) 2 } 250 Sending and receiving UAs MAY support other content encryption 251 algorithms. 253 Sending and receiving UAs MUST support the AES-128-WRAP for 254 encryption of one AES key with another AES key [RFC3565]. For 255 convenience, the AES-128-WRAP algorithm identifier is repeated here: 257 id-aes128-wrap OBJECT IDENTIFIER ::= { 258 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 259 csor(3) nistAlgorithm(4) aes(1) 5 } 261 Sending and receiving UAs MAY support other key encryption 262 algorithms. 264 Symmetric key-encryption keys can be distributed before messages are 265 sent. If sending and receiving UAs support previously distributed 266 key-encryption keys, then they MUST assign a KEK identifier [RFC5652] 267 to the previously distributed symmetric key. 269 Alternatively, a key agreement algorithm can be used to establish a 270 single-use key-encryption key. If sending and receiving UAs support 271 key agreement, then they MUST the Elliptic Curve Diffie-Hellman 272 (ECDH) using the NIST P256 elliptic curve and the ANSI-X9.63-KDF key 273 derivation function with the SHA-256 message digest algorithm 274 [RFC5753]. For convenience, the ECDH using the ANSI-X9.63-KDF with 275 SHA-256 algorithm identifier is repeated here: 277 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 278 iso(1) identified-organization(3) certicom(132) 279 schemes(1) 11 1 } 281 4.3. Signed and Encrypted Messages 283 When generating a signed and encrypted message, sending UAs MUST sign 284 the message first, and then encrypt it. 286 4.4. Certificate Handling 288 Sending and receiving UAs MUST follow the S/MIME certificate handling 289 procedures [RFC5750], with a few exceptions detailed below. 291 4.4.1. Subject Alternative Name 293 The subject alternative name extension is used as the preferred means 294 to convey the SIP URI of a message signer. Any SIP URI present MUST 295 be encoded using the uniformResourceIdentifier CHOICE of the 296 GeneralName type as described in [RFC5280], Section 4.2.1.6. Since 297 the SubjectAltName type is a SEQUENCE OF GeneralName, multiple URIs 298 MAY be present. 300 4.4.2. Certificate Validation 302 When validating a certificate, receiving UAs MUST support the 303 Elliptic Curve Digital Signature Algorithm (ECDSA) using the NIST 304 P256 elliptic curve and the SHA-256 message digest algorithm 305 [RFC5480]. 307 Sending and receiving UAs MAY support other digital signature 308 algorithms for certificate validation. 310 5. Transfer Encoding 312 SIP and MSRP UAs are always capable of receiving binary data. Inner 313 S/MIME entities do not require base64 encoding [RFC4648]. 315 Both SIP and MSRP provide 8-bit safe transport channels; base64 316 encoding is not generally needed for the outer S/MIME entities. 317 However, if there is a chance a message might cross a 7-bit transport 318 (for example, gateways that convert to a 7-bit transport for 319 intermediate transfer), base64 encoding may be needed for the outer 320 entity. 322 6. User Agent Capabilities 324 Messaging UAs may implement a subset of S/MIME capabilities. Even 325 when implemented, some features may not be available due to 326 configuration. For example, UAs that do not have user certificates 327 cannot sign messages on behalf of the user or decrypt encrypted 328 messages sent to the user. At a minimum, a UA that supports S/MIME 329 MUST be able to validate a signed message. 331 End-user certificates have long been a barrier to large-scale 332 S/MIME deployment. But since UAs can validate signatures even 333 without local certificates, the use case of organizations sending 334 secure notifications to their users becomes a sort of "low hanging 335 fruit". 337 SIP and MSRP UAs advertise their level of support for S/MIME by 338 indicating their capability to receive the "application/pkcs7-mime" 339 media type. 341 The fact that a UA indicates support for the "multipart/signed" media 342 type does not necessarily imply support for S/MIME. The UA might 343 just be able to display clear-signed content without validating the 344 signature. UAs that wish to indicate the ability to validate 345 signatures for clear-signed messages MUST also indicate support for 346 "application/pkcs7-signature". 348 A UA can indicate that it can receive all smime-types by advertising 349 "application/pkcs7-mime" with no parameters. If a UA does not accept 350 all smime-types, it advertises the media type with the appropriate 351 parameters. If more than one are supported, the UA includes a 352 separate instance of the media-type string, appropriately 353 parameterized, for each. 355 For example, a UA that can only received signed-data would advertise 356 "application/pkcs7-mime; smime-type=signed-data". 358 SIP signaling can fork to multiple destinations for a given Address 359 of Record (AoR). A user might have multiple UAs with different 360 capabilities; the capabilities remembered from an interaction with 361 one such UA might not apply to another. 363 UAs can also advertise or discover S/MIME using out of band 364 mechanisms. Such mechanisms are beyond the scope of this document. 366 7. Using S/MIME with the SIP MESSAGE Method 368 The use of S/MIME with the SIP MESSAGE method is described in section 369 11.3 of [RFC3428], and for SIP in general in section 23 of [RFC3261]. 370 This section and its child sections offer clarifications for the use 371 of S/MIME with the SIP MESSAGE method, along with related updates to 372 RFC 3261 and RFC 3428. 374 7.1. Size Limit 376 SIP MESSAGE requests are typically limited to 1300 octets. That 377 limit applies to the entire message, including both SIP header fields 378 and the message content. This is due to the potential for 379 fragmentation of larger requests sent over UDP. In general, it is 380 hard to be sure that no proxy or other intermediary will forward a 381 SIP request over UDP somewhere along the path. Therefore, S/MIME 382 messages sent via SIP MESSAGE should be kept as small as possible. 384 [RFC3261] says that a SignedData message MUST contain a certificate 385 to be used to validate the signature. In order to reduce the message 386 size, this document updates that to say that a SignedData message 387 sent in a SIP MESSAGE request SHOULD contain the certificate, but MAY 388 omit it if the sender has reason to believe that the recipient 389 already has the certificate in its keychain, or has some other method 390 of accessing the certificate. 392 7.2. User Agent Capabilities 394 SIP user agents (UA) can indicate support for S/MIME by including the 395 appropriate media type or types in the SIP Accept header field in a 396 response to an OPTIONS request, or in a 415 response to a SIP request 397 that contained an unsupported media type in the body. 399 UAs might be able to use the user agent capabilities framework 400 [RFC3840] to indicate support. However doing so would require the 401 registration of one or more media feature tags with IANA. 403 UAs MAY use other out-of-band methods to indicate their level of 404 support for S/MIME. 406 7.3. Failure Cases 408 [RFC3261] requires that the recipient of a SIP request that includes 409 a body part of an unsupported media type and a Content-Disposition 410 header "handling" parameter of "required" return a 415 "Unsupported 411 Media Type" response. Given that SIP MESSAGE exists for no reason 412 other than to deliver content in the body, it is reasonable to treat 413 the top-level body part as always required. However [RFC3428] makes 414 no such assertion. This document updates [RFC3428] to say that a UAC 415 that receives a SIP MESSAGE request with an unsupported media type 416 MUST return a 415 Unsupported Media Type" response. 418 [RFC3261] says that if a recipient receives an S/MIME body encrypted 419 to the wrong certificate, it MUST return a SIP 493 (Undecipherable) 420 response, and SHOULD send a valid certificate in that response. This 421 is not always possible in practice for SIP MESSAGE requests. The 422 User Agent Server (UAS) may choose not to decrypt a message until the 423 user is ready to read it. Messages may be delivered to a message 424 store, or sent via a store-and-forward service. This document 425 updates RFC 3261 to say that the UAS SHOULD return a SIP 493 response 426 if it immediately attempts to decrypt the message and determines the 427 message was encrypted to the wrong certificate. However, it MAY 428 return a 2XX class response if decryption is deferred. 430 8. Using S/MIME with MSRP 432 MSRP has features that interact with the use of S/MIME. In 433 particular, the ability to send messages in chunks, the ability to 434 send messages of unknown size, and the use of SDP to indicate media- 435 type support create considerations for the use of S/MIME. 437 8.1. Chunking 439 MSRP allows a message to be broken into "chunks" for transmission. 440 In this context, the term "message" refers to an entire message that 441 one user might send to another. A chunk is a fragment of that 442 message sent in a single MSRP SEND request. All of the chunks that 443 make up a particular message share the same Message-ID value. 445 The sending user agent may break a message into chunks, which the 446 receiving user agent will reassemble to form the complete message. 447 Intermediaries such as MSRP Relays [RFC4976] might break chunks into 448 smaller chunks, or might reassemble chunks into larger ones; 449 therefore the message received by the recipient may be broken into a 450 different number of chunks than were sent by the recipient. 451 Intermediaries might also cause chunks to be received in a different 452 order than sent. 454 The sender MUST apply any S/MIME operations to the whole message 455 prior to breaking it into chunks. Likewise, the receiver needs to 456 reassemble the message from its chunks prior to decrypting, 457 validating a signature, etc. 459 MSRP chunks are framed using an end-line. The end-line comprises 460 seven hyphens, a 64-bit random value taken from the start line, and a 461 continuation flag. MRSP requires the sending user agent to scan data 462 sent in a specific chunk to be sent ensure that the end-line does not 463 accidentally occur as part of the sent data. This scanning occurs on 464 a chunk rather than a whole message, consequently it must occur after 465 the sender applies any S/MIME operations. 467 8.2. Streamed Data 469 MSRP allows a mode of operation where a UA sends some chunks of a 470 message prior to knowing the full length of the message. For 471 example, a sender might send streamed data over MSRP as a single 472 message, even though it doesn't know the full length of that data in 473 advance. This mode is incompatible with S/MIME, since a sending UA 474 must apply S/MIME operations to the entire message in advance of 475 breaking it into chunks. 477 Therefore, when sending a message in an S/MIME format, the sender 478 MUST include the Byte-Range header field for every chunk, including 479 the first chunk. The Byte-Range header field MUST include the total 480 length of the message. 482 A higher layer could choose to break such streamed data into a series 483 of messages prior to applying S/MIME operation, so that each fragment 484 appears as a distinct S/MIME separate message in MSRP. Such 485 mechanisms are beyond the scope for this document. 487 8.3. Indicating support for S/MIME 489 A UA that supports this specification MUST explicitly include the 490 appropriate media type or types in the "accept-types" attribute in 491 any SDP offer or answer that proposes MSRP. It MAY indicate that it 492 requires S/MIME wrappers for all messages by putting appropriate 493 S/MIME media types in the "accept-types" attribute and putting all 494 other supported media types in the "accept-wrapped-types" attribute. 496 For backwards compatibility, a sender MAY treat a peer that includes 497 an asterisk ("*") in the "accept-types" attribute as potentially 498 supporting S/MIME. If the peer returns an MSRP 415 response to an 499 attempt to send an S/MIME message, the sender should treat the peer 500 as not supporting S/MIME for the duration of the session, as 501 indicated in [RFC4975]. 503 MSRP allows multiple reporting modes that provide different levels of 504 feedback. If the sender includes a Failure-Report header field with 505 a value of "no", it will not receive failure reports. This mode 506 should not be used carelessly, since such a sender would never see a 507 415 response as described above, and would have no way to learn that 508 the recipient could not process an S/MIME body. 510 8.4. MSRP URIs 512 MSRP URIs are ephemeral. Endpoints MUST NOT use MSRP URIs to 513 identify certificates, or insert MSRP URIs into certificate Subject 514 Alternative Name fields. When MSRP sessions are negotiated using SIP 515 [RFC3261], the SIP Addresses of Record (AoRs) of the peers are used 516 instead. 518 Note that MSRP allows messages to be sent between peers in either 519 direction. A given MSRP message might be sent from the SIP offerer 520 to the SIP answer. Thus, the the sender and recipient roles may 521 reverse between one message and another in a given session. 523 8.5. Failure Cases 525 Successful delivery of an S/MIME message does not indicate that the 526 recipient successfully decrypted the contents or validated a 527 signature. Decryption and/or validation may not occur immediately on 528 receipt, since since the recipient may not immediately view the 529 message, and the user agent may choose not to attempt decryption or 530 validation until the user requests it. 532 Likewise, successful delivery of S/MIME enveloped data does not, on 533 its own, indicate that the recipient supports the enclosed media 534 type. If the peer only implicitly indicated support for the enclosed 535 media type through the use of a wildcard in the "accept-types" or 536 "accept-wrapped types" SDP attributes, it may not decrypt the message 537 in time to send a 415 response. 539 9. S/MIME Interaction with other SIP Messaging Features 541 9.1. Common Profile for Instant Messaging 543 The Common Profile for Instant Messaging (CPIM) [RFC3860] defines an 544 abstract messaging service, with the goal of creating gateways 545 between different messaging protocols that could relay instant 546 messages without change. The SIP MESSAGE method and MSRP were 547 initially designed to map to the CPIM abstractions. However, at the 548 time of this writing, CPIM compliant gateways have not been deployed. 549 To the authors' knowledge, no other IM protocols have been explicitly 550 mapped to CPIM. 552 CPIM also defines the abstract messaging URI scheme "im:". As of the 553 time of this writing, the "im:" scheme is not in common use. The use 554 of "im:" URIs as subject alternative names in certificates is for 555 future study. 557 The Common Profile for Instant Messages Message Format [RFC3862] 558 allows UAs to attach transport-neutral metadata to arbitrary MIME 559 content. The format was designed as a canonicalization format to 560 allow signed data to cross protocol-converting gateways without loss 561 of metadata needed to verify the signature. While it has not 562 typically been used for that purpose, it has been used for other 563 metadata applications, for example, Intant Message Delivery 564 Notifications (IMDN)[RFC5438] and MSRP Multi-party Chat [RFC7701] 566 Signature and encryption operations are typically applied to the 567 entire CPIM body part, rather than to just the CPIM payload. The use 568 of CPIM metadata fields to identify certificates or to authenticate 569 SIP or MSRP header fields is for further study. 571 9.2. Instant Message Delivery Notifications 573 The Instant Message Delivery Notification (IMDN) mechanism[RFC5438] 574 allows both endpoints and intermediary application servers to request 575 and to generate delivery notifications. The use of S/MIME does not 576 impact strictly end-to-end use of IMDN. IMDN recommends that devices 577 that are capable of doing so sign delivery notifications. It further 578 requires that delivery notifications that result from encrypted 579 messages also be encrypted. 581 However, IMDN allows intermediary application servers to insert 582 notification requests into messages, to add routing information to 583 messages, and to act on notification requests. It also allows list 584 servers to aggregate delivery notifications. 586 Such intermediaries will be unable to read end-to-end encrypted 587 messages in order to interpret delivery notice requests. 588 Intermediaries that insert information into end-to-end signed 589 messages will cause the signature validation to fail. 591 10. Examples 593 Examples will be added in a future version of this document. 595 11. IANA Considerations 597 This document makes no requests of the IANA. 599 12. Security Considerations 601 The security considerations from S/MIME [RFC5750][RFC5751] and 602 elliptic curves in CMS [RFC5753] apply. The S/MIME related security 603 considerations from SIP [RFC3261][RFC3853], SIP MESSAGE [RFC3428], 604 and MSRP [RFC4975] apply. 606 This document assumes that end-entity certificate validation is 607 provided by a chain of trust to certification authority (CA), using a 608 public key infrastructure. The security considerations from 609 [RFC5280] apply. However, other validations methods may be possible; 610 for example sending a signed fingerprint for the end-entity in SDP. 611 The relationship of this work and the techniques discussed in 612 [RFC4474], [I-D.ietf-stir-rfc4474bis], and 613 [I-D.ietf-sipbrandy-rtpsec] are for further study. 615 When matching an end-entity certificate to the sender or recipient 616 identity, the respective SIP AoRs are used. Typically these will 617 match the SIP From and To header fields. Matching SIP AoRs from 618 other header fields, for example, P-Asserted-Identity [RFC3325], is 619 for further study. 621 The secure notification use case discussed in Section 1 has 622 significant vulnerabilities when used in an insecure environment. 623 For example, "phishing" messages could be used to trick users into 624 revealing credentials. Eavesdroppers could learn confirmation codes 625 from unprotected two-factor authentication messages. Unsolicited 626 messages sent by impersonators could tarnish the reputation of an 627 organization. While hop-by-hop protection can mitigate some of those 628 risks, it still leaves messages vulnerabile to malicious or 629 compromised intermediaries. 631 Mobile messaging is typically an online application; online 632 certificate revocation checks should usually be feasible. 634 13. References 636 13.1. Normative References 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, 640 DOI 10.17487/RFC2119, March 1997, 641 . 643 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 644 A., Peterson, J., Sparks, R., Handley, M., and E. 645 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 646 DOI 10.17487/RFC3261, June 2002, 647 . 649 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 650 with Session Description Protocol (SDP)", RFC 3264, 651 DOI 10.17487/RFC3264, June 2002, 652 . 654 [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., 655 Huitema, C., and D. Gurle, "Session Initiation Protocol 656 (SIP) Extension for Instant Messaging", RFC 3428, 657 DOI 10.17487/RFC3428, December 2002, 658 . 660 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 661 Encryption Algorithm in Cryptographic Message Syntax 662 (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, 663 . 665 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 666 Requirement for the Session Initiation Protocol (SIP)", 667 RFC 3853, DOI 10.17487/RFC3853, July 2004, 668 . 670 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 671 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 672 July 2006, . 674 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 675 "The Message Session Relay Protocol (MSRP)", RFC 4975, 676 DOI 10.17487/RFC4975, September 2007, 677 . 679 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 680 Housley, R., and W. Polk, "Internet X.509 Public Key 681 Infrastructure Certificate and Certificate Revocation List 682 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 683 . 685 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 686 "Elliptic Curve Cryptography Subject Public Key 687 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 688 . 690 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 691 RFC 5652, DOI 10.17487/RFC5652, September 2009, 692 . 694 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 695 Mail Extensions (S/MIME) Version 3.2 Certificate 696 Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, 697 . 699 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 700 Mail Extensions (S/MIME) Version 3.2 Message 701 Specification", RFC 5751, DOI 10.17487/RFC5751, January 702 2010, . 704 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 705 Cryptography (ECC) Algorithms in Cryptographic Message 706 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 707 2010, . 709 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 710 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 711 2010, . 713 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 714 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 715 May 2017, . 717 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 718 One (ASN.1): Specification of basic notation", 719 ITU-T Recommendation X.680, 2015. 721 [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: 722 Specification of Basic Encoding Rules (BER), Canonical 723 Encoding Rules (CER) and Distinguished Encoding Rules 724 (DER)", ITU-T Recommendation X.690, 2015. 726 13.2. Informative References 728 [I-D.ietf-sipbrandy-rtpsec] 729 Peterson, J., Rescorla, E., Barnes, R., and R. Housley, 730 "Best Practices for Securing RTP Media Signaled with SIP", 731 draft-ietf-sipbrandy-rtpsec-02 (work in progress), March 732 2017. 734 [I-D.ietf-stir-rfc4474bis] 735 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 736 "Authenticated Identity Management in the Session 737 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 738 (work in progress), February 2017. 740 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 741 Extensions to the Session Initiation Protocol (SIP) for 742 Asserted Identity within Trusted Networks", RFC 3325, 743 DOI 10.17487/RFC3325, November 2002, 744 . 746 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 747 "Indicating User Agent Capabilities in the Session 748 Initiation Protocol (SIP)", RFC 3840, 749 DOI 10.17487/RFC3840, August 2004, 750 . 752 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 753 (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004, 754 . 756 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 757 Messaging (CPIM): Message Format", RFC 3862, 758 DOI 10.17487/RFC3862, August 2004, 759 . 761 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 762 Authenticated Identity Management in the Session 763 Initiation Protocol (SIP)", RFC 4474, 764 DOI 10.17487/RFC4474, August 2006, 765 . 767 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 768 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 769 . 771 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 772 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 773 DOI 10.17487/RFC4976, September 2007, 774 . 776 [RFC5438] Burger, E. and H. Khartabil, "Instant Message Disposition 777 Notification (IMDN)", RFC 5438, DOI 10.17487/RFC5438, 778 February 2009, . 780 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 781 Protocol (XMPP): Instant Messaging and Presence", 782 RFC 6121, DOI 10.17487/RFC6121, March 2011, 783 . 785 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 786 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 787 2015, . 789 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 790 RFC 7516, DOI 10.17487/RFC7516, May 2015, 791 . 793 [RFC7701] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi- 794 party Chat Using the Message Session Relay Protocol 795 (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015, 796 . 798 Authors' Addresses 800 Ben Campbell 801 Independent 802 204 Touchdown Dr 803 Irving, TX 75063 804 US 806 Email: ben@nostrum.com 807 Russ Housley 808 Vigil Security 809 918 Spring Knoll Drive 810 Herndon, VA 20170 811 US 813 Email: housley@vigilsec.com