idnits 2.17.1 draft-wing-sipping-srtp-key-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1022. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1033. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1040. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1046. 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 document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 31, 2008) is 5654 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) == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-06 == Outdated reference: A later version (-09) exists of draft-ietf-sip-media-security-requirements-07 == Outdated reference: A later version (-08) exists of draft-ietf-sip-saml-04 == Outdated reference: A later version (-09) exists of draft-ietf-sip-sips-08 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-15 == Outdated reference: A later version (-22) exists of draft-zimmermann-avt-zrtp-10 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group D. Wing 3 Internet-Draft Cisco 4 Intended status: Standards Track F. Audet 5 Expires: May 4, 2009 Nortel 6 S. Fries 7 Siemens AG 8 H. Tschofenig 9 Nokia Siemens Networks 10 A. Johnston 11 Avaya 12 October 31, 2008 14 Secure Media Recording and Transcoding with the Session Initiation 15 Protocol 16 draft-wing-sipping-srtp-key-04 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on May 4, 2009. 43 Abstract 45 Call recording is an important feature in enterprise telephony 46 applications. Some industries such as financial traders have 47 requirements to record all calls in which customers give trading 48 orders. This poses a particular problem for Secure RTP systems as 49 many SRTP key exchange mechanisms do not disclose the SRTP session 50 keys to intermediate SIP proxies. As a result, these key exchange 51 mechanisms cannot be used in environments where call recording is 52 needed. 54 This document specifies a secure mechanism for a cooperating endpoint 55 to disclose its SRTP master keys to an authorized party to allow 56 secure call recording. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Introduction to SRTP Call Recording . . . . . . . . . . . . . 4 63 4. Recording Modes . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Always On Recording . . . . . . . . . . . . . . . . . . . 6 65 4.2. Recording On Demand . . . . . . . . . . . . . . . . . . . 6 66 4.3. Required Recording . . . . . . . . . . . . . . . . . . . . 6 67 4.4. Pause and Resume Recording . . . . . . . . . . . . . . . . 6 68 5. Recording Call Flows . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. Always On Recording . . . . . . . . . . . . . . . . . . . 8 70 5.2. Recording On Demand . . . . . . . . . . . . . . . . . . . 9 71 5.3. Required Recording . . . . . . . . . . . . . . . . . . . . 9 72 5.4. Pause and Resume Recording Call Flow . . . . . . . . . . . 9 73 5.5. Conference Recording . . . . . . . . . . . . . . . . . . . 10 74 6. Transcoding . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 7. Media Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 7.1. Offer/Answer Considerations . . . . . . . . . . . . . . . 13 77 7.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 14 78 7.2.1. Learning Name and Certificate of ESC . . . . . . . . . 14 79 7.2.2. Authorization of ESC . . . . . . . . . . . . . . . . . 14 80 7.2.3. Sending SRTP Session Keys to ESC . . . . . . . . . . . 15 81 7.2.4. Scenarios and Call Flows . . . . . . . . . . . . . . . 16 82 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 9.1. Incorrect ESC . . . . . . . . . . . . . . . . . . . . . . 18 85 9.2. Risks of Sharing SRTP Session Key . . . . . . . . . . . . 18 86 9.3. Disclosure of Call Recording . . . . . . . . . . . . . . . 19 87 9.4. Integrity and encryption of keying information . . . . . . 19 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 91 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 93 13.2. Informational References . . . . . . . . . . . . . . . . . 22 94 Appendix A. Outstanding Issues . . . . . . . . . . . . . . . . . 23 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 96 Intellectual Property and Copyright Statements . . . . . . . . . . 25 98 1. Introduction 100 Call recording is an important feature in enterprise telephony 101 applications. Some industries such as financial traders have 102 requirements to record all calls in which customers give trading 103 orders. In others, calls are recorded, as the near ubiquitous 104 announcement says, "for training and quality control purposes". Yet 105 in others, all calls are not recorded, and only statistical audits 106 are done. 108 The services and examples in this document are not wiretapping as 109 defined in Raven [RFC2804]. Specifically, there is no attempt in 110 this draft to make the recording process undetectable to the user. 111 Also, in most circumstances, the intent of the recording is to 112 protect both parties from later disagreements about what was said 113 during the conversation or to remedy mistakes made. 115 First, three different recording modes are discussed. Then example 116 call flows for how this can be accomplished using standard SIP 117 primitives. Finally, the impact of encrypted media, SRTP, is 118 discussed. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119] and indicate 125 requirement levels for compliant mechanisms. 127 The following terminology is taken directly from SIP Event State 128 Publication Extension [RFC3903]: 130 Event Publication Agent (EPA): The User Agent Client (UAC) that 131 issues PUBLISH requests to publish event state. 133 Event State Compositor (ESC): The User Agent Server (UAS) that 134 processes PUBLISH requests, and is responsible for compositing 135 event state into a complete, composite event state of a resource. 137 Publication: The act of an EPA sending a PUBLISH request to an ESC 138 to publish event state. 140 3. Introduction to SRTP Call Recording 142 This document addresses two difficulties with End-to-end encryption 143 of RTP (SRTP [RFC3711]): transcoding and media recording. When 144 peering with other networks, different codecs are sometimes necessary 145 (e.g., transcoding a surround-sound codec for transmission over a 146 highly-compressed bandwidth-constrained network). In some 147 environments (e.g., stock brokerages and banks) regulations and 148 business needs require recording calls with coworkers or with 149 customers. In many environments, quality problems such as echo can 150 only be diagnosed by listening to the call (analyzing SRTP headers is 151 not sufficient). 153 With an RTP stream, transcoding is accomplished by modifying SDP to 154 offer a different codec through a transcoding device [RFC4117], and 155 call recording or monitoring can be accomplished with an Ethernet 156 sniffer listening for SIP and its associated RTP, with a media relay, 157 or with a Session Border Controller. However, when media is 158 encrypted end-to-end [I-D.ietf-sip-media-security-requirements], 159 these existing techniques fail because they are unable to decrypt the 160 media packets. If [I-D.ietf-sip-media-security-requirements] is 161 used, then it is not even possible for a Proxy in the signalling path 162 to extract the SRTP session keys from the SDP. 164 When a media session is encrypted with SRTP, there are three 165 techniques to decrypt the media for monitoring or call recording: 167 1. the endpoint establishes a separate media stream to the recording 168 device, with a separate SRTP key, and sends the (mixed) media to 169 the recording device. This techniques is often called 'active 170 recording'. The disadvantages of this technique include doubling 171 bandwidth requirements in the network and additionally the 172 processing power on the client side. Moreover, the loss of media 173 recording facility doesn't cause loss of call (as is required in 174 some environments) and therefore, it may be necessary to 175 establish a reliable connection to the recording device to cope 176 with possible packet loss on the unreliable link. Because the 177 endpoint maintains its own key with the connected party, this 178 technique is more secure: a malicious media recording device 179 cannot inject media to the connected party on behalf of the 180 endpoint. 182 2. the endpoint relays media through a device which forks a separate 183 media stream to the recording device. This technique is often 184 employed by Session Border Controllers. This relay does not, 185 itself, have access to the SRTP key. 187 3. Network monitoring devices are used to listen to the SRTP traffic 188 and correlate SRTP with SIP. This correlation requires 189 cooperation of call signaling devices if the call signaling is 190 encrypted (e.g., with TLS). 192 In cases (2) and (3), a cooperating endpoint publishes its SRTP 193 master keys to an authorized party using the SIP Event State 194 Publication Extension [RFC3903]. For case (1), this is not necessary 195 as the cooperating endpoint may use existing key negotiation 196 mechanisms such as [RFC4567], [RFC4568] or DTLS-SRTP 197 [I-D.ietf-avt-dtls-srtp]. Cases (2) and (3) can be described as 198 passive recording, as the client is not directly involved with the 199 media recording. The client merely provides the key information to a 200 recording device. The publication mechanism described in this paper 201 allows secure disclosure of SRTP session keys to authorized parties 202 so that an endpoints media stream can be transcoded or decrypted, as 203 needed by that environment. 205 4. Recording Modes 207 There are four common modes of call recording which are described in 208 the following sections. 210 4.1. Always On Recording 212 In the Always On recording mode, for an identified endpoint, phone 213 number, user or agent, all calls both incoming and outgoing are 214 recorded. For example, a toll free call to a helpline could utilize 215 this mode to record the entire text of calls. 217 4.2. Recording On Demand 219 In the Recording On Demand recording mode, only certain calls are 220 recorded. For example, in a call center application, personal or 221 non-call center calls by an agent might not be recorded. 223 4.3. Required Recording 225 In the Required Recording mode, the requirement for recording is so 226 strong that if call recording resources are unavailable, the call 227 must not be setup or an existing call must be disconnected. 229 4.4. Pause and Resume Recording 231 In the Pause and Resume Recording Mode, only parts of a given call 232 may be recorded. For example, when the call is placed on hold, 233 recording may be paused and resumed when the call is resumed. Or, 234 IVR interactions in which a user enters account numbers and pin 235 numbers should not be recorded, as the DTMF tones convey private or 236 secure information. Pausing can be unidirectional or bi-directional. 238 5. Recording Call Flows 240 This section will show how these four recording modes can be 241 implemented . 243 In SIP call recording, the two-way RTP or SRTP media session between 244 two UAs is sent to a UA referred to as a Recording UA. While it is 245 possible for recording to be done locally in a UA, this has no impact 246 on the SIP call flows. 248 While it is also possible for the recording policy and decision 249 making to be included in an endpoint, it is more common to have a 250 third party control recording and cause the RTP or SRTP to be sent to 251 the Recording UA. In these call flows, this third party will be 252 called the Controller. 254 If the Controller acts as a third party call controller (3PCC) 255 [RFC3725], it is possible for the Controller to cause each UA to send 256 an extra media stream to the Recorder. However, for this call flow 257 to work: 259 1. Both UAs must support multiple media lines and streams sent to 260 different addresses (e.g., Section 2.4 of SDP Examples 261 [RFC4317]). 263 2. Both UAs must have twice the normal bandwidth available. 265 3. Both UAs must know to send the same media on both media streams. 267 While 1 and 2 are possible, 3 is the most difficult. Without 268 additional information in the SDP, each media stream is considered a 269 separate media stream. 271 Alternatively, the Controller could be a combination of a SIP Proxy 272 and a media relay (e.g., a Session Border Controller). This media 273 relay would copy media streams to a second location. The protocol 274 and coordination between these two elements is outside the scope of 275 this specification. In another model discussed in Section 5, the 276 Controller could be a SIP Focus and a Media Server with some special 277 logic. Finally, the Controller could be realized as a B2BUA. 279 Using this model, there are no SIP, SDP, or bandwidth requirements on 280 either UA. The Controller then can cause the media received at the 281 Media Relay to be copied to the Recorder. An example is shown in 282 Figure 1, below where the Recorder records a call between Alice and 283 Bob. 285 Alice Controller Bob Recorder 286 | | | | 287 | INVITE F1 | | | 288 |--------------->| | | 289 |(100 Trying) F2 | | | 290 |<---------------| INVITE F3 | | 291 | |--------------------------------->| 292 | | | 200 OK F4 | 293 | |<---------------------------------| 294 | | | ACK F5 | 295 | |--------------------------------->| 296 | | INVITE F6 | | 297 | |------------->| | 298 | |180 Ringing F7| | 299 | |<-------------| | 300 | 180 Ringing F5 | | | 301 |<---------------| 200 OK F6 | | 302 | |<-------------| | 303 | 200 OK F7 | | | 304 |<---------------| | | 305 | ACK F8 | | | 306 |--------------->| ACK F9 | | 307 | |------------->| | 308 | | INVITE F10 | | 309 | |--------------------------------->| 310 | | | 200 OK F11 | 311 | |<---------------------------------| 312 | | | ACK F12 | 313 | |--------------------------------->| 314 | Both way SRTP Established | | 315 |<==============>|<============>| | 316 | | SRTP From Alice | 317 | |=================================>| 318 | | SRTP From Bob | 319 | |=================================>| 321 Figure 1: Controller Proxy or B2BUA 323 The following sections will discuss and extend this basic call flow 324 for the four recording modes. 326 5.1. Always On Recording 328 The Always On recording mode for the user Bob can be implemented 329 using the call flow of Figure 1 if every call made to Bob is handled 330 in this way. 332 5.2. Recording On Demand 334 In the Recording On Demand recording mode, the call flow of Figure 1 335 is used selectively - only for the calls that need to be recorded. 336 For the non-recorded flows, the Controller could act as a Proxy 337 Server and make no changes to the signaling or media flows. By not 338 inserting a Record-Route, the Controller could even drop out of the 339 SIP dialog for calls where recording is not of interest. 341 5.3. Required Recording 343 Required recording could also be implemented using Figure 1, as the 344 INVITE is sent first to the Recorder before being sent to Bob. As a 345 result, if the INVITE is refused (i.e., the Recorder is unable to 346 record the call), the INVITE will not be forwarded to Bob and the 347 call refused. Also, if the Recorder disconnects during the call or 348 is unable to provide recording resources (i.e., disks full, etc.), 349 the BYE from the Recorder can be used to terminate the call to Bob. 350 This is show in Figure 2, below. 352 Alice Controller Bob Recorder 353 | | | | 354 | Both way SRTP Established | | 355 |<==============>|<============>| | 356 | | SRTP From Alice | 357 | |=================================>| 358 | | SRTP From Bob | 359 | |=================================>| 360 | | | | 361 | | BYE F1 | 362 | |<---------------------------------| 363 | | 200 OK F2 | 364 | |--------------------------------->| 365 | | | | 366 | BYE F3 | | | 367 |<---------------| | | 368 | 200 OK F4 | | | 369 |--------------->| | | 371 Figure 2: Required Recording Call Flow 373 5.4. Pause and Resume Recording Call Flow 375 The Pause and Resume recording mode can be initiated by the call flow 376 of Figure 2. When the recording is to be paused, for example, when 377 the caller Alice places the call on hold, the hold re-INVITE from 378 Alice causes the Controller to place the call to the Recorder on hold 379 as well. No media is sent to the Recorder until a re-INVITE starts 380 the recording again, as shown in Figure 3, below. 382 Alice Controller Bob Recorder 383 | | | | 384 | Both way SRTP Established | | 385 |<==============>|<=============>| | 386 | | SRTP From Alice | 387 | |=================================>| 388 | | SRTP From Bob | 389 | |=================================>| 390 | INVITE (hold) F1 | | 391 |--------------->| INVITE (inactive) F2 | 392 | |--------------------------------->| 393 | | 200 OK (inactive) F4 | 394 | |<---------------------------------| 395 | | | ACK F5 | 396 | |--------------------------------->| 397 | |INVITE (hold) F6 | 398 | |------------->| | 399 | |200 OK (hold) F7 | 400 | |<-------------| | 401 | 200 OK (hold) F8 | | 402 |<---------------| | | 403 | ACK F8 | | | 404 |--------------->| ACK F9 | | 405 | |------------->| | 406 | | | | 407 | No SRTP Sent | 409 Figure 3: Pause and Resume Call Flow 411 5.5. Conference Recording 413 A call flow for conference recording is shown in Figure 4, below. 414 This call flow is similar to the previous ones except with a focus 415 instead of the Controller. The recorder SUBSCRIBEs to the focus 416 using the conference event package to learn of call recording events 417 of interest to the Recorder. 419 With the subscription established by the SUBSCRIBE, the Recorder 420 receives NOTIFYs whenever recording events of interest occur from the 421 Controller. For example, the Recorder is informed when Alice joins 422 the conference, but recording is not initiated. When notification 423 that Bob has joined the conference is received in a NOTIFY, F7, is 424 sent. In this example, the Recorder decides to record the call and 425 sends a INVITE with Join to the Controller, F16. The dialog 426 information used to construct the Join header field is obtained using 427 the NOTIFY, F13. The Focus/Mixer then begins to stream the media to 428 the Recorder for the duration of the conference. 430 This model could be used for other recording modes. In this case, 431 the event package would be a new event package specifically tailored 432 to the recording application, containing all the information needed 433 by a Recorder to make a decision on whether or not to record a call. 434 The details of this event package may be defined in a future draft. 435 Note that presently, CTI (Computer Telephone Integration) protocols 436 are used for this purpose today. 438 Alice Focus/Mixer Bob Recorder 439 | | | | 440 | | SUBSCRIBE F1 | 441 | |<---------------------------------| 442 | | | 200 OK F2 | 443 | |--------------------------------->| 444 | | NOTIFY F3 | | 445 | |--------------------------------->| 446 | | | 200 OK F4 | 447 | |<---------------------------------| 448 | INVITE F5 | | | 449 |--------------->| | | 450 | 200 OK F6 | | | 451 |<---------------| | | 452 | ACK F7 | | | 453 |--------------->| | | 454 | SRTP | NOTIFY F8 | | 455 |<==============>|--------------------------------->| 456 | | | 200 OK F9 | 457 | |<---------------------------------| 458 | | INVITE F10 | | 459 | |<-------------| | 460 | |180 Ringing F11 | 461 | |------------->| | 462 | | 200 OK F12 | | 463 | |------------->| | 464 | | SRTP | | 465 | |<============>| | 466 | | NOTIFY F13 | | 467 | |--------------------------------->| 468 | | | 200 OK F14 | 469 | |<---------------------------------| 470 | | INVITE Join: A-B F15 | 471 | |<---------------------------------| 472 | | | 200 OK F16 | 473 | |--------------------------------->| 474 | | | ACK F17 | 475 | |<---------------------------------| 476 | | Mixed SRTP from Alice and Bob | 477 | |=================================>| 479 Figure 4: Conference Recording Call Flow 481 6. Transcoding 483 There are similarities between transcoding and call recording, 484 especially technique 2 described in Section 3. An endpoint that 485 desires transcoding can provide its SRTP key to a transcoder and 486 request its services. 488 [[This section is a placeholder, and will be expanded in a later 489 version of this document.]] 491 7. Media Considerations 493 The following sections will discuss considerations relating to the 494 media streams. 496 7.1. Offer/Answer Considerations 498 For the call flows in this document, it is assumed that a single bi- 499 directional media stream is to be recorded. Normally, this would be 500 negotiated using a single media line (m= line) in the SDP with a 501 default direction attribute (a=sendrcv). The media stream sent from 502 the Controller to the Recorder could be done in two different ways, 503 depending on the media handling in the Controller. In the simplest 504 case, each direction of the media stream between Alice and Bob could 505 be converted to a separate uni-directional media stream sent to the 506 Controller. In the INVITE from the Controller to the Recorder, for a 507 single recording session, there would be two media lines (m=) with 508 each marked as send only (a=sendonly). This has the advantage that 509 the Controller does not have to perform any processing on the RTP 510 packets - they are simply forwarded without changing SSRC or sequence 511 numbers. The Recording device will then mix the packets together or 512 possibly record the two sides of the conversation separately, if 513 desired. 515 In the other model, the Controller can function as an RTP mixer, in 516 which case a single uni-directional media stream will be used with a 517 single media line. The Controller will need to process the RTP 518 packets by mixing them and including its own SSRC and sequence number 519 in the resulting RTP packets. The Recorder will then not have to mix 520 them and will not have the option of recording the two sides 521 separately. 523 The approach of using two separate media lines is the recommended one 524 as it allows for simple RTP packet processing at the Controller and 525 also provides recording flexibility at the Recorder. However, a 526 Recorder should also be able to handle the case where the Controller 527 performs the mixing as well. 529 7.2. Operation 531 For transcoding, RTP packets must be sent from and received by a 532 device which performs the transcoding. When the media is encrypted, 533 this device must be capable of decrypting the media, performing the 534 transcoding function, and re-encrypting the media. 536 ISSUE-1: should we consider providing some or all of the SIP 537 headers, as well? Some recording functions will need to know the 538 identity of the remote party. This information could be gleaned 539 from the SIP proxies, though, and starts to fall outside the 540 intended scope of this document. 542 ISSUE-2: The authors have been considering use of MIKEY 543 [RFC3830], but MIKEY may not be used off the shelf. Certain 544 changes to the state machine may have to be made (MIKEY [RFC3830] 545 describes the TGK transport rather than SRTP master key 546 transport). 548 7.2.1. Learning Name and Certificate of ESC 550 The endpoint will be configured with the AOR of its ESC (e.g., 551 "transcoder@example.com"). If S/MIME is used to send the SRTP master 552 key to the ESC, the endpoint is additionally configured with the 553 certificate of its ESC. 555 The name and public key of the ESC is configured into the endpoint. 556 It is vital that the public key of the ESC is not changed by an 557 unauthorized user. Changes to change that public key will cause SRTP 558 key disclosure to be encrypted with that key. It is RECOMMENDED that 559 endpoints restrict changing the public key of the disclosure device 560 using protections similar to changes to the endpoint's SIP username 561 and SIP password. 563 7.2.2. Authorization of ESC 565 Depending on the application, authorization of the key disclosure and 566 distribution to the ESC may be necessary besides the pure transport 567 security of the key distribution itself. This may be the case when 568 the configuration framework [I-D.ietf-sipping-config-framework] is 569 not applied and thus the information about the ESC is not known to 570 the client. 572 This can be done by providing a SAML extension [I-D.ietf-sip-saml] in 573 the header of the SUBSCRIBE message. The SAML assertion shall at 574 least contain the information about the ESC, call related information 575 to associate the call with the assertion (editors note: we may also 576 define wildcards here to allow for recordings of all phone calls for 577 a day, independent of the call) and a reference to the certificate 578 for the ESC. The latter information is needed to transport the SRTP 579 Session Key to the ESC in a protected manner, as described in the 580 section below. 582 The signature of the SAML assertion should be produced using the 583 private key of the domain certificate. This certificate MUST have a 584 SubjAltName which matches the domain of user agent's SIP proxy (that 585 is, if the SIP proxy is sip.example.com, the SubjAltName of the 586 domain certificate signing this SAML assertion MUST also be 587 example.com). Here, the main focus is placed on communication of 588 clients with the ESC, which belongs to the client's home domain. 590 7.2.3. Sending SRTP Session Keys to ESC 592 SDP is used to describe the media session to the ESC. However, the 593 existing Security Descriptions [RFC4568] only describes the master 594 key and parameters of the SRTP packets being sent -- it does not 595 describe the master key (and parameters) of the SRTP being received, 596 or the SSRC being transmitted. For transcoding and media recording, 597 both the sending key and receiving key are needed and in some cases 598 the SSRC is needed. 600 Thus, we hereby extend the existing crypto attribute to indicate the 601 SSRC. We also create a new SDP attribute, "rcrypto", which is 602 identical to the existing "crypto" attribute, except that it 603 describes the receiving keys and their SSRCs. For example: 605 a=crypto:1 AES_CM_128_HMAC_SHA1_80 606 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 607 SSRC=1899 608 a=rcrypto:1 AES_CM_128_HMAC_SHA1_80 609 inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKKIN1Mw|2^20|1:32 610 SSRC=3289 611 a=rcrypto:1 AES_CM_128_HMAC_SHA1_80 612 inline:Hw3JFWNCFqSpTqNiYRj6HmSWKMHAmO4q1KIN1OVA|2^20|1:32 613 SSRC=4893 615 Figure 5: Example SDP 617 The full SDP, including the keying information, is then sent to the 618 ESC. The keying information MUST be encrypted and integrity 619 protected. Existing mechanisms such as S/MIME [RFC3261] and SIPS 620 [I-D.ietf-sip-sips] or SIP over TLS (on all hops per administrative 621 means) MAY be used to achieve this goal, or other mechanisms may be 622 defined. 624 [[ ISSUE-3: if a endpoint is receiving multiple incoming streams 625 from multiple endpoints, it will have negotiated different keys 626 with each of them, and all of that traffic is coming to the same 627 transport address on the endpoint. Thus, we need a way to 628 describe the different keys we're using to/from different 629 transport addresses. One solution is to indicate the remote 630 transport address. Indicating the remote SSRC is insufficient for 631 this task, as several SRTP keying mechanisms do not include SSRC 632 in their signaling (DTLS-SRTP, ZRTP, Security Descriptions). 634 For example, if there were two remote peers with different keys, 635 we could signal it like this: 637 a=crypto:1 AES_CM_128_HMAC_SHA1_80 638 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 639 192.0.2.1:5678 SSRC=1899 SSRC=3892 640 a=rcrypto:1 AES_CM_128_HMAC_SHA1_80 641 inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKKIN1Mw|2^20|1:32 642 192.0.2.1:5678 SSRC=3289 SSRC=2813 643 a=crypto:1 AES_CM_128_HMAC_SHA1_80 644 inline:GdUJShpX1ZLEw6UzF3WSJjNzB4d1BINUAv+PSdFc|2^20|1:32 645 192.0.2.222:2893 646 a=rcrypto:1 AES_CM_128_HMAC_SHA1_80 647 inline:6UzF3IN1ZLEwAv+PSdFcWUGdUJShpXSJjNzB4d1B|2^20|1:32 648 192.0.2.222:2893 650 Figure 6: Strawman solution 652 ]] 654 7.2.4. Scenarios and Call Flows 656 The following scenarios and call flows depict the assumptions for the 657 provision of media key disclosure. Figure 7 shows the general setup 658 within the home domain of the client. Note that the authors assume 659 that the client only discloses media keys only to an entity in the 660 client's home network rather than to an arbitrary entity in the 661 visited network. 663 +----------+ +-------+ +---------+ +--------+ +----------+ 664 | SIP User | | SIP | |SIP Proxy| | Media | | SIP | 665 |Agent(EPA)| | Proxy | | (ESC) | |Recorder| |User Agent| 666 +----------+ +-------+ +---------+ +--------+ +----------+ 667 | | | | | 668 +----------+----------+-----------+-----------+ 670 Figure 7: Network Topology 672 Based on this setup there are different options to realize the key 673 disclosure, depending on the environment. In the following two 674 approaches are distinguished. 676 Publishing media keys to the ESC 678 This requires that the configuration management provides the ESC 679 configuration data (e.g., certificate, policy) in a secure way to 680 the client. As stated above, this configuration is outside the 681 scope of this document, but an example can be found in 682 [I-D.ietf-sipping-config-framework]. The key disclosure in this 683 approach uses the PUBLISH method to disclose the key to the ESC 684 according to a given policy. 686 +----------+ +-------+ +---------+ +--------+ +----------+ 687 | SIP User | | SIP | |SIP Proxy| | Media | | SIP | 688 |Agent(EPA)| | Proxy | | (ESC) | |Recorder| |User Agent| 689 +----------+ +-------+ +---------+ +--------+ +----------+ 690 | | | | | 691 |-REGISTER->| | | | 692 |<-200 OK---| | | | 693 | | | | | 694 |--INVITE-->|-------------INVITE------------->| 695 |<-200 Ok---|<------------200 Ok------------- | 696 | | | | | 697 |<====SRTP in both directions================>| 698 | | | | | 699 |-PUBLISH-->|-PUBLISH-->|-key----->| | 700 |<-200 Ok---|<--200 Ok--| | | 702 Figure 8: Message Flow showing Publishing of Media Keys to ESC 704 Note that the protocol between the ESC and the recorder is out of 705 scope of this document. 707 Using SAML assertions for ESC contact 709 In this approach authorization is provided via a SAML assertion, 710 see [I-D.ietf-sip-saml], indicating which ESC is allowed to 711 perform call recording of a single or a set of calls, depending on 712 the content of the assertion. Here a SAML assertion is provided 713 as part of the SUBSCRIBE message, send from the ESC to the client. 714 The assertion needs to provide at least the call relation, or a 715 time interval for which media recoding is going to be performed. 716 The SAML assertion is signed with the private key associated with 717 the domain certificate, which is in possession of the 718 authentication service. The call flow would look like following: 720 +----------+ +-------+ +---------+ +--------+ +----------+ 721 | SIP User | | SIP | |SIP Proxy| | Media | | SIP | 722 |Agent(EPA)| | Proxy | | (ESC) | |Recorder| |User Agent| 723 +----------+ +-------+ +---------+ +--------+ +----------+ 724 | | | | | 725 |-REGISTER->| | | | 726 |<-200 OK---| | | | 727 | | | | | 728 |<-SUBSCRIBE (SAML as.)-| | | 729 | | | | | 730 |--INVITE-->|-------------INVITE------------->| 731 |<-200 Ok---|<------------200 Ok------------- | 732 | | | | | 733 |<====SRTP in both directions================>| 734 | | | | | 735 |--NOTIFY (SRTP data)-->| | | 736 | | | | | 738 Figure 9: Message Flow Showing Publication using SAML 740 8. Grammar 742 [[Grammar will be provided in a subsequent version of this 743 document.]] 745 9. Security Considerations 747 9.1. Incorrect ESC 749 Insertion of the incorrect public key of the SRTP ESC will result in 750 disclosure of the SRTP session key to an unauthorized party. Thus, 751 the UA's configuration MUST be protected to prevent such 752 misconfiguration. To avoid changes to the configuration in the end 753 device, the configuration access MUST be suitably protected. 755 9.2. Risks of Sharing SRTP Session Key 757 A party authorized to obtain the SRTP session key can listen to the 758 media stream and could inject data into the media stream as if it 759 were either party. The alternatives are worse: disclose the 760 device's private key to the transcoder or media recording device, or 761 abandon using secure SRTP key exchange in environments that require 762 media transcoding or media recording. As we wish to promote the use 763 of secure SRTP key exchange mechanisms, disclosure of the SRTP 764 session key appears the least of these evils. 766 9.3. Disclosure of Call Recording 768 Secure SRTP key exchange techniques which implement this 769 specification SHOULD support a "disclosure flag", similar to that 770 first proposed in Appendix B of [I-D.zimmermann-avt-zrtp]. In this 771 way, both endpoints can be made aware of such recording and provide 772 appropriate alerting to their users (via an audible, visual, or other 773 indicator). The policies surrounding the usage of the flag or not 774 will depend on the operating environment of the system. 776 9.4. Integrity and encryption of keying information 778 The mechanism describe in this specification relies on protecting and 779 encrypting the keying information. There are well known mechanism to 780 achieve that goal. 782 Using SIPS to convey the SRTP key exposes the SRTP master key to all 783 SIP proxies between the Event Publication Agent (ESC, the SIP User 784 Agent) and the Event State Compositor (ESC). S/MIME allows 785 disclosing the SRTP master key to only the ESC. 787 10. IANA Considerations 789 New SSRC extension of the "crypto" attribute, and the new "rcrypto" 790 attribute will be registered here. 792 11. Examples 794 This is an example showing a SIPS AOR for the ESC. This relies on 795 the SIP network providing TLS encryption of the SRTP master keys to 796 the ESC. 798 PUBLISH sips:recorder@example.com SIP/2.0 799 Via: SIP/2.0/TLS pua.example.com;branch=z9hG4bK652hsge 800 To: 801 From: ;tag=1234wxyz 802 Call-ID: 81818181@pua.example.com 803 CSeq: 1 PUBLISH 804 Max-Forwards: 70 805 Expires: 3600 806 Event: srtp 807 Content-Type: application/sdp 808 Content-Length: ... 810 v=0 811 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 812 s=- 813 c=IN IP4 192.0.2.101 814 t=0 0 815 m=audio 49172 RTP/SAVP 0 816 a=crypto:1 AES_CM_128_HMAC_SHA1_80 817 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 818 a=rcrypto:1 AES_CM_128_HMAC_SHA1_80 819 inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32 820 a=rtpmap:0 PCMU/8000 822 Figure 10: Example with "SIPS:" AOR 824 This is an example showing an S/MIME-encrypted transmission to the 825 recorder's AOR, recorder@example.com. The data enclosed in "*" is 826 encrypted with recorder@example.com's public key. 828 PUBLISH sip:recorder@example.com SIP/2.0 829 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge 830 To: 831 From: ;tag=1234wxyz 832 Call-ID: 81818181@pua.example.com 833 CSeq: 1 PUBLISH 834 Max-Forwards: 70 835 Expires: 3600 836 Event: srtp 837 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 838 name=smime.p7m 839 Content-Transfer-Encoding: binary 840 Content-ID: 1234@atlanta.example.com 841 Content-Disposition: attachment;filename=smime.p7m; 842 handling=required 843 Content-Length: ... 845 ****************************************************************** 846 * (encryptedContentInfo) * 847 * Content-Type: application/sdp * 848 * Content-Length: ... * 849 * * 850 * v=0 * 851 * o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com* 852 * s=- * 853 * c=IN IP4 192.0.2.101 * 854 * t=0 0 * 855 * m=audio 49172 RTP/SAVP 0 * 856 * a=crypto:1 AES_CM_128_HMAC_SHA1_80 * 857 * inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 * 858 * a=rcrypto:1 AES_CM_128_HMAC_SHA1_80 * 859 * inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32 * 860 * a=rtpmap:0 PCMU/8000 * 861 * * 862 ****************************************************************** 864 Figure 11: Example with S/MIME-encrypted SDP 866 12. Acknowledgements 868 Thanks to Sheldon Davis and Val Matula for suggesting improvements to 869 the document. 871 13. References 873 13.1. Normative References 875 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 876 Requirement Levels", BCP 14, RFC 2119, March 1997. 878 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 879 A., Peterson, J., Sparks, R., Handley, M., and E. 880 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 881 June 2002. 883 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 884 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 885 RFC 3711, March 2004. 887 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 888 for Event State Publication", RFC 3903, October 2004. 890 13.2. Informational References 892 [I-D.ietf-avt-dtls-srtp] 893 McGrew, D. and E. Rescorla, "Datagram Transport Layer 894 Security (DTLS) Extension to Establish Keys for Secure 895 Real-time Transport Protocol (SRTP)", 896 draft-ietf-avt-dtls-srtp-06 (work in progress), 897 October 2008. 899 [I-D.ietf-sip-media-security-requirements] 900 Wing, D., Fries, S., Tschofenig, H., and F. Audet, 901 "Requirements and Analysis of Media Security Management 902 Protocols", draft-ietf-sip-media-security-requirements-07 903 (work in progress), June 2008. 905 [I-D.ietf-sip-saml] 906 Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. 907 Sicker, "SIP SAML Profile and Binding", 908 draft-ietf-sip-saml-04 (work in progress), July 2008. 910 [I-D.ietf-sip-sips] 911 Audet, F., "The use of the SIPS URI Scheme in the Session 912 Initiation Protocol (SIP)", draft-ietf-sip-sips-08 (work 913 in progress), February 2008. 915 [I-D.ietf-sipping-config-framework] 916 Channabasappa, S., "A Framework for Session Initiation 917 Protocol User Agent Profile Delivery", 918 draft-ietf-sipping-config-framework-15 (work in progress), 919 February 2008. 921 [I-D.zimmermann-avt-zrtp] 922 Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 923 Path Key Agreement for Secure RTP", 924 draft-zimmermann-avt-zrtp-10 (work in progress), 925 October 2008. 927 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 928 May 2000. 930 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 931 Camarillo, "Best Current Practices for Third Party Call 932 Control (3pcc) in the Session Initiation Protocol (SIP)", 933 BCP 85, RFC 3725, April 2004. 935 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 936 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 937 August 2004. 939 [RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. van 940 Wijk, "Transcoding Services Invocation in the Session 941 Initiation Protocol (SIP) Using Third Party Call Control 942 (3pcc)", RFC 4117, June 2005. 944 [RFC4317] Johnston, A. and R. Sparks, "Session Description Protocol 945 (SDP) Offer/Answer Examples", RFC 4317, December 2005. 947 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 948 Carrara, "Key Management Extensions for Session 949 Description Protocol (SDP) and Real Time Streaming 950 Protocol (RTSP)", RFC 4567, July 2006. 952 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 953 Description Protocol (SDP) Security Descriptions for Media 954 Streams", RFC 4568, July 2006. 956 Appendix A. Outstanding Issues 958 Authors' to-do list: 960 o Separate B2BUA function from media relay function in the call 961 flows and in the text. 963 o Add flows for Active recording mode. Should we use DTLS-SRTP 964 without a separate SIP session? 966 Authors' Addresses 968 Dan Wing 969 Cisco Systems, Inc. 970 170 West Tasman Drive 971 San Jose, CA 95134 972 USA 974 Email: dwing@cisco.com 976 Francois Audet 977 Nortel 978 4655 Great America Parkway 979 Santa Clara, CA 95054 980 USA 982 Email: audet@nortel.com 984 Steffen Fries 985 Siemens AG 986 Otto-Hahn-Ring 6 987 Munich, Bavaria 81739 988 Germany 990 Email: steffen.fries@siemens.com 992 Hannes Tschofenig 993 Nokia Siemens Networks 994 Otto-Hahn-Ring 6 995 Munich, Bavaria 81739 996 Germany 998 Email: Hannes.Tschofenig@nsn.com 999 URI: http://www.tschofenig.priv.at 1001 Alan Johnston 1002 Avaya 1003 St. Louis, MO 1004 USA 1006 Email: alan@sipstation.com 1008 Full Copyright Statement 1010 Copyright (C) The IETF Trust (2008). 1012 This document is subject to the rights, licenses and restrictions 1013 contained in BCP 78, and except as set forth therein, the authors 1014 retain all their rights. 1016 This document and the information contained herein are provided on an 1017 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1018 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1019 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1020 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1021 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1022 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1024 Intellectual Property 1026 The IETF takes no position regarding the validity or scope of any 1027 Intellectual Property Rights or other rights that might be claimed to 1028 pertain to the implementation or use of the technology described in 1029 this document or the extent to which any license under such rights 1030 might or might not be available; nor does it represent that it has 1031 made any independent effort to identify any such rights. Information 1032 on the procedures with respect to rights in RFC documents can be 1033 found in BCP 78 and BCP 79. 1035 Copies of IPR disclosures made to the IETF Secretariat and any 1036 assurances of licenses to be made available, or the result of an 1037 attempt made to obtain a general license or permission for the use of 1038 such proprietary rights by implementers or users of this 1039 specification can be obtained from the IETF on-line IPR repository at 1040 http://www.ietf.org/ipr. 1042 The IETF invites any interested party to bring to its attention any 1043 copyrights, patents or patent applications, or other proprietary 1044 rights that may cover technology that may be required to implement 1045 this standard. Please address the information to the IETF at 1046 ietf-ipr@ietf.org. 1048 Acknowledgment 1050 This document was produced using xml2rfc v1.33 (of 1051 http://xml.resource.org/) from a source in RFC-2629 XML format.