idnits 2.17.00 (12 Aug 2021) /tmp/idnits21566/draft-wing-sipping-srtp-key-00.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 495. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 17, 2007) is 5572 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-sipping-config-framework has been published as RFC 6080 == Outdated reference: draft-ietf-sip-sips has been published as RFC 5630 == Outdated reference: draft-ietf-sip-certs has been published as RFC 6072 == 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 Network Working Group D. Wing 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track F. Audet 5 Expires: August 21, 2007 Nortel 6 S. Fries 7 Siemens AG 8 H. Tschofenig 9 Siemens Networks GmbH & Co KG 10 February 17, 2007 12 Disclosing Secure RTP (SRTP) Session Keys with a SIP Event Package 13 draft-wing-sipping-srtp-key-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 21, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 Many Secure RTP (SRTP) key exchange mechanisms do not disclose the 47 SRTP session keys to intermediate SIP proxies. However, these key 48 exchange mechanisms cannot be used In environments where transcoding, 49 monitoring, or call recording are needed. This document specifies a 50 secure mechanism for a cooperating endpoint to disclose its SRTP 51 master keys to an authorized party. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Learning Name and Certificate of ESC . . . . . . . . . . . 5 59 3.2. Sending SRTP Session Keys to ESC . . . . . . . . . . . . . 5 60 4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 5.1. Incorrect ESC . . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. Risks of Sharing SRTP Session Key . . . . . . . . . . . . 7 64 5.3. Disclosure Flag . . . . . . . . . . . . . . . . . . . . . 7 65 5.4. Integrity and encryption of keying information . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 70 8.2. Informational References . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 72 Intellectual Property and Copyright Statements . . . . . . . . . . 12 74 1. Introduction 76 This document addresses 2 difficulties with end-to-end encryption of 77 RTP (SRTP [RFC3711]): transcoding and media recording. When peering 78 with other networks, different codecs are sometimes necessary 79 (transcoding a surround-sound codec for transmission over a highly- 80 compressed bandwidth-constrained network, for example). In some 81 environments (e.g., stock brokerages and banks) regulations and 82 business needs require recording calls with coworkers or with 83 customers. In many environments, quality problems such as echo can 84 only be diagnosed by listening to the call (analyzing SRTP headers is 85 not sufficient). 87 With an RTP stream, transcoding is accomplished by modifying SDP to 88 offer a different codec through a transcoding device [RFC4117], and 89 call recording or monitoring can be accomplished with an Ethernet 90 sniffer listening for SIP and its associated RTP, with a media relay, 91 or with a Session Border Controller. However, when media is 92 encrypted end-to-end[I-D.wing-rtpsec-keying-eval], these existing 93 techniques fail because they are unable to decrypt the media packets. 95 When a media session is encrypted with SRTP, there are three 96 techniques to decrypt the media for monitoring or call recording: 98 1. the endpoint establishes a separate media stream to the recording 99 device, with a separate SRTP key, and sends the (mixed) media to 100 the recording device. The disadvantages of this technique 101 include doubling bandwidth requirements, loss of media recording 102 facility doesn't cause loss of call (as is required in some 103 environments). A significant advantage of this technique, 104 however, is that it's secure: a malicious media recording device 105 cannot inject media to the connected party on behalf of the 106 endpoint. Depending on the application requirements it may be 107 necessary to establish a reliable connection to the recording 108 device to cope with possible packet loss on the unreliable link, 109 typically used for media transport. 111 2. the endpoint relays media through a device which forks a separate 112 media stream to the recording device. This technique is often 113 employed by Session Border Controllers, and could also be 114 employed by TURN servers. 116 3. Network sniffing devices are used to listen to the SRTP traffic 117 and correlate SRTP with SIP (with cooperation of call signaling 118 devices, if the call signaling is encrypted). 120 This document describes cases (2) and (3) where a cooperating 121 endpoints publishes its SRTP master keys to an authorized party using 122 the SIP Event State Publication Extension [RFC3903]. The mechanism 123 described in this paper allows secure disclosure of SRTP session keys 124 to authorized parties so that an endpoints media stream can be 125 transcoded or decrypted, as needed by that environment. 127 2. Terminology 129 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 The following terminology is taken directly from SIP Event State 134 Publication Extension [RFC3903]: 136 Event Publication Agent (EPA): The User Agent Client (UAC) that 137 issues PUBLISH requests to publish event state. 139 Event State Compositor (ESC): The User Agent Server (UAS) that 140 processes PUBLISH requests, and is responsible for compositing 141 event state into a complete, composite event state of a resource. 143 Publication: The act of an EPA sending a PUBLISH request to an ESC 144 to publish event state. 146 3. Operation 148 For transcoding, RTP packets must be sent from and received by a 149 device which performs the transcoding. When the media is encrypted, 150 this device must be capable of decrypting the media, performing the 151 transcoding function, and re-encrypting the media. 153 ISSUE-1: should we consider providing some or all of the SIP 154 headers, as well? Some recording functions will need to know the 155 identity of the remote party. This information could be gleaned 156 from the SIP proxies, though, and starts to fall outside the 157 intended scope of this document. 159 ISSUE-2: The authors have been considering use of MIKEY 160 [RFC3830], but MIKEY may not be used off the shelf. Certain 161 changes to the state machine may have to be made (RFC3830 162 describes the TGK transport rather than SRTP master key 163 transport). 165 3.1. Learning Name and Certificate of ESC 167 The endpoint will be configured with the AOR of its ESC (e.g., 168 "transcoder@example.com"). If S/MIME is used to send the SRTP master 169 key to the ESC, the endpoint is additionally configured with the 170 certificate of its ESC. 172 This configuration is outside the scope of this document, but some 173 examples are CLI, [I-D.ietf-sipping-config-framework], or 174 [I-D.ietf-sip-certs]. 176 3.2. Sending SRTP Session Keys to ESC 178 SDP is used to describe the media session to the ESC. However, the 179 existing Security Descriptions [RFC4568] only describes the master 180 key and parameters of the SRTP packets being sent -- it does not 181 describe the master key (and parameters) of the SRTP being received, 182 or the SSRC being transmitted. For transcoding and media recording, 183 both the sending key and receiving key are needed and in some cases 184 the SSRC is needed. 186 Thus, we hereby extend the existing crypto attribute to indicate the 187 SSRC. We also create a new SDP attribute, "rcrypto", which is 188 identical to the existing "crypto" attribute, except that it 189 describes the receiving keys and their SSRCs. For example: 191 a=crypto:1 AES_CM_128_HMAC_SHA1_32 192 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 193 SSRC=1899 194 a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 195 inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKKIN1Mw|2^20|1:32 196 SSRC=3289 197 a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 198 inline:Hw3JFWNCFqSpTqNiYRj6HmSWKMHAmO4q1KIN1OVA|2^20|1:32 199 SSRC=4893 201 Figure 1: Example SDP 203 The full SDP, including the keying information, is then sent to the 204 ESC. The keying information MUST be encrypted and integrity 205 protected. Existing mechanisms such as S/MIME [RFC3261] and SIPS 206 [I-D.ietf-sip-sips] MAY be used to achieve this goal, or other 207 mechanisms may be defined. 209 [[ ISSUE-3: if a endpoint is receiving multiple incoming streams 210 from multiple endpoints, it will have negotiated different keys 211 with each of them, and all of that traffic is coming to the same 212 transport address on the endpoint. Thus, we need a way to 213 describe the different keys we're using to/from different 214 transport addresses. One solution is to indicate the remote 215 transport address. Indicating the remote SSRC is insufficient for 216 this task, as several SRTP keying mechanisms do not include SSRC 217 in their signaling (DTLS-SRTP, ZRTP, Security Descriptions). 219 For example, if there were two remote peers with different keys, 220 we could signal it like this: 222 a=crypto:1 AES_CM_128_HMAC_SHA1_32 223 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 224 192.0.2.1:5678 SSRC=1899 SSRC=3892 225 a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 226 inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKKIN1Mw|2^20|1:32 227 192.0.2.1:5678 SSRC=3289 SSRC=2813 228 a=crypto:1 AES_CM_128_HMAC_SHA1_32 229 inline:GdUJShpX1ZLEw6UzF3WSJjNzB4d1BINUAv+PSdFc|2^20|1:32 230 192.0.2.222:2893 231 a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 232 inline:6UzF3IN1ZLEwAv+PSdFcWUGdUJShpXSJjNzB4d1B|2^20|1:32 233 192.0.2.222:2893 235 Figure 2: Strawman solution 237 ]] 239 4. Grammar 241 [[Grammar will be provided in a subsequent version of this 242 document.]] 244 5. Security Considerations 246 5.1. Incorrect ESC 248 Insertion of the incorrect public key of the SRTP ESC will result in 249 disclosure of the SRTP session key to an unauthorized party. Thus, 250 the UA's configuration MUST be protected to prevent such 251 misconfiguration. If the configuration or the ESC's certificate are 252 obtained over the network [I-D.ietf-sipping-config-framework], 253 [I-D.ietf-sip-certs], the certificate MUST be suitably authenticated 254 and integrity protected. 256 5.2. Risks of Sharing SRTP Session Key 258 A party authorized to obtain the SRTP session key can listen to the 259 media stream and could inject data into the media stream as if it 260 were either party. The alternatives are worse: disclose the 261 device's private key to the transcoder or media recording device, or 262 abandon using secure SRTP key exchange in environments that require 263 media transcoding or media recording. As we wish to promote the use 264 of secure SRTP key exchange mechanisms, disclosure of the SRTP 265 session key appears the least of these evils. 267 5.3. Disclosure Flag 269 Secure SRTP key exchange techniques which implement this 270 specification SHOULD provide a "disclosure flag", similar to that 271 first proposed in Appendix B of [I-D.zimmermann-avt-zrtp]. 273 5.4. Integrity and encryption of keying information 275 The mechanism describe in this specification relies on protecting and 276 encrypting the keying information. There are well known mechanism to 277 achieve that goal. 279 Using SIPS to convey the SRTP key exposes the SRTP master key to all 280 SIP proxies between the Event Publication Agent (ESC, the SIP User 281 Agent) and the Event State Compositor (ESC). S/MIME allows 282 disclosing the SRTP master key to only the ESC. 284 6. IANA Considerations 286 New SSRC extension of the "crypto" attribute, and the new "rcrypto" 287 attribute will be registered here. 289 7. Examples 291 This is an example showing a SIPS AOR for the ESC. This relies on 292 the SIP network providing TLS encryption of the SRTP master keys to 293 the ESC. 295 PUBLISH sips:recorder@example.com SIP/2.0 296 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge 297 To: 298 From: ;tag=1234wxyz 299 Call-ID: 81818181@pua.example.com 300 CSeq: 1 PUBLISH 301 Max-Forwards: 70 302 Expires: 3600 303 Event: srtp 304 Content-Type: application/sdp 305 Content-Length: ... 307 v=0 308 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 309 s=- 310 c=IN IP4 192.0.2.101 311 t=0 0 312 m=audio 49172 RTP/SAVP 0 313 a=crypto:1 AES_CM_128_HMAC_SHA1_32 314 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 315 a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 316 inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32 317 a=rtpmap:0 PCMU/8000 319 Figure 3: Example with "SIPS:" AOR 321 This is an example showing an S/MIME-encrypted transmission to the 322 media recorder's AOR, recorder@example.com. The data enclosed in "*" 323 is encrypted with recorder@example.com's public key. 325 PUBLISH sip:recorder@example.com SIP/2.0 326 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge 327 To: 328 From: ;tag=1234wxyz 329 Call-ID: 81818181@pua.example.com 330 CSeq: 1 PUBLISH 331 Max-Forwards: 70 332 Expires: 3600 333 Event: srtp 334 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 335 name=smime.p7m 336 Content-Transfer-Encoding: binary 337 Content-ID: 1234@atlanta.example.com 338 Content-Disposition: attachment;filename=smime.p7m;handling=required 339 Content-Length: ... 341 ****************************************************************** 342 * (encryptedContentInfo) * 343 * Content-Type: application/sdp * 344 * Content-Length: ... * 345 * * 346 * v=0 * 347 * o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com* 348 * s=- * 349 * c=IN IP4 192.0.2.101 * 350 * t=0 0 * 351 * m=audio 49172 RTP/SAVP 0 * 352 * a=crypto:1 AES_CM_128_HMAC_SHA1_32 * 353 * inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 * 354 * a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 * 355 * inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32 * 356 * a=rtpmap:0 PCMU/8000 * 357 * * 358 ****************************************************************** 360 Figure 4: Example with S/MIME-encrypted SDP 362 8. References 364 8.1. Normative References 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, March 1997. 369 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 370 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 371 RFC 3711, March 2004. 373 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 374 for Event State Publication", RFC 3903, October 2004. 376 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 377 A., Peterson, J., Sparks, R., Handley, M., and E. 378 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 379 June 2002. 381 8.2. Informational References 383 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 384 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 385 August 2004. 387 [I-D.wing-rtpsec-keying-eval] 388 Audet, F. and D. Wing, "Evaluation of SRTP Keying with 389 SIP", draft-wing-rtpsec-keying-eval-02 (work in progress), 390 February 2007. 392 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 393 Description Protocol (SDP) Security Descriptions for Media 394 Streams", RFC 4568, July 2006. 396 [I-D.ietf-sipping-config-framework] 397 Petrie, D. and S. Channabasappa, "A Framework for Session 398 Initiation Protocol User Agent Profile Delivery", 399 draft-ietf-sipping-config-framework-10 (work in progress), 400 January 2007. 402 [I-D.ietf-sip-sips] 403 Audet, F., "Guidelines for the use of the SIPS URI Scheme 404 in the Session Initiation Protocol (SIP)", 405 draft-ietf-sip-sips-01 (work in progress), February 2007. 407 [I-D.ietf-sip-certs] 408 Jennings, C., "Certificate Management Service for The 409 Session Initiation Protocol (SIP)", 410 draft-ietf-sip-certs-02 (work in progress), October 2006. 412 [I-D.zimmermann-avt-zrtp] 413 Zimmermann, P., "ZRTP: Extensions to RTP for Diffie- 414 Hellman Key Agreement for SRTP", 415 draft-zimmermann-avt-zrtp-02 (work in progress), 416 October 2006. 418 [RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. van 419 Wijk, "Transcoding Services Invocation in the Session 420 Initiation Protocol (SIP) Using Third Party Call Control 421 (3pcc)", RFC 4117, June 2005. 423 Authors' Addresses 425 Dan Wing 426 Cisco Systems 427 170 West Tasman Drive 428 San Jose, CA 95134 429 USA 431 Email: dwing@cisco.com 433 Francois Audet 434 Nortel 435 4655 Great America Parkway 436 Santa Clara, CA 95054 437 USA 439 Email: audet@nortel.com 441 Steffen Fries 442 Siemens AG 443 Otto-Hahn-Ring 6 444 Munich, Bavaria 81739 445 Germany 447 Email: steffen.fries@siemens.com 449 Hannes Tschofenig 450 Siemens Networks GmbH & Co KG 451 Otto-Hahn-Ring 6 452 Munich, Bavaria 81739 453 Germany 455 Email: Hannes.Tschofenig@siemens.com 457 Full Copyright Statement 459 Copyright (C) The IETF Trust (2007). 461 This document is subject to the rights, licenses and restrictions 462 contained in BCP 78, and except as set forth therein, the authors 463 retain all their rights. 465 This document and the information contained herein are provided on an 466 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 467 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 468 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 469 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 470 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 471 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 473 Intellectual Property 475 The IETF takes no position regarding the validity or scope of any 476 Intellectual Property Rights or other rights that might be claimed to 477 pertain to the implementation or use of the technology described in 478 this document or the extent to which any license under such rights 479 might or might not be available; nor does it represent that it has 480 made any independent effort to identify any such rights. Information 481 on the procedures with respect to rights in RFC documents can be 482 found in BCP 78 and BCP 79. 484 Copies of IPR disclosures made to the IETF Secretariat and any 485 assurances of licenses to be made available, or the result of an 486 attempt made to obtain a general license or permission for the use of 487 such proprietary rights by implementers or users of this 488 specification can be obtained from the IETF on-line IPR repository at 489 http://www.ietf.org/ipr. 491 The IETF invites any interested party to bring to its attention any 492 copyrights, patents or patent applications, or other proprietary 493 rights that may cover technology that may be required to implement 494 this standard. Please address the information to the IETF at 495 ietf-ipr@ietf.org. 497 Acknowledgment 499 Funding for the RFC Editor function is provided by the IETF 500 Administrative Support Activity (IASA).