idnits 2.17.00 (12 Aug 2021) /tmp/idnits17649/draft-wing-sipping-srtp-key-03.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 1001. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1012. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1019. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1025. 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 (February 24, 2008) is 5200 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: draft-ietf-sip-media-security-requirements has been published as RFC 5479 == Outdated reference: A later version (-08) exists of draft-ietf-sip-saml-03 == Outdated reference: draft-ietf-sip-sips has been published as RFC 5630 == Outdated reference: draft-ietf-sipping-config-framework has been published as RFC 6080 == Outdated reference: draft-zimmermann-avt-zrtp has been published as RFC 6189 Summary: 1 error (**), 0 flaws (~~), 6 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: August 27, 2008 Nortel 6 S. Fries 7 Siemens AG 8 H. Tschofenig 9 Nokia Siemens Networks 10 A. Johnston 11 Avaya 12 February 24, 2008 14 Secure Media Recording and Transcoding with the Session Initiation 15 Protocol 16 draft-wing-sipping-srtp-key-03 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 August 27, 2008. 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 . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . 23 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". 106 Note that the services and examples in this document are not 107 wiretapping as defined in Raven [RFC2804]. Specifically, all 108 recording done by enterprises is always announced to both parties. 109 Also, in most circumstances, the intent of the recording is to 110 protect both parties from later disagreements about what was said 111 during the conversation or to remedy mistakes made. 113 First, four different recording modes are discussed. Then example 114 call flows for how this can be accomplished using standard SIP 115 primitives. Finally, the impact of encrypted media, SRTP, is 116 discussed. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119] and indicate 123 requirement levels for compliant mechanisms. 125 The following terminology is taken directly from SIP Event State 126 Publication Extension [RFC3903]: 128 Event Publication Agent (EPA): The User Agent Client (UAC) that 129 issues PUBLISH requests to publish event state. 131 Event State Compositor (ESC): The User Agent Server (UAS) that 132 processes PUBLISH requests, and is responsible for compositing 133 event state into a complete, composite event state of a resource. 135 Publication: The act of an EPA sending a PUBLISH request to an ESC 136 to publish event state. 138 3. Introduction to SRTP Call Recording 140 This document addresses two difficulties with End-to-end encryption 141 of RTP (SRTP [RFC3711]): transcoding and media recording. When 142 peering with other networks, different codecs are sometimes necessary 143 (e.g., transcoding a surround-sound codec for transmission over a 144 highly-compressed bandwidth-constrained network). In some 145 environments (e.g., stock brokerages and banks) regulations and 146 business needs require recording calls with coworkers or with 147 customers. In many environments, quality problems such as echo can 148 only be diagnosed by listening to the call (analyzing SRTP headers is 149 not sufficient). 151 With an RTP stream, transcoding is accomplished by modifying SDP to 152 offer a different codec through a transcoding device [RFC4117], and 153 call recording or monitoring can be accomplished with an Ethernet 154 sniffer listening for SIP and its associated RTP, with a media relay, 155 or with a Session Border Controller. However, when media is 156 encrypted end-to-end [I-D.ietf-sip-media-security-requirements], 157 these existing techniques fail because they are unable to decrypt the 158 media packets. 160 When a media session is encrypted with SRTP, there are three 161 techniques to decrypt the media for monitoring or call recording: 163 1. the endpoint establishes a separate media stream to the recording 164 device, with a separate SRTP key, and sends the (mixed) media to 165 the recording device. This techniques is often called 'active 166 recording'. The disadvantages of this technique include doubling 167 bandwidth requirements in the network and additionally the 168 processing power on the client side. Moreover, the loss of media 169 recording facility doesn't cause loss of call (as is required in 170 some environments). Depending on the application requirements it 171 may be necessary to establish a reliable connection to the 172 recording device to cope with possible packet loss on the 173 unreliable link, typically used for media transport. Because the 174 endpoint maintains its own key with the connected party, this 175 technique is more secure: a malicious media recording device 176 cannot inject media to the connected party on behalf of the 177 endpoint. 179 2. the endpoint relays media through a device which forks a separate 180 media stream to the recording device. This technique is often 181 employed by Session Border Controllers. This relay does not, 182 itself, have access to the SRTP key. 184 3. Network monitoring devices are used to listen to the SRTP traffic 185 and correlate SRTP with SIP. This correlation requires 186 cooperation of call signaling devices if the call signaling is 187 encrypted (e.g., with TLS). 189 This document describes cases (2) and (3) where a cooperating 190 endpoint publishes its SRTP master keys to an authorized party using 191 the SIP Event State Publication Extension [RFC3903]. The mechanism 192 can be described as passive recording, as the client is not directly 193 involved with the media recording. The client merely provides the 194 key information to a recording device. The mechanism described in 195 this paper allows secure disclosure of SRTP session keys to 196 authorized parties so that an endpoints media stream can be 197 transcoded or decrypted, as needed by that environment. Technique 198 (1) stated above is not considered further in this document, as it 199 does not require the disclosure of the key used for the communication 200 between the two endpoints. 202 4. Recording Modes 204 There are four common modes of call recording which are described in 205 the following sections. 207 4.1. Always On Recording 209 In the Always On recording mode, for an identified endpoint, phone 210 number, user or agent, all calls both incoming and outgoing are 211 recorded. For example, a toll free call to a helpline could utilize 212 this mode to record the entire text of calls. 214 4.2. Recording On Demand 216 In the Recording On Demand recording mode, only certain calls are 217 recorded. For example, in a call center application, personal or 218 non-call center calls by an agent might not be recorded. 220 4.3. Required Recording 222 In the Required Recording mode, the requirement for recording is so 223 strong that if call recording resources are unavailable, the call 224 must not be setup or an existing call must be disconnected. 226 4.4. Pause and Resume Recording 228 In the Pause and Resume Recording Mode, only parts of a given call 229 may be recorded. For example, when the call is placed on hold, 230 recording may be paused and resumed when the call is resumed. Or, 231 IVR interactions in which a user enters account numbers and pin 232 numbers should not be recorded, as the DTMF tones convey private or 233 secure information. Pausing can be unidirectional or bi-directional. 235 5. Recording Call Flows 237 This section will show how these four recording modes can be 238 implemented . 240 In SIP call recording, the two-way RTP or SRTP media session between 241 two UAs is sent to a UA referred to as a Recording UA. While it is 242 possible for recording to be done locally in a UA, this has no impact 243 on the SIP call flows. 245 While it is also possible for the recording policy and decision 246 making to be included in an endpoint, it is more common to have a 247 third party control recording and cause the RTP or SRTP to be sent to 248 the Recording UA. In these call flows, this third party will be 249 called the Controller. 251 If the Controller acts as a third party call controller (3PCC) 252 [RFC3725], it is possible for the Controller to cause each UA to send 253 an extra media stream to the Recorder. However, for this call flow 254 to work: 256 1. Both UAs must support multiple media lines and streams sent to 257 different addresses (e.g., Section 2.4 of SDP Examples 258 [RFC4317]). 260 2. Both UAs must have twice the normal bandwidth available. 262 3. Both UAs must know to send the same media on both media streams. 264 While 1 and 2 are possible, 3 is the most difficult. Without 265 additional information in the SDP, each media stream is considered a 266 separate media stream. 268 Alternatively, the Controller could be a combination of a SIP Proxy 269 and a media relay (e.g., a Session Border Controller). This media 270 relay would copy media streams to a second location. The protocol 271 and coordination between these two elements is outside the scope of 272 this specification. In another model discussed in Section 5, the 273 Controller could be a SIP Focus and a Media Server with some special 274 logic. Finally, the Controller could be realized as a B2BUA. 276 Using this model, there are no SIP, SDP, or bandwidth requirements on 277 either UA. The Controller then can cause the media received at the 278 Media Relay to be copied to the Recorder. An example is shown in 279 Figure 1, below where the Recorder records a call between Alice and 280 Bob. 282 Alice Controller Bob Recorder 283 | | | | 284 | INVITE F1 | | | 285 |--------------->| | | 286 |(100 Trying) F2 | | | 287 |<---------------| INVITE F3 | | 288 | |--------------------------------->| 289 | | | 200 OK F4 | 290 | |<---------------------------------| 291 | | | ACK F5 | 292 | |--------------------------------->| 293 | | INVITE F6 | | 294 | |------------->| | 295 | |180 Ringing F7| | 296 | |<-------------| | 297 | 180 Ringing F5 | | | 298 |<---------------| 200 OK F6 | | 299 | |<-------------| | 300 | 200 OK F7 | | | 301 |<---------------| | | 302 | ACK F8 | | | 303 |--------------->| ACK F9 | | 304 | |------------->| | 305 | | INVITE F10 | | 306 | |--------------------------------->| 307 | | | 200 OK F11 | 308 | |<---------------------------------| 309 | | | ACK F12 | 310 | |--------------------------------->| 311 | Both way SRTP Established | | 312 |<==============>|<============>| | 313 | | SRTP From Alice | 314 | |=================================>| 315 | | SRTP From Bob | 316 | |=================================>| 318 Figure 1: Controller Proxy or B2BUA 320 The following sections will discuss and extend this basic call flow 321 for the four recording modes. 323 5.1. Always On Recording 325 The Always On recording mode for the user Bob can be implemented 326 using the call flow of Figure 1 if every call made to Bob is handled 327 in this way. 329 5.2. Recording On Demand 331 In the Recording On Demand recording mode, the call flow of Figure 1 332 is used selectively - only for the calls that need to be recorded. 333 For the non-recorded flows, the Controller could act as a Proxy 334 Server and make no changes to the signaling or media flows. By not 335 inserting a Record-Route, the Controller could even drop out of the 336 SIP dialog for calls where recording is not of interest. 338 5.3. Required Recording 340 Required recording could also be implemented using Figure 1, as the 341 INVITE is sent first to the Recorder before being sent to Bob. As a 342 result, if the INVITE is refused (i.e., the Recorder is unable to 343 record the call), the INVITE will not be forwarded to Bob and the 344 call refused. Also, if the Recorder disconnects during the call or 345 is unable to provide recording resources (i.e., disks full, etc.), 346 the BYE from the Recorder can be used to terminate the call to Bob. 347 This is show in Figure 2, below. 349 Alice Controller Bob Recorder 350 | | | | 351 | Both way SRTP Established | | 352 |<==============>|<============>| | 353 | | SRTP From Alice | 354 | |=================================>| 355 | | SRTP From Bob | 356 | |=================================>| 357 | | | | 358 | | BYE F1 | 359 | |<---------------------------------| 360 | | 200 OK F2 | 361 | |--------------------------------->| 362 | | | | 363 | BYE F3 | | | 364 |<---------------| | | 365 | 200 OK F4 | | | 366 |--------------->| | | 368 Figure 2: Required Recording Call Flow 370 5.4. Pause and Resume Recording Call Flow 372 The Pause and Resume recording mode can be initiated by the call flow 373 of Figure 2. When the recording is to be paused, for example, when 374 the caller Alice places the call on hold, the hold re-INVITE from 375 Alice causes the Controller to place the call to the Recorder on hold 376 as well. No media is sent to the Recorder until a re-INVITE starts 377 the recording again, as shown in Figure 3, below. 379 Alice Controller Bob Recorder 380 | | | | 381 | Both way SRTP Established | | 382 |<==============>|<=============>| | 383 | | SRTP From Alice | 384 | |=================================>| 385 | | SRTP From Bob | 386 | |=================================>| 387 | INVITE (hold) F1 | | 388 |--------------->| INVITE (inactive) F2 | 389 | |--------------------------------->| 390 | | 200 OK (inactive) F4 | 391 | |<---------------------------------| 392 | | | ACK F5 | 393 | |--------------------------------->| 394 | |INVITE (hold) F6 | 395 | |------------->| | 396 | |200 OK (hold) F7 | 397 | |<-------------| | 398 | 200 OK (hold) F8 | | 399 |<---------------| | | 400 | ACK F8 | | | 401 |--------------->| ACK F9 | | 402 | |------------->| | 403 | | | | 404 | No SRTP Sent | 406 Figure 3: Pause and Resume Call Flow 408 5.5. Conference Recording 410 A call flow for conference recording is shown in Figure 4, below. 411 This call flow is similar to the previous ones except with a focus 412 instead of the Controller. The recorder SUBSCRIBEs to the focus 413 using the conference event package to learn of call recording events 414 of interest to the Recorder. 416 With the subscription established by the SUBSCRIBE, the Recorder 417 receives NOTIFYs whenever recording events of interest occur from the 418 Controller. For example, the Recorder is informed when Alice joins 419 the conference, but recording is not initiated. When notification 420 that Bob has joined the conference is received in a NOTIFY, F7, is 421 sent. In this example, the Recorder decides to record the call and 422 sends a INVITE with Join to the Controller, F16. The dialog 423 information used to construct the Join header field is obtained using 424 the NOTIFY, F13. The Focus/Mixer then begins to stream the media to 425 the Recorder for the duration of the conference. 427 This model could be used for other recording modes. In this case, 428 the event package would be a new event package specifically tailored 429 to the recording application, containing all the information needed 430 by a Recorder to make a decision on whether or not to record a call. 431 The details of this event package may be defined in a future draft. 432 Note that presently, CTI (Computer Telephone Integration) protocols 433 are used for this purpose today. 435 Alice Focus/Mixer Bob Recorder 436 | | | | 437 | | SUBSCRIBE F1 | 438 | |<---------------------------------| 439 | | | 200 OK F2 | 440 | |--------------------------------->| 441 | | NOTIFY F3 | | 442 | |--------------------------------->| 443 | | | 200 OK F4 | 444 | |<---------------------------------| 445 | INVITE F5 | | | 446 |--------------->| | | 447 | 200 OK F6 | | | 448 |<---------------| | | 449 | ACK F7 | | | 450 |--------------->| | | 451 | SRTP | NOTIFY F8 | | 452 |<==============>|--------------------------------->| 453 | | | 200 OK F9 | 454 | |<---------------------------------| 455 | | INVITE F10 | | 456 | |<-------------| | 457 | |180 Ringing F11 | 458 | |------------->| | 459 | | 200 OK F12 | | 460 | |------------->| | 461 | | SRTP | | 462 | |<============>| | 463 | | NOTIFY F13 | | 464 | |--------------------------------->| 465 | | | 200 OK F14 | 466 | |<---------------------------------| 467 | | INVITE Join: A-B F15 | 468 | |<---------------------------------| 469 | | | 200 OK F16 | 470 | |--------------------------------->| 471 | | | ACK F17 | 472 | |<---------------------------------| 473 | | Mixed SRTP from Alice and Bob | 474 | |=================================>| 476 Figure 4: Conference Recording Call Flow 478 6. Transcoding 480 There are similarities between transcoding and call recording, 481 especially technique 2 described in Section 3. An endpoint that 482 desires transcoding can provide its SRTP key to a transcoder and 483 request its services. 485 [[This section is a placeholder, and will be expanded in a later 486 version of this document.]] 488 7. Media Considerations 490 The following sections will discuss considerations relating to the 491 media streams. 493 7.1. Offer/Answer Considerations 495 For the call flows in this document, it is assumed that a single bi- 496 directional media stream is to be recorded. Normally, this would be 497 negotiated using a single media line (m= line) in the SDP with a 498 default direction attribute (a=sendrcv). The media stream sent from 499 the Controller to the Recorder could be done in two different ways, 500 depending on the media handling in the Controller. In the simplest 501 case, each direction of the media stream between Alice and Bob could 502 be converted to a separate uni-directional media stream sent to the 503 Controller. In the INVITE from the Controller to the Recorder, for a 504 single recording session, there would be two media lines (m=) with 505 each marked as send only (a=sendonly). This has the advantage that 506 the Controller does not have to perform any processing on the RTP 507 packets - they are simply forwarded without changing SSRC or sequence 508 numbers. The Recording device will then mix the packets together or 509 possibly record the two sides of the conversation separately, if 510 desired. 512 In the other model, the Controller can function as an RTP mixer, in 513 which case a single uni-directional media stream will be used with a 514 single media line. The Controller will need to process the RTP 515 packets by mixing them and including its own SSRC and sequence number 516 in the resulting RTP packets. The Recorder will then not have to mix 517 them and will not have the option of recording the two sides 518 separately. 520 The approach of using two separate media lines is the recommended one 521 as it allows for simple RTP packet processing at the Controller and 522 also provides recording flexibility at the Recorder. However, a 523 Recorder should also be able to handle the case where the Controller 524 performs the mixing as well. 526 7.2. Operation 528 For transcoding, RTP packets must be sent from and received by a 529 device which performs the transcoding. When the media is encrypted, 530 this device must be capable of decrypting the media, performing the 531 transcoding function, and re-encrypting the media. 533 ISSUE-1: should we consider providing some or all of the SIP 534 headers, as well? Some recording functions will need to know the 535 identity of the remote party. This information could be gleaned 536 from the SIP proxies, though, and starts to fall outside the 537 intended scope of this document. 539 ISSUE-2: The authors have been considering use of MIKEY 540 [RFC3830], but MIKEY may not be used off the shelf. Certain 541 changes to the state machine may have to be made (MIKEY [RFC3830] 542 describes the TGK transport rather than SRTP master key 543 transport). 545 7.2.1. Learning Name and Certificate of ESC 547 The endpoint will be configured with the AOR of its ESC (e.g., 548 "transcoder@example.com"). If S/MIME is used to send the SRTP master 549 key to the ESC, the endpoint is additionally configured with the 550 certificate of its ESC. 552 The name and public key of the ESC is configured into the endpoint. 553 It is vital that the public key of the ESC is not changed by an 554 unauthorized user. Changes to change that public key will cause SRTP 555 key disclosure to be encrypted with that key. It is RECOMMENDED that 556 endpoints restrict changing the public key of the disclosure device 557 using protections similar to changes to the endpoint's SIP username 558 and SIP password. 560 7.2.2. Authorization of ESC 562 Depending on the application, authorization of the key disclosure and 563 distribution to the ESC may be necessary besides the pure transport 564 security of the key distribution itself. This may be the case when 565 the configuration framework [I-D.ietf-sipping-config-framework] is 566 not applied and thus the information about the ESC is not known to 567 the client. 569 This can be done by providing a SAML extension [I-D.ietf-sip-saml] in 570 the header of the SUBSCRIBE message. The SAML assertion shall at 571 least contain the information about the ESC, call related information 572 to associate the call with the assertion (editors note: we may also 573 define wildcards here to allow for recordings of all phone calls for 574 a day, independent of the call) and a reference to the certificate 575 for the ESC. The latter information is needed to transport the SRTP 576 Session Key to the ESC in a protected manner, as described in the 577 section below. 579 The signature of the SAML assertion should be produced using the 580 private key of the domain certificate. This certificate MUST have a 581 SubjAltName which matches the domain of user agent's SIP proxy (that 582 is, if the SIP proxy is sip.example.com, the SubjAltName of the 583 domain certificate signing this SAML assertion MUST also be 584 example.com). Here, the main focus is placed on communication of 585 clients with the ESC, which belongs to the client's home domain. 587 7.2.3. Sending SRTP Session Keys to ESC 589 SDP is used to describe the media session to the ESC. However, the 590 existing Security Descriptions [RFC4568] only describes the master 591 key and parameters of the SRTP packets being sent -- it does not 592 describe the master key (and parameters) of the SRTP being received, 593 or the SSRC being transmitted. For transcoding and media recording, 594 both the sending key and receiving key are needed and in some cases 595 the SSRC is needed. 597 Thus, we hereby extend the existing crypto attribute to indicate the 598 SSRC. We also create a new SDP attribute, "rcrypto", which is 599 identical to the existing "crypto" attribute, except that it 600 describes the receiving keys and their SSRCs. For example: 602 a=crypto:1 AES_CM_128_HMAC_SHA1_80 603 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 604 SSRC=1899 605 a=rcrypto:1 AES_CM_128_HMAC_SHA1_80 606 inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKKIN1Mw|2^20|1:32 607 SSRC=3289 608 a=rcrypto:1 AES_CM_128_HMAC_SHA1_80 609 inline:Hw3JFWNCFqSpTqNiYRj6HmSWKMHAmO4q1KIN1OVA|2^20|1:32 610 SSRC=4893 612 Figure 5: Example SDP 614 The full SDP, including the keying information, is then sent to the 615 ESC. The keying information MUST be encrypted and integrity 616 protected. Existing mechanisms such as S/MIME [RFC3261] and SIPS 617 [I-D.ietf-sip-sips] or SIP over TLS (on all hops per administrative 618 means) MAY be used to achieve this goal, or other mechanisms may be 619 defined. 621 [[ ISSUE-3: if a endpoint is receiving multiple incoming streams 622 from multiple endpoints, it will have negotiated different keys 623 with each of them, and all of that traffic is coming to the same 624 transport address on the endpoint. Thus, we need a way to 625 describe the different keys we're using to/from different 626 transport addresses. One solution is to indicate the remote 627 transport address. Indicating the remote SSRC is insufficient for 628 this task, as several SRTP keying mechanisms do not include SSRC 629 in their signaling (DTLS-SRTP, ZRTP, Security Descriptions). 631 For example, if there were two remote peers with different keys, 632 we could signal it like this: 634 a=crypto:1 AES_CM_128_HMAC_SHA1_80 635 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 636 192.0.2.1:5678 SSRC=1899 SSRC=3892 637 a=rcrypto:1 AES_CM_128_HMAC_SHA1_80 638 inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKKIN1Mw|2^20|1:32 639 192.0.2.1:5678 SSRC=3289 SSRC=2813 640 a=crypto:1 AES_CM_128_HMAC_SHA1_80 641 inline:GdUJShpX1ZLEw6UzF3WSJjNzB4d1BINUAv+PSdFc|2^20|1:32 642 192.0.2.222:2893 643 a=rcrypto:1 AES_CM_128_HMAC_SHA1_80 644 inline:6UzF3IN1ZLEwAv+PSdFcWUGdUJShpXSJjNzB4d1B|2^20|1:32 645 192.0.2.222:2893 647 Figure 6: Strawman solution 649 ]] 651 7.2.4. Scenarios and Call Flows 653 The following scenarios and call flows depict the assumptions for the 654 provision of media key disclosure. Figure 7 shows the general setup 655 within the home domain of the client. Note that the authors assume 656 that the client only discloses media keys only to an entity in the 657 client's home network rather than to an arbitrary entity in the 658 visited network. 660 +----------+ +-------+ +---------+ +--------+ +----------+ 661 | SIP User | | SIP | |SIP Proxy| | Media | | SIP | 662 |Agent(EPA)| | Proxy | | (ESC) | |Recorder| |User Agent| 663 +----------+ +-------+ +---------+ +--------+ +----------+ 664 | | | | | 665 +----------+----------+-----------+-----------+ 667 Figure 7: Network Topology 669 Based on this setup there are different options to realize the key 670 disclosure, depending on the environment. In the following two 671 approaches are distinguished. 673 Publishing media keys to the ESC 675 This requires that the configuration management provides the ESC 676 configuration data (e.g., certificate, policy) in a secure way to 677 the client. As stated above, this configuration is outside the 678 scope of this document, but an example can be found in 679 [I-D.ietf-sipping-config-framework]. The key disclosure in this 680 approach uses the PUBLISH method to disclose the key to the ESC 681 according to a given policy. 683 +----------+ +-------+ +---------+ +--------+ +----------+ 684 | SIP User | | SIP | |SIP Proxy| | Media | | SIP | 685 |Agent(EPA)| | Proxy | | (ESC) | |Recorder| |User Agent| 686 +----------+ +-------+ +---------+ +--------+ +----------+ 687 | | | | | 688 |-REGISTER->| | | | 689 |<-200 OK---| | | | 690 | | | | | 691 |--INVITE-->|-------------INVITE------------->| 692 |<-200 Ok---|<------------200 Ok------------- | 693 | | | | | 694 |<====SRTP in both directions================>| 695 | | | | | 696 |-PUBLISH-->|-PUBLISH-->|-key----->| | 697 |<-200 Ok---|<--200 Ok--| | | 699 Figure 8: Message Flow showing Publishing of Media Keys to ESC 701 Note that the protocol between the ESC and the recorder is out of 702 scope of this document. 704 Using SAML assertions for ESC contact 706 In this approach authorization is provided via a SAML assertion, 707 see [I-D.ietf-sip-saml], indicating which ESC is allowed to 708 perform call recording of a single or a set of calls, depending on 709 the content of the assertion. Here a SAML assertion is provided 710 as part of the SUBSCRIBE message, send from the ESC to the client. 711 The assertion needs to provide at least the call relation, or a 712 time interval for which media recoding is going to be performed. 713 The SAML assertion is signed with the private key associated with 714 the domain certificate, which is in possession of the 715 authentication service. The call flow would look like following: 717 +----------+ +-------+ +---------+ +--------+ +----------+ 718 | SIP User | | SIP | |SIP Proxy| | Media | | SIP | 719 |Agent(EPA)| | Proxy | | (ESC) | |Recorder| |User Agent| 720 +----------+ +-------+ +---------+ +--------+ +----------+ 721 | | | | | 722 |-REGISTER->| | | | 723 |<-200 OK---| | | | 724 | | | | | 725 |<-SUBSCRIBE (SAML as.)-| | | 726 | | | | | 727 |--INVITE-->|-------------INVITE------------->| 728 |<-200 Ok---|<------------200 Ok------------- | 729 | | | | | 730 |<====SRTP in both directions================>| 731 | | | | | 732 |--NOTIFY (SRTP data)-->| | | 733 | | | | | 735 Figure 9: Message Flow Showing Publication using SAML 737 8. Grammar 739 [[Grammar will be provided in a subsequent version of this 740 document.]] 742 9. Security Considerations 744 9.1. Incorrect ESC 746 Insertion of the incorrect public key of the SRTP ESC will result in 747 disclosure of the SRTP session key to an unauthorized party. Thus, 748 the UA's configuration MUST be protected to prevent such 749 misconfiguration. To avoid changes to the configuration in the end 750 device, the configuration access MUST be suitably protected. 752 9.2. Risks of Sharing SRTP Session Key 754 A party authorized to obtain the SRTP session key can listen to the 755 media stream and could inject data into the media stream as if it 756 were either party. The alternatives are worse: disclose the 757 device's private key to the transcoder or media recording device, or 758 abandon using secure SRTP key exchange in environments that require 759 media transcoding or media recording. As we wish to promote the use 760 of secure SRTP key exchange mechanisms, disclosure of the SRTP 761 session key appears the least of these evils. 763 9.3. Disclosure of Call Recording 765 Secure SRTP key exchange techniques which implement this 766 specification SHOULD provide a "disclosure flag", similar to that 767 first proposed in Appendix B of [I-D.zimmermann-avt-zrtp]. In this 768 way, both endpoints can be made aware of such recording and provide 769 appropriate alerting to their users (via an audible, visual, or other 770 indicator). 772 9.4. Integrity and encryption of keying information 774 The mechanism describe in this specification relies on protecting and 775 encrypting the keying information. There are well known mechanism to 776 achieve that goal. 778 Using SIPS to convey the SRTP key exposes the SRTP master key to all 779 SIP proxies between the Event Publication Agent (ESC, the SIP User 780 Agent) and the Event State Compositor (ESC). S/MIME allows 781 disclosing the SRTP master key to only the ESC. 783 10. IANA Considerations 785 New SSRC extension of the "crypto" attribute, and the new "rcrypto" 786 attribute will be registered here. 788 11. Examples 790 This is an example showing a SIPS AOR for the ESC. This relies on 791 the SIP network providing TLS encryption of the SRTP master keys to 792 the ESC. 794 PUBLISH sips:recorder@example.com SIP/2.0 795 Via: SIP/2.0/TLS pua.example.com;branch=z9hG4bK652hsge 796 To: 797 From: ;tag=1234wxyz 798 Call-ID: 81818181@pua.example.com 799 CSeq: 1 PUBLISH 800 Max-Forwards: 70 801 Expires: 3600 802 Event: srtp 803 Content-Type: application/sdp 804 Content-Length: ... 806 v=0 807 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 808 s=- 809 c=IN IP4 192.0.2.101 810 t=0 0 811 m=audio 49172 RTP/SAVP 0 812 a=crypto:1 AES_CM_128_HMAC_SHA1_80 813 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 814 a=rcrypto:1 AES_CM_128_HMAC_SHA1_80 815 inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32 816 a=rtpmap:0 PCMU/8000 818 Figure 10: Example with "SIPS:" AOR 820 This is an example showing an S/MIME-encrypted transmission to the 821 recorder's AOR, recorder@example.com. The data enclosed in "*" is 822 encrypted with recorder@example.com's public key. 824 PUBLISH sip:recorder@example.com SIP/2.0 825 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge 826 To: 827 From: ;tag=1234wxyz 828 Call-ID: 81818181@pua.example.com 829 CSeq: 1 PUBLISH 830 Max-Forwards: 70 831 Expires: 3600 832 Event: srtp 833 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 834 name=smime.p7m 835 Content-Transfer-Encoding: binary 836 Content-ID: 1234@atlanta.example.com 837 Content-Disposition: attachment;filename=smime.p7m; 838 handling=required 839 Content-Length: ... 841 ****************************************************************** 842 * (encryptedContentInfo) * 843 * Content-Type: application/sdp * 844 * Content-Length: ... * 845 * * 846 * v=0 * 847 * o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com* 848 * s=- * 849 * c=IN IP4 192.0.2.101 * 850 * t=0 0 * 851 * m=audio 49172 RTP/SAVP 0 * 852 * a=crypto:1 AES_CM_128_HMAC_SHA1_80 * 853 * inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 * 854 * a=rcrypto:1 AES_CM_128_HMAC_SHA1_80 * 855 * inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32 * 856 * a=rtpmap:0 PCMU/8000 * 857 * * 858 ****************************************************************** 860 Figure 11: Example with S/MIME-encrypted SDP 862 12. Acknowledgements 864 Thanks to Sheldon Davis and Val Matula for suggesting improvements to 865 the document. 867 13. References 869 13.1. Normative References 871 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 872 Requirement Levels", BCP 14, RFC 2119, March 1997. 874 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 875 A., Peterson, J., Sparks, R., Handley, M., and E. 876 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 877 June 2002. 879 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 880 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 881 RFC 3711, March 2004. 883 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 884 for Event State Publication", RFC 3903, October 2004. 886 13.2. Informational References 888 [I-D.ietf-sip-media-security-requirements] 889 Wing, D., Fries, S., Tschofenig, H., and F. Audet, 890 "Requirements and Analysis of Media Security Management 891 Protocols", draft-ietf-sip-media-security-requirements-02 892 (work in progress), January 2008. 894 [I-D.ietf-sip-saml] 895 Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. 896 Sicker, "SIP SAML Profile and Binding", 897 draft-ietf-sip-saml-03 (work in progress), November 2007. 899 [I-D.ietf-sip-sips] 900 Audet, F., "The use of the SIPS URI Scheme in the Session 901 Initiation Protocol (SIP)", draft-ietf-sip-sips-08 (work 902 in progress), February 2008. 904 [I-D.ietf-sipping-config-framework] 905 Channabasappa, S., "A Framework for Session Initiation 906 Protocol User Agent Profile Delivery", 907 draft-ietf-sipping-config-framework-15 (work in progress), 908 February 2008. 910 [I-D.zimmermann-avt-zrtp] 911 Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure 912 RTP", draft-zimmermann-avt-zrtp-04 (work in progress), 913 July 2007. 915 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 916 May 2000. 918 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 919 Camarillo, "Best Current Practices for Third Party Call 920 Control (3pcc) in the Session Initiation Protocol (SIP)", 921 BCP 85, RFC 3725, April 2004. 923 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 924 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 925 August 2004. 927 [RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. van 928 Wijk, "Transcoding Services Invocation in the Session 929 Initiation Protocol (SIP) Using Third Party Call Control 930 (3pcc)", RFC 4117, June 2005. 932 [RFC4317] Johnston, A. and R. Sparks, "Session Description Protocol 933 (SDP) Offer/Answer Examples", RFC 4317, December 2005. 935 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 936 Description Protocol (SDP) Security Descriptions for Media 937 Streams", RFC 4568, July 2006. 939 Appendix A. Outstanding Issues 941 Authors' to-do list: 943 o Separate B2BUA function from media relay function in the call 944 flows and in the text. 946 Authors' Addresses 948 Dan Wing 949 Cisco Systems, Inc. 950 170 West Tasman Drive 951 San Jose, CA 95134 952 USA 954 Email: dwing@cisco.com 955 Francois Audet 956 Nortel 957 4655 Great America Parkway 958 Santa Clara, CA 95054 959 USA 961 Email: audet@nortel.com 963 Steffen Fries 964 Siemens AG 965 Otto-Hahn-Ring 6 966 Munich, Bavaria 81739 967 Germany 969 Email: steffen.fries@siemens.com 971 Hannes Tschofenig 972 Nokia Siemens Networks 973 Otto-Hahn-Ring 6 974 Munich, Bavaria 81739 975 Germany 977 Email: Hannes.Tschofenig@nsn.com 978 URI: http://www.tschofenig.com 980 Alan Johnston 981 Avaya 982 St. Louis, MO 983 USA 985 Email: alan@sipstation.com 987 Full Copyright Statement 989 Copyright (C) The IETF Trust (2008). 991 This document is subject to the rights, licenses and restrictions 992 contained in BCP 78, and except as set forth therein, the authors 993 retain all their rights. 995 This document and the information contained herein are provided on an 996 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 997 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 998 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 999 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1000 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1001 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1003 Intellectual Property 1005 The IETF takes no position regarding the validity or scope of any 1006 Intellectual Property Rights or other rights that might be claimed to 1007 pertain to the implementation or use of the technology described in 1008 this document or the extent to which any license under such rights 1009 might or might not be available; nor does it represent that it has 1010 made any independent effort to identify any such rights. Information 1011 on the procedures with respect to rights in RFC documents can be 1012 found in BCP 78 and BCP 79. 1014 Copies of IPR disclosures made to the IETF Secretariat and any 1015 assurances of licenses to be made available, or the result of an 1016 attempt made to obtain a general license or permission for the use of 1017 such proprietary rights by implementers or users of this 1018 specification can be obtained from the IETF on-line IPR repository at 1019 http://www.ietf.org/ipr. 1021 The IETF invites any interested party to bring to its attention any 1022 copyrights, patents or patent applications, or other proprietary 1023 rights that may cover technology that may be required to implement 1024 this standard. Please address the information to the IETF at 1025 ietf-ipr@ietf.org. 1027 Acknowledgment 1029 This document was produced using xml2rfc v1.33pre8 (of 1030 http://xml.resource.org/) from a source in RFC-2629 XML format.