idnits 2.17.00 (12 Aug 2021) /tmp/idnits22244/draft-wing-sipping-srtp-key-01.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 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 600. 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 (July 8, 2007) is 5431 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: A later version (-08) exists of draft-ietf-sip-saml-02 == 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: January 9, 2008 Nortel 6 S. Fries 7 Siemens AG 8 H. Tschofenig 9 Nokia Siemens Networks 10 July 8, 2007 12 Disclosing Secure RTP (SRTP) Session Keys with a SIP Event Package 13 draft-wing-sipping-srtp-key-01 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 January 9, 2008. 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. Howevr, 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. Authorization of ESC . . . . . . . . . . . . . . . . . . . 5 60 3.3. Sending SRTP Session Keys to ESC . . . . . . . . . . . . . 5 61 3.4. Scenarios and Call Flows . . . . . . . . . . . . . . . . . 7 62 4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 5.1. Incorrect ESC . . . . . . . . . . . . . . . . . . . . . . 9 65 5.2. Risks of Sharing SRTP Session Key . . . . . . . . . . . . 9 66 5.3. Disclosure Flag . . . . . . . . . . . . . . . . . . . . . 9 67 5.4. Integrity and encryption of keying information . . . . . . 9 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 8.2. Informational References . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 74 Intellectual Property and Copyright Statements . . . . . . . . . . 14 76 1. Introduction 78 This document addresses 2 difficulties with End-to-end encryption of 79 RTP (SRTP [RFC3711]): transcoding and media recording. When peering 80 with other networks, different codecs are sometimes necessary 81 (transcoding a surround-sound codec for transmission over a highly- 82 compressed bandwidth-constrained network, for example). In some 83 environments (e.g., stock brokerages and banks) regulations and 84 business needs require recording calls with coworkers or with 85 customers. In many environments, quality problems such as echo can 86 only be diagnosed by listening to the call (analyzing SRTP headers is 87 not sufficient). 89 With an RTP stream, transcoding is accomplished by modifying SDP to 90 offer a different codec through a transcoding device [RFC4117], and 91 call recording or monitoring can be accomplished with an Ethernet 92 sniffer listening for SIP and its associated RTP, with a media relay, 93 or with a Session Border Controller. However, when media is 94 encrypted end-to-end[I-D.wing-rtpsec-keying-eval], these existing 95 techniques fail because they are unable to decrypt the media packets. 97 When a media session is encrypted with SRTP, there are three 98 techniques to decrypt the media for monitoring or call recording: 100 1. the endpoint establishes a separate media stream to the recording 101 device, with a separate SRTP key, and sends the (mixed) media to 102 the recording device. The disadvantages of this technique 103 include doubling bandwidth requirements, loss of media recording 104 facility doesn't cause loss of call (as is required in some 105 environments). A significant advantage of this technique, 106 however, is that it's secure: a malicious media recording device 107 cannot inject media to the connected party on behalf of the 108 endpoint. Depending on the application requirements it may be 109 necessary to establish a reliable connection to the recording 110 device to cope with possible packet loss on the unreliable link, 111 typically used for media transport. 113 2. the endpoint relays media through a device which forks a separate 114 media stream to the recording device. This technique is often 115 employed by Session Border Controllers, and could also be 116 employed by TURN servers. 118 3. Network sniffing devices are used to listen to the SRTP traffic 119 and correlate SRTP with SIP (with cooperation of call signaling 120 devices, if the call signaling is encrypted). 122 This document describes cases (2) and (3) where a cooperating 123 endpoints publishes its SRTP master keys to an authorized party using 124 the SIP Event State Publication Extension [RFC3903]. The mechanism 125 described in this paper allows secure disclosure of SRTP session keys 126 to authorized parties so that an endpoints media stream can be 127 transcoded or decrypted, as needed by that environment. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 The following terminology is taken directly from SIP Event State 136 Publication Extension [RFC3903]: 138 Event Publication Agent (EPA): The User Agent Client (UAC) that 139 issues PUBLISH requests to publish event state. 141 Event State Compositor (ESC): The User Agent Server (UAS) that 142 processes PUBLISH requests, and is responsible for compositing 143 event state into a complete, composite event state of a resource. 145 Publication: The act of an EPA sending a PUBLISH request to an ESC 146 to publish event state. 148 3. Operation 150 For transcoding, RTP packets must be sent from and received by a 151 device which performs the transcoding. When the media is encrypted, 152 this device must be capable of decrypting the media, performing the 153 transcoding function, and re-encrypting the media. 155 ISSUE-1: should we consider providing some or all of the SIP 156 headers, as well? Some recording functions will need to know the 157 identity of the remote party. This information could be gleaned 158 from the SIP proxies, though, and starts to fall outside the 159 intended scope of this document. 161 ISSUE-2: The authors have been considering use of MIKEY 162 [RFC3830], but MIKEY may not be used off the shelf. Certain 163 changes to the state machine may have to be made (RFC3830 164 describes the TGK transport rather than SRTP master key 165 transport). 167 3.1. Learning Name and Certificate of ESC 169 The endpoint will be configured with the AOR of its ESC (e.g., 170 "transcoder@example.com"). If S/MIME is used to send the SRTP master 171 key to the ESC, the endpoint is additionally configured with the 172 certificate of its ESC. 174 This configuration is outside the scope of this document, but some 175 examples are CLI, [I-D.ietf-sipping-config-framework], or 176 [I-D.ietf-sip-certs]. 178 3.2. Authorization of ESC 180 Depending on the application, authorization of the key disclosure and 181 distribution to the ESC may be necessary besides the pure transport 182 security of the key distribution itself. This may be the case when 183 the config framework [I-D.ietf-sipping-config-framework] is not 184 applied and thus the information about the ESC is not known to the 185 client. 187 This can be done by providing a SAML extension, according to 188 [I-D.ietf-sip-saml] in the header of the SUBSCRIBE message. The SAML 189 assertion shall at least contain the information about the ESC, call 190 related information to associate the call with the assertion (editors 191 note: we may also define wildcards here to allow for recordings of 192 all phone calls for a day, independent of the call) and a reference 193 to the certificate for the ESC. The latter information is needed to 194 transport the SRTP Session Key to the ESC in a protected manner, as 195 described in the section below. 197 The signature of the SAML assertion should be produced using the 198 private key of the domain certificate. This certificate MUST have a 199 SubjAltName which matches the domain of user agent's SIP proxy (that 200 is, if the SIP proxy is sip.example.com, the SubjAltName of the 201 domain certificate signing this SAML assertion MUST also be 202 example.com). Here, the main focus is placed on communication of 203 clients with the ESC, which belongs to the client's home domain. 205 3.3. Sending SRTP Session Keys to ESC 207 SDP is used to describe the media session to the ESC. However, the 208 existing Security Descriptions [RFC4568] only describes the master 209 key and parameters of the SRTP packets being sent -- it does not 210 describe the master key (and parameters) of the SRTP being received, 211 or the SSRC being transmitted. For transcoding and media recording, 212 both the sending key and receiving key are needed and in some cases 213 the SSRC is needed. 215 Thus, we hereby extend the existing crypto attribute to indicate the 216 SSRC. We also create a new SDP attribute, "rcrypto", which is 217 identical to the existing "crypto" attribute, except that it 218 describes the receiving keys and their SSRCs. For example: 220 a=crypto:1 AES_CM_128_HMAC_SHA1_32 221 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 222 SSRC=1899 223 a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 224 inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKKIN1Mw|2^20|1:32 225 SSRC=3289 226 a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 227 inline:Hw3JFWNCFqSpTqNiYRj6HmSWKMHAmO4q1KIN1OVA|2^20|1:32 228 SSRC=4893 230 Figure 1: Example SDP 232 The full SDP, including the keying information, is then sent to the 233 ESC. The keying information MUST be encrypted and integrity 234 protected. Existing mechanisms such as S/MIME [RFC3261] and SIPS 235 [I-D.ietf-sip-sips] MAY be used to achieve this goal, or other 236 mechanisms may be defined. 238 [[ ISSUE-3: if a endpoint is receiving multiple incoming streams 239 from multiple endpoints, it will have negotiated different keys 240 with each of them, and all of that traffic is coming to the same 241 transport address on the endpoint. Thus, we need a way to 242 describe the different keys we're using to/from different 243 transport addresses. One solution is to indicate the remote 244 transport address. Indicating the remote SSRC is insufficient for 245 this task, as several SRTP keying mechanisms do not include SSRC 246 in their signaling (DTLS-SRTP, ZRTP, Security Descriptions). 248 For example, if there were two remote peers with different keys, 249 we could signal it like this: 251 a=crypto:1 AES_CM_128_HMAC_SHA1_32 252 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 253 192.0.2.1:5678 SSRC=1899 SSRC=3892 254 a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 255 inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKKIN1Mw|2^20|1:32 256 192.0.2.1:5678 SSRC=3289 SSRC=2813 257 a=crypto:1 AES_CM_128_HMAC_SHA1_32 258 inline:GdUJShpX1ZLEw6UzF3WSJjNzB4d1BINUAv+PSdFc|2^20|1:32 259 192.0.2.222:2893 260 a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 261 inline:6UzF3IN1ZLEwAv+PSdFcWUGdUJShpXSJjNzB4d1B|2^20|1:32 262 192.0.2.222:2893 264 Figure 2: Strawman solution 266 ]] 268 3.4. Scenarios and Call Flows 270 The following scenarios and call flows depict the assumptions for the 271 provision of media key disclosure. Figure 3 shows the general setup 272 within the home domain of the client. Note that the authors assume 273 that the client only discloses media keys only to an entity in the 274 client's home network rather than to an arbitrary entity in the 275 visited network. 277 +--------+ +-------+ +-------+ +--------+ 278 | Client | | Proxy | | ESC | | MedRec | 279 +--------+ +-------+ +-------+ +--------+ 280 | | | | 281 +---------------+--------------+--------------+ 283 Figure 3: Network Topology 285 Based on this setup there are different options to realize the key 286 disclosure, depending on the environment. In the following two 287 approaches are distingusihed. 289 Publishing media keys to the ESC 291 This requires that the configuration management provides the ESC 292 configuration data (e.g., certificate, policy) in a secure way to 293 the client. As stated above, this configuration is outside the 294 scope of this document, but an example can be found in 295 [I-D.ietf-sipping-config-framework]. The key disclosure in this 296 approach uses the PUBLISH method to disclose the key to the ESC 297 according to a given policy. 299 +--------+ +-------+ +-------+ +--------+ 300 | Client | | Proxy | | ESC | | MedRec | 301 +--------+ +-------+ +-------+ +--------+ 302 | | | | 303 | - REGISTER -> | | | 304 | <- 200 OK -- | | | 305 | | | | 306 | -- INVITE --> | | | 307 | <- 200 OK -- | | | 308 | | | | 309 | -- PUBLISH (Key Data) --> | | 310 | | | | 312 Using SAML assertions for ESC contact 314 In this approach authorization is provided via a SAML assertion, 315 see [I-D.ietf-sip-saml], indicating which ESC is allowed to 316 perform call recording of a single or a set of calls, depending on 317 the content of the assertion. Here a SAML assertion is provided 318 as part of the SUBSCRIBE message, send from the ESC to the client. 319 The assertion needs to provide at least the call relation, or a 320 time intervall for which media recoding is going to be performed. 321 The SAML assertion is signed with the private key associated with 322 the domain certificate, which is in possession of the 323 authentication service. The call flow would look like following: 325 +--------+ +-------+ +-------+ +--------+ 326 | Client | | Proxy | | ESC | | MedRec | 327 +--------+ +-------+ +-------+ +--------+ 328 | | | | 329 | - REGISTER -> | | | 330 | <- 200 OK -- | | | 331 | | | | 332 | <- SUBSCIBE (call forming) - | | 333 | + SAML assertion | | 334 | | | | 335 | -- INVITE --> | | | 336 | <- 200 OK -- | | | 337 | | | | 338 | -- NOTIFY (Key Data) --> | | 340 4. Grammar 342 [[Grammar will be provided in a subsequent version of this 343 document.]] 345 5. Security Considerations 347 5.1. Incorrect ESC 349 Insertion of the incorrect public key of the SRTP ESC will result in 350 disclosure of the SRTP session key to an unauthorized party. Thus, 351 the UA's configuration MUST be protected to prevent such 352 misconfiguration. If the configuration or the ESC's certificate are 353 obtained over the network [I-D.ietf-sipping-config-framework], 354 [I-D.ietf-sip-certs], the certificate MUST be suitably authenticated 355 and integrity protected. 357 5.2. Risks of Sharing SRTP Session Key 359 A party authorized to obtain the SRTP session key can listen to the 360 media stream and could inject data into the media stream as if it 361 were either party. The alternatives are worse: disclose the 362 device's private key to the transcoder or media recording device, or 363 abandon using secure SRTP key exchange in environments that require 364 media transcoding or media recording. As we wish to promote the use 365 of secure SRTP key exchange mechanisms, disclosure of the SRTP 366 session key appears the least of these evils. 368 5.3. Disclosure Flag 370 Secure SRTP key exchange techniques which implement this 371 specification SHOULD provide a "disclosure flag", similar to that 372 first proposed in Appendix B of [I-D.zimmermann-avt-zrtp]. 374 5.4. Integrity and encryption of keying information 376 The mechanism describe in this specification relies on protecting and 377 encrypting the keying infomation. There are well known mechanism to 378 achieve that goal. 380 Using SIPS to convey the SRTP key exposes the SRTP master key to all 381 SIP proxies between the Event Publication Agent (ESC, the SIP User 382 Agent) and the Event State Compositor (ESC). S/MIME allows 383 disclosing the SRTP master key to only the ESC. 385 6. IANA Considerations 387 New SSRC extension of the "crypto" attribute, and the new "rcrypto" 388 attribute will be registered here. 390 7. Examples 392 This is an example showing a SIPS AOR for the ESC. This relies on 393 the SIP network providing TLS encryption of the SRTP master keys to 394 the ESC. 396 PUBLISH sips:recorder@example.com SIP/2.0 397 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge 398 To: 399 From: ;tag=1234wxyz 400 Call-ID: 81818181@pua.example.com 401 CSeq: 1 PUBLISH 402 Max-Forwards: 70 403 Expires: 3600 404 Event: srtp 405 Content-Type: application/sdp 406 Content-Length: ... 408 v=0 409 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 410 s=- 411 c=IN IP4 192.0.2.101 412 t=0 0 413 m=audio 49172 RTP/SAVP 0 414 a=crypto:1 AES_CM_128_HMAC_SHA1_32 415 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 416 a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 417 inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32 418 a=rtpmap:0 PCMU/8000 420 Figure 6: Example with "SIPS:" AOR 422 This is an example showing an S/MIME-encrypted transmission to the 423 media recorder's AOR, recorder@example.com. The data enclosed in "*" 424 is encrypted with recorder@example.com's public key. 426 PUBLISH sip:recorder@example.com SIP/2.0 427 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge 428 To: 429 From: ;tag=1234wxyz 430 Call-ID: 81818181@pua.example.com 431 CSeq: 1 PUBLISH 432 Max-Forwards: 70 433 Expires: 3600 434 Event: srtp 435 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 436 name=smime.p7m 437 Content-Transfer-Encoding: binary 438 Content-ID: 1234@atlanta.example.com 439 Content-Disposition: attachment;filename=smime.p7m;handling=required 440 Content-Length: ... 442 ****************************************************************** 443 * (encryptedContentInfo) * 444 * Content-Type: application/sdp * 445 * Content-Length: ... * 446 * * 447 * v=0 * 448 * o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com* 449 * s=- * 450 * c=IN IP4 192.0.2.101 * 451 * t=0 0 * 452 * m=audio 49172 RTP/SAVP 0 * 453 * a=crypto:1 AES_CM_128_HMAC_SHA1_32 * 454 * inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 * 455 * a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 * 456 * inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32 * 457 * a=rtpmap:0 PCMU/8000 * 458 * * 459 ****************************************************************** 461 Figure 7: Example with S/MIME-encrypted SDP 463 8. References 465 8.1. Normative References 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 471 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 472 RFC 3711, March 2004. 474 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 475 for Event State Publication", RFC 3903, October 2004. 477 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 478 A., Peterson, J., Sparks, R., Handley, M., and E. 479 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 480 June 2002. 482 8.2. Informational References 484 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 485 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 486 August 2004. 488 [I-D.wing-rtpsec-keying-eval] 489 Audet, F. and D. Wing, "Evaluation of SRTP Keying with 490 SIP", draft-wing-rtpsec-keying-eval-02 (work in progress), 491 February 2007. 493 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 494 Description Protocol (SDP) Security Descriptions for Media 495 Streams", RFC 4568, July 2006. 497 [I-D.ietf-sipping-config-framework] 498 Petrie, D. and S. Channabasappa, "A Framework for Session 499 Initiation Protocol User Agent Profile Delivery", 500 draft-ietf-sipping-config-framework-12 (work in progress), 501 June 2007. 503 [I-D.ietf-sip-sips] 504 Audet, F., "The use of the SIPS URI Scheme in the Session 505 Initiation Protocol (SIP)", draft-ietf-sip-sips-05 (work 506 in progress), June 2007. 508 [I-D.ietf-sip-certs] 509 Jennings, C., "Certificate Management Service for The 510 Session Initiation Protocol (SIP)", 511 draft-ietf-sip-certs-03 (work in progress), March 2007. 513 [I-D.ietf-sip-saml] 514 Tschofenig, H., "SIP SAML Profile and Binding", 515 draft-ietf-sip-saml-02 (work in progress), May 2007. 517 [I-D.zimmermann-avt-zrtp] 518 Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure 519 RTP", draft-zimmermann-avt-zrtp-03 (work in progress), 520 March 2007. 522 [RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. van 523 Wijk, "Transcoding Services Invocation in the Session 524 Initiation Protocol (SIP) Using Third Party Call Control 525 (3pcc)", RFC 4117, June 2005. 527 Authors' Addresses 529 Dan Wing 530 Cisco Systems, Inc. 531 170 West Tasman Drive 532 San Jose, CA 95134 533 USA 535 Email: dwing@cisco.com 537 Francois Audet 538 Nortel 539 4655 Great America Parkway 540 Santa Clara, CA 95054 541 USA 543 Email: audet@nortel.com 545 Steffen Fries 546 Siemens AG 547 Otto-Hahn-Ring 6 548 Munich, Bavaria 81739 549 Germany 551 Email: steffen.fries@siemens.com 553 Hannes Tschofenig 554 Nokia Siemens Networks 555 Otto-Hahn-Ring 6 556 Munich, Bavaria 81739 557 Germany 559 Email: Hannes.Tschofenig@nsn.com 560 URI: http://www.tschofenig.com 562 Full Copyright Statement 564 Copyright (C) The IETF Trust (2007). 566 This document is subject to the rights, licenses and restrictions 567 contained in BCP 78, and except as set forth therein, the authors 568 retain all their rights. 570 This document and the information contained herein are provided on an 571 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 572 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 573 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 574 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 575 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 576 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 578 Intellectual Property 580 The IETF takes no position regarding the validity or scope of any 581 Intellectual Property Rights or other rights that might be claimed to 582 pertain to the implementation or use of the technology described in 583 this document or the extent to which any license under such rights 584 might or might not be available; nor does it represent that it has 585 made any independent effort to identify any such rights. Information 586 on the procedures with respect to rights in RFC documents can be 587 found in BCP 78 and BCP 79. 589 Copies of IPR disclosures made to the IETF Secretariat and any 590 assurances of licenses to be made available, or the result of an 591 attempt made to obtain a general license or permission for the use of 592 such proprietary rights by implementers or users of this 593 specification can be obtained from the IETF on-line IPR repository at 594 http://www.ietf.org/ipr. 596 The IETF invites any interested party to bring to its attention any 597 copyrights, patents or patent applications, or other proprietary 598 rights that may cover technology that may be required to implement 599 this standard. Please address the information to the IETF at 600 ietf-ipr@ietf.org. 602 Acknowledgment 604 Funding for the RFC Editor function is provided by the IETF 605 Administrative Support Activity (IASA).