idnits 2.17.1 draft-ietf-sipping-e2m-sec-reqs-05.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 578. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (December 8, 2004) is 7080 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '3') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. '4') (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2617 (ref. '8') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2630 (ref. '11') (Obsoleted by RFC 3369, RFC 3370) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING K. Ono 2 Internet-Draft S. Tachimoto 3 Expires: June 8, 2005 NTT Corporation 4 December 8, 2004 6 Requirements for End-to-Middle Security for the Session Initiation 7 Protocol (SIP) 8 draft-ietf-sipping-e2m-sec-reqs-05 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 8, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 A SIP User Agent (UA) does not always trust all intermediaries in its 44 request path to inspect its message bodies and/or headers contained 45 in its message. The UA might want to protect the message bodies 46 and/or headers from intermediaries except those that provide services 47 based on its content. This situation requires a mechanism called 48 "end-to-middle security" to secure the information passed between the 49 UA and intermediaries, which does not interfere with end-to-end 50 security. This document defines a set of requirements for a 51 mechanism to achieve end-to-middle security. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC-2119 [1]. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1 Examples of Scenarios . . . . . . . . . . . . . . . . . . . . 3 64 2.2 Service Examples . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Scope of End-to-Middle Security . . . . . . . . . . . . . . . 7 66 4. Requirements for a Solution . . . . . . . . . . . . . . . . . 7 67 4.1 General Requirements . . . . . . . . . . . . . . . . . . . . . 7 68 4.2 Requirements for End-to-Middle Confidentiality . . . . . . . . 8 69 4.3 Requirements for End-to-Middle Integrity . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 73 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9.1 Normative References . . . . . . . . . . . . . . . . . . . . . 11 76 9.2 Informative References . . . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 78 Intellectual Property and Copyright Statements . . . . . . . . 13 80 1. Introduction 82 The Session Initiation Protocol (SIP) [2] supports hop-by-hop 83 security using Transport Layer Security (TLS) [3] and end-to-end 84 security using Secure MIME (S/MIME) [4]. These security mechanisms 85 assume that a SIP UA trusts all proxy servers along its request path 86 to inspect the message bodies contained in the message, or a SIP UA 87 does not trust any proxy servers to do so. 89 However, there is a model where trusted and partially-trusted proxy 90 servers are mixed along a message path. The partially-trusted proxy 91 servers are only trusted to provide SIP routing, but these proxy 92 servers are not trusted by users to inspect its data except routing 93 headers. A hop-by-hop confidentiality service using TLS is not 94 suitable for this model. An end-to-end confidentiality service using 95 S/MIME is also not suitable when the intermediaries provide services 96 based on reading the message bodies and/or headers. This problem is 97 described in Section 23 of [2]. 99 In some cases, a UA might want to protect its message bodies and/or 100 headers from proxy servers along its request path except from those 101 that provide services based on reading its message bodies and/or 102 headers. Conversely, a proxy server might want to view the message 103 bodies and/or headers to sufficiently provide these services. Such 104 proxy servers are not always the first hop from the UA. This 105 situation requires a security mechanism to secure message bodies 106 and/or headers between the UA and the proxy servers, yet disclosing 107 information to those that need it. We call this "end-to-middle 108 security". 110 2. Use Cases 112 2.1 Examples of Scenarios 114 We describe here examples of scenarios in which trusted and 115 partially-trusted proxy servers both exist in a message path. These 116 situations demonstrate the reasons why end-to-middle security is 117 required. 119 In the following example, User #1 does not know the security policies 120 or services provided by Proxy server #1 (Proxy#1). User #1 sends a 121 MESSAGE [5] request including S/MIME-encrypted message content for 122 end-to-end security as shown in Figure 1, while Proxy #1 rejects the 123 request base on its strict security policy that prohibits the 124 forwarding of unknown data. 126 Home network 127 +---------------------+ 128 | +-----+ +-----+ | +-----+ +-----+ 129 User #1-----| | C |-----| * |-----| * |-----| C |-----User #2 130 | +-----+ +-----+ | +-----+ +-----+ 131 | UA #1 Proxy #1 | Proxy #2 UA #2 132 +---------------------+ 134 C: Content that UA #1 allows the entity to inspect 135 *: Content that UA #1 prevents the entity from inspecting 137 Figure 1: Deployment example #1 139 In the second example, Proxy server #1 is the home proxy server of 140 User #1 using UA #1. User #1 communicates with User #2 through Proxy 141 #1 and Proxy #2 as shown in Figure 2. Although User #1 already knows 142 Proxy #1's security policy which requires the inspection of the 143 content of the MESSAGE request, User #1 does not know whether Proxy 144 #2 is trustworthy, and thus wants to protect the message bodies in 145 the request. To accomplish this, UA #1 will need to be able to grant 146 a trusted intermediary (Proxy #1) to inspect message bodies, while 147 preserving their confidentiality from other intermediaries (Proxy 148 #2). 150 Even if UA #1's request message authorizes Proxy #1 to inspect the 151 message bodies, UA #1 is unable to authorize the same proxy server to 152 inspect the message bodies in subsequent MESSAGE requests from UA #2. 154 Home network 155 +---------------------+ 156 | +-----+ +-----+ | +-----+ +-----+ 157 User #1-----| | C |-----| C |-----| * |-----| C |----- User #2 158 | +-----+ +-----+ | +-----+ +-----+ 159 | UA #1 Proxy #1 | Proxy #2 UA #2 160 +---------------------+ 162 C: Content that UA #1 needs to disclose 163 *: Content that UA #1 needs to protect 165 Figure 2: Deployment example #2 167 In the third example, User #1 connects UA #1 to a proxy server in a 168 visited (potentially insecure) network, e.g., a hotspot service or a 169 roaming service. Since User #1 wants to utilize certain home network 170 services, UA #1 connects to a home proxy server, Proxy #1. However, 171 UA #1 must connect to Proxy #1 via the proxy server of the visited 172 network (Proxy A), because User #1 must follow the policy of that 173 network. Proxy A performs access control based on the destination 174 addresses of calls. User #1 only trusts Proxy A to route requests, 175 not to inspect the message bodies the requests contain as shown in 176 Figure 3. User #1 trusts Proxy #1 both to route requests and to 177 inspect the message bodies for some purpose. 179 The same problems as in the second example also exist here. 181 Visited network 182 +---------------------+ 183 | +-----+ +-----+ | +-----+ +-----+ +-----+ 184 User #1 -- | | C |-----| * |-----| C |-----| * |-----| C | 185 | +-----+ +-----+ | +-----+ +-----+ +-----+ 186 | UA #1 Proxy A | Proxy #1 Proxy #2 UA #2 187 +---------------------+ 189 C: Content that UA #1 needs to disclose 190 *: Content that UA #1 needs to protect 192 Figure 3: Deployment example #3 194 2.2 Service Examples 196 We describe here several services that require end-to-middle 197 security. 199 2.2.1 Logging Services for Instant Messages 201 Logging Services are provided by the archiving function, which is 202 located in the proxy server, that logs the message content exchanged 203 between UAs. The archiving function could be located at the 204 originator network and/or the destination network. When the content 205 of an instant message contains private information, UACs (UA Clients) 206 encrypt the content for the UASs (UA Servers). The archiving 207 function needs a way to log the content in a message body in 208 bidirectional MESSAGE requests in such a way that the data is 209 decipherable. The archiving function also needs a way to verify the 210 data integrity of the content before logging. 212 This service might be deployed in financial or health care service 213 provider's networks, where archiving communication is required by 214 their security policies, as well as other networks. 216 2.2.2 Non-emergency Call Routing Based on the Location Object 218 The Location Object [6] includes private information as well as 219 routing information for appropriate proxy servers. Some proxy 220 servers have the capability to provide location-based routing. When 221 UAs want to employ location-based routing in non-emergency 222 situations, the UAs need to connect to the proxy servers with such a 223 capability and disclose the location object contained in the message 224 body of the INVITE request, while protecting it from other proxy 225 servers along the request path. 227 The Location Object also needs to be verified for integrity before 228 location-based routing is applied. Sometimes the UAC want to also 229 send the Location Object to the UASs. This is another good example 230 of the need for a UAC to simultaneously send secure data to a proxy 231 server and to the UAS. 233 2.2.3 User Authentication 235 2.2.3.1 User Authentication using the AIBs 237 The Authenticated Identity Bodies (AIBs) [7] is a digitally-signed 238 data that is used as way to identify users. Proxy servers that need 239 to authenticate a user verify the signature. When the originator 240 needs anonymity, the user identity in the AIB is encrypted before 241 being signed. Proxy servers that authenticate the user need to 242 decrypt the body in order to view the user identity in the AIB. Such 243 proxy servers can be located at adjacent and/or non-adjacent to the 244 UA. 246 The AIB could be included in all request/response messages. The 247 proxy server needs to view it in request messages in order to 248 authenticate users. Another proxy server sometimes needs to view it 249 in response messages for user authentication. 251 2.2.3.2 User Authentication in HTTP Digest Authentication 253 User authentication data for HTTP digest authentication [8] includes 254 potentially private information, such as a user name. The user 255 authentication data can be set only in a SIP header of request 256 messages. This information needs to be transmitted securely to 257 servers that authenticate users, located either adjacently and/or 258 non-adjacently to the UA. 260 2.2.4 Media-related Services 262 Firewall traversal is an example of services based on media 263 information in a message body, such as the Session Description 264 Protocol (SDP). A firewall entity that supports the SIP protocol, or 265 a midcom [9] agent co-located with a proxy server, controls a 266 firewall based on the address and port information of media streams 267 in the SDP offer/answer. The address and port information in the SDP 268 needs to be transmitted securely to recipient UAs and the proxy 269 server operating as a midcom agent. Therefore, there is a need for 270 proxy server to be able to decrypt the SDP, as well as to verify the 271 integrity of the SDP. 273 When the SDPs include key parameters for Secure RTP (SRTP) [10], the 274 key parameters need to be encrypted only for end-to-end 275 confidentiality. 277 3. Scope of End-to-Middle Security 279 End-to-middle security consists of user authentication, data 280 integrity, and data confidentiality. However, this document only 281 describes requirements for data confidentiality and data integrity, 282 since end-to-middle authentication is covered by existing mechanisms 283 such as HTTP digest authentication, S/MIME Cryptographic Message 284 Syntax (CMS) SignedData body [11], or an AIB. 286 As for data integrity, the CMS SignedData body can be used for 287 verification of the data integrity by any entities. The CMS 288 SignedData body could be used for end-to-middle security at the same 289 time for end-to-end security. 291 Although a proxy server is able to verify the integrity of the data, 292 there is no way for UAs to request a selected proxy server to verify 293 a message with the CMS SignedData body. Therefore some new 294 mechanisms are needed to achieve data integrity for end-to-middle 295 security. 297 This document mainly discusses requirements for data confidentiality 298 and the integrity of end-to-middle security. 300 4. Requirements for a Solution 302 We describe here requirements for a solution. The requirements are 303 mainly applied during the phase of a dialog creation or sending a 304 MESSAGE method. 306 4.1 General Requirements 308 The following are general requirements for end-to-middle 309 confidentiality and integrity. 311 REQ-GEN-1: The solution SHOULD have little impact on the way a UA 312 handles S/MIME-secured messages. 314 REQ-GEN-2: It SHOULD have no impact on proxy servers that do not 315 provide services based on S/MIME bodies in terms of 316 handling the existing SIP headers. 318 REQ-GEN-3: It SHOULD NOT violate the standardized mechanism of proxy 319 servers in terms of handling message bodies. 321 REQ-GEN-4: It SHOULD allow a UA to discover security policies of 322 proxy servers. Security policies imply what data is 323 needed to disclose and/or verify in a message. 325 This requirement is necessary when the UA does not know 326 statically which proxy servers or domains need 327 disclosing data and/or verification. 329 4.2 Requirements for End-to-Middle Confidentiality 331 REQ-CONF-1: The solution MUST allow encrypted data to be shared with 332 the recipient UA and selected proxy servers, when a UA 333 wants. 335 REQ-CONF-2: It MUST NOT violate end-to-end encryption when the 336 encrypted data does not need to be shared with any proxy 337 servers. 339 REQ-CONF-3: It SHOULD allow a UA to request selected proxy servers to 340 view specific message bodies. The request itself SHOULD 341 be secure. 343 REQ-CONF-4: It MAY allow a UA to request that the recipient UA 344 disclose information to the proxy server, to which the 345 requesting UA is initially disclosing information. The 346 request itself SHOULD be secure. 348 This requirement is not necessary when a provider that 349 operates the proxy server does not permit revealing 350 the security policies to a different provider that the 351 recipient UA belongs to. 353 4.3 Requirements for End-to-Middle Integrity 355 REQ-INT-1: The solution SHOULD work even when the SIP end-to-end 356 integrity service is enabled. 358 REQ-INT-2: It SHOULD allow a UA to request selected proxy servers to 359 verify specific message bodies. The request itself SHOULD 360 be secure. 362 REQ-INT-3: It SHOULD allow a UA to request the recipient UA to send 363 the verification data of the same information that the 364 requesting UA is providing to the proxy server. The 365 request itself SHOULD be secure. 367 This requirement is not necessary when a provider that 368 operates the proxy server does not permit to reveal the 369 security policies to a different provider that the 370 recipient UA belongs to. 372 5. Security Considerations 374 This document describes the requirements for confidentiality and 375 integrity between a UA and a proxy server. Although this document 376 does not cover authentication, it is important in order to prevent 377 attacks from malicious users and servers. 379 The end-to-middle security requires additional processing on message 380 bodies, such as unpacking MIME structure, data decryption, and/or 381 signature verification to proxy servers. Therefore the proxy servers 382 that enable end-to-middle security are vulnerable to a 383 Denial-of-Services attack. There is a threat model where a malicious 384 user sends many complicated-MIME-structure messages to a proxy 385 server, containing user authentication data obtained by 386 eavesdropping. This attack will result in a slow down of the overall 387 performance of these proxy servers. To prevent this attack, user 388 authentication mechanism needs protection against replay attack. Or 389 the user authentication always needs to be executed simultaneously 390 with protection of data integrity. In order to prevent an attack, 391 the following requirements should be satisfied. 393 o The solution MUST support mutual authentication, data 394 confidentiality and data integrity protection between a UA and a 395 proxy server. 397 o It SHOULD support protection against a replay attack for user 398 authentication. 400 o It SHOULD simultaneously support user authentication and data 401 integrity protection. 403 These last two requirements are met by HTTP Digest 404 authentication. 406 6. IANA Considerations 408 This document requires no additional considerations. 410 7. Acknowledgments 412 Thanks to Rohan Mahy and Cullen Jennings for their initial support of 413 this concept, and to Jon Peterson, Gonzalo Camarillo, Sean Olson, 414 Mark Baugher and Mary Barnes for their helpful comments. 416 8. Changes 418 [Note to RFC editor. Please remove this entire section when this 419 draft is published as an RFC.] 421 o Changes from 04.txt 423 * Updated references. 424 * Fixed editorial errors. 426 o Changes from 03.txt 428 * Removed some of the text that described an illegal behavior of 429 a proxy server and the scope of session policies in the 430 "Examples of Scenarios" section. 431 * Added notes to describe the requirements met by session 432 policies in the "Requirements for a Solution" section. 433 * Added a note to describe the requirements met by an existing 434 mechanism. 435 * Changed the last requirements of end-to-middle confidentiality 436 and integrity from "SHOULD" to "MAY", and added the conditions 437 of the requirements. 438 * Categorized references to normative and informative ones. 440 o Changes from 02.txt 442 * Changed the text about the use case of SDP-based service in 443 order to decrease the dependency on session policies 444 discussion. The title was changed to "media-related service". 445 * Simplified the "Scope of End-to-Middle Security" section. 446 * Removed some of the text that described detailed information on 447 mechanisms in the "Requirements for a Solution" section. 448 * Closed open issues as follows: 449 + Deleted an open issue described in the "General 450 Requirements" section, since it is no longer an issue. The 451 issue was concerning the necessity for the proxy server to 452 notify the UAS after receiving a response, which is not 453 necessary, because proxy servers' security policies or 454 services have no dependencies on the information in a 455 response. 456 + Deleted an open issue described in the "Requirements for 457 End-to-Middle Confidentiality" section, since it is not an 458 issue of requirements, but that of a mechanism. 459 * Changed the last item of the general requirements from 460 proxy-driven to UA-driven. 461 * Deleted the text in the requirements that describes the 462 relation between the requirements and the service examples. 463 * Added some text in the "Security Consideration" section. 464 * Many editorial correction. 466 o "Changes from 01.txt" 468 * Extracted use cases from the Introduction section, and created 469 a new section to describe the use cases in more detail. The 470 use cases are also updated. 471 * Deleted a few "may" words from the "Problem with Existing 472 Situations" section to avoid confusion with "MAY" as a key 473 word. 474 * Added the relation between the requirements and the service 475 examples. 476 * Deleted the redundant requirements for discovery of the 477 targeted-middle. The requirement is described only in the 478 "Generic Requirements", not in the "Requirements for 479 End-to-Middle Confidentiality/Integrity". 480 * Changed the 4th requirement of end-to-middle confidentiality 481 from "MUST" to "SHOULD". 482 * Changed the 3rd requirement of end-to-middle integrity from 483 "MUST" to "SHOULD". 484 * Added some text about DoS attack prevention in the "Security 485 Consideration" section. 487 o "Changes from 00.txt" 489 * Reworked the subsections in Section 4 to clarify the 490 objectives, separating end-to-middle confidentiality and 491 integrity. 493 9. References 495 9.1 Normative References 497 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 498 Levels", RFC 2119, BCP 14, March 1997. 500 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 501 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 502 Session Initiation Protocol", RFC 3261, June 2002. 504 9.2 Informative References 506 [3] Allen, C. and T. Dierks, "The TLS Protocol Version 1.0", RFC 507 2246, January 1999. 509 [4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 510 2633, June 1992. 512 [5] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 513 D. Gurle, "Session Initiation Protocol (SIP) Extension for 514 Instant Messaging", RFC 3428, December 2002. 516 [6] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. 517 Polk, "Geopriv Requirements", RFC 3693, February 2004. 519 [7] Peterson, J., "Session Initiation Protocol (SIP) Authenticated 520 Identity Body (AIB) Format", RFC 3893, September 2004. 522 [8] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 523 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 524 Basic and Digest Access Authentication", RFC 2617, June 1999. 526 [9] Srisuresh, P., Kuthan, J., Rosenberg, J., Brim, S., Molitor, A. 527 and A. Rayhan, "Middlebox communication architecture and 528 framework", RFC 3303, August 2002. 530 [10] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. 531 Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 532 3711, March 2004. 534 [11] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 535 1999. 537 Authors' Addresses 539 Kumiko Ono 540 Network Service Systems Laboratories 541 NTT Corporation 542 9-11, Midori-Cho 3-Chome 543 Musashino-shi, Tokyo 180-8585 544 Japan 546 EMail: ono.kumiko@lab.ntt.co.jp 547 Shinya Tachimoto 548 Network Service Systems Laboratories 549 NTT Corporation 550 9-11, Midori-Cho 3-Chome 551 Musashino-shi, Tokyo 180-8585 552 Japan 554 EMail: tachimoto.shinya@lab.ntt.co.jp 556 Intellectual Property Statement 558 The IETF takes no position regarding the validity or scope of any 559 Intellectual Property Rights or other rights that might be claimed to 560 pertain to the implementation or use of the technology described in 561 this document or the extent to which any license under such rights 562 might or might not be available; nor does it represent that it has 563 made any independent effort to identify any such rights. Information 564 on the procedures with respect to rights in RFC documents can be 565 found in BCP 78 and BCP 79. 567 Copies of IPR disclosures made to the IETF Secretariat and any 568 assurances of licenses to be made available, or the result of an 569 attempt made to obtain a general license or permission for the use of 570 such proprietary rights by implementers or users of this 571 specification can be obtained from the IETF on-line IPR repository at 572 http://www.ietf.org/ipr. 574 The IETF invites any interested party to bring to its attention any 575 copyrights, patents or patent applications, or other proprietary 576 rights that may cover technology that may be required to implement 577 this standard. Please address the information to the IETF at 578 ietf-ipr@ietf.org. 580 Disclaimer of Validity 582 This document and the information contained herein are provided on an 583 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 584 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 585 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 586 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 587 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 588 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 590 Copyright Statement 592 Copyright (C) The Internet Society (2004). This document is subject 593 to the rights, licenses and restrictions contained in BCP 78, and 594 except as set forth therein, the authors retain all their rights. 596 Acknowledgment 598 Funding for the RFC Editor function is currently provided by the 599 Internet Society.