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