idnits 2.17.1 draft-ietf-sipping-e2m-sec-reqs-06.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 621. ** 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 (March 14, 2005) is 6980 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) -- Looks like a reference, but probably isn't: 'C' on line 191 -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '3') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 3850 (ref. '4') (Obsoleted by RFC 5750) -- 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 2327 (ref. '9') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 3852 (ref. '12') (Obsoleted by RFC 5652) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING K. Ono 3 Internet-Draft S. Tachimoto 4 Expires: September 15, 2005 NTT Corporation 5 March 14, 2005 7 Requirements for End-to-Middle Security for the Session Initiation 8 Protocol (SIP) 9 draft-ietf-sipping-e2m-sec-reqs-06 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 15, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 A SIP User Agent (UA) does not always trust all intermediaries in its 45 request path to inspect its message bodies and/or headers contained 46 in its message. The UA might want to protect the message bodies 47 and/or headers from intermediaries except those that provide services 48 based on its content. This situation requires a mechanism called 49 "end-to-middle security" to secure the information passed between the 50 UA and intermediaries, which does not interfere with end-to-end 51 security. This document defines a set of requirements for a 52 mechanism to achieve end-to-middle security. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC-2119 [1]. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1 Examples of Scenarios . . . . . . . . . . . . . . . . . . 3 65 2.2 Service Examples . . . . . . . . . . . . . . . . . . . . . 5 66 3. Scope of End-to-Middle Security . . . . . . . . . . . . . . . 7 67 4. Requirements for a Solution . . . . . . . . . . . . . . . . . 7 68 4.1 General Requirements . . . . . . . . . . . . . . . . . . . 7 69 4.2 Requirements for End-to-Middle Confidentiality . . . . . . 8 70 4.3 Requirements for End-to-Middle Integrity . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 74 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 9.1 Normative References . . . . . . . . . . . . . . . . . . . 12 77 9.2 Informative References . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 79 Intellectual Property and Copyright Statements . . . . . . . . 14 81 1. Introduction 83 The Session Initiation Protocol (SIP) [2] supports hop-by-hop 84 security using Transport Layer Security (TLS) [3] and end-to-end 85 security using Secure MIME (S/MIME) [4]. These security mechanisms 86 assume that a SIP UA trusts all proxy servers along its request path 87 to inspect the message bodies contained in the message, or a SIP UA 88 does not trust any proxy servers to do so. 90 However, there is a model where trusted and partially-trusted proxy 91 servers are mixed along a message path. The partially-trusted proxy 92 servers are only trusted to provide SIP routing, but these proxy 93 servers are not trusted by users to inspect its data except routing 94 headers. A hop-by-hop confidentiality service using TLS is not 95 suitable for this model. An end-to-end confidentiality service using 96 S/MIME is also not suitable when the intermediaries provide services 97 based on reading the message bodies and/or headers. This problem is 98 described in Section 23 of [2]. 100 In some cases, a UA might want to protect its message bodies and/or 101 headers from proxy servers along its request path except from those 102 that provide services based on reading its message bodies and/or 103 headers. Conversely, a proxy server might want to view the message 104 bodies and/or headers to sufficiently provide these services. Such 105 proxy servers are not always the first hop from the UA. This 106 situation requires a security mechanism to secure message bodies 107 and/or headers between the UA and the proxy servers, yet disclosing 108 information to those that need it. We call this "end-to-middle 109 security". 111 2. Use Cases 113 2.1 Examples of Scenarios 115 We describe here examples of scenarios in which trusted and 116 partially-trusted proxy servers both exist in a message path. These 117 situations demonstrate the reasons why end-to-middle security is 118 required. 120 In the following example, User #1 does not know the security policies 121 or services provided by Proxy server #1 (Proxy#1). User #1 sends a 122 MESSAGE [5] request including S/MIME-encrypted message content for 123 end-to-end security as shown in Figure 1, while Proxy #1 rejects the 124 request based on its strict security policy that prohibits the 125 forwarding of unknown data. 127 Home network 128 +---------------------+ 129 | +-----+ +-----+ | +-----+ +-----+ 130 User #1-----| | C |-----| [C] |-----| [C] |-----| C |-----User #2 131 | +-----+ +-----+ | +-----+ +-----+ 132 | UA #1 Proxy #1 | Proxy #2 UA #2 133 +---------------------+ 135 C: Content that UA #1 allows the entity to inspect 136 [C]: Content that UA #1 prevents the entity from inspecting 138 Figure 1: Deployment example #1 140 In the second example, Proxy server #1 is the home proxy server of 141 User #1 using UA #1. User #1 communicates with User #2 through Proxy 142 #1 and Proxy #2 as shown in Figure 2. Although User #1 already knows 143 Proxy #1's security policy which requires the inspection of the 144 content of the MESSAGE request, User #1 does not know whether Proxy 145 #2 is trustworthy, and thus wants to protect the message bodies in 146 the request. To accomplish this, UA #1 will need to be able to grant 147 a trusted intermediary (Proxy #1) to inspect message bodies, while 148 preserving their confidentiality from other intermediaries (Proxy 149 #2). 151 Even if UA #1's request message authorizes Proxy #1 to inspect the 152 message bodies, UA #1 is unable to authorize the same proxy server to 153 inspect the message bodies in subsequent MESSAGE requests from UA #2. 155 Home network 156 +---------------------+ 157 | +-----+ +-----+ | +-----+ +-----+ 158 User #1-----| | C |-----| C |-----| [C] |-----| C |----- User #2 159 | +-----+ +-----+ | +-----+ +-----+ 160 | UA #1 Proxy #1 | Proxy #2 UA #2 161 +---------------------+ 163 C: Content that UA #1 needs to disclose 164 [C]: Content that UA #1 needs to protect 166 Figure 2: Deployment example #2 168 In the third example, User #1 connects UA #1 to a proxy server in a 169 visited (potentially insecure) network, e.g., a hotspot service or a 170 roaming service. Since User #1 wants to utilize certain home network 171 services, UA #1 connects to a home proxy server, Proxy #1. However, 172 UA #1 must connect to Proxy #1 via the proxy server of the visited 173 network (Proxy A), because User #1 must follow the policy of that 174 network. Proxy A performs access control based on the destination 175 addresses of calls. User #1 only trusts Proxy A to route requests, 176 not to inspect the message bodies the requests contain as shown in 177 Figure 3. User #1 trusts Proxy #1 both to route the requests and to 178 inspect the message bodies. 180 The same problems as in the second example also exist here. 182 Visited network 183 +---------------------+ 184 | +-----+ +-----+ | +-----+ +-----+ +-----+ 185 User #1 -- | | C |-----| [C] |-----| C |-----| [C] |-----| C | 186 | +-----+ +-----+ | +-----+ +-----+ +-----+ 187 | UA #1 Proxy A | Proxy #1 Proxy #2 UA #2 188 +---------------------+ 190 C: Content that UA #1 needs to disclose 191 [C]: Content that UA #1 needs to protect 193 Figure 3: Deployment example #3 195 2.2 Service Examples 197 We describe here several services that require end-to-middle 198 security. 200 2.2.1 Logging Services for Instant Messages 202 Logging Services are provided by the archiving function, which is 203 located in the proxy server, that logs the message content exchanged 204 between UAs. The archiving function could be located at the 205 originator network and/or the destination network. When the content 206 of an instant message contains private information, UACs (UA Clients) 207 encrypt the content for the UASs (UA Servers). The archiving 208 function needs a way to log the content in a message body in 209 bidirectional MESSAGE requests in such a way that the data is 210 decipherable. The archiving function also needs a way to verify the 211 data integrity of the content before logging. 213 This service might be deployed in financial networks, health care 214 service provider's networks, as well as other networks where 215 archiving communication is required by their security policies. 217 2.2.2 Non-emergency Call Routing Based on the Location Object 219 The Location Object [6] includes a person's geographical location 220 information that is privacy-sensitive. Some proxy servers will have 221 the capability to provide routing based on the geographical location 222 information. When UAs want to employ location-based routing in 223 non-emergency situations, the UAs need to connect to the proxy 224 servers with such a capability and disclose the geographical location 225 information contained in the message body of the INVITE request, 226 while protecting it from other proxy servers along the request path. 227 The Location Object also needs to be verified for data integrity by 228 the proxy servers before location-based routing is applied. 229 Sometimes the UACs want to send the Location Object to the UASs. 230 This is another good example presenting the need for UACs to 231 simultaneously send secure data to a proxy server and to the UASs. 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 for identifying users. Proxy servers that need to 239 authenticate a user verify the signature. When the originator needs 240 anonymity, the user identity in the AIB is encrypted before being 241 signed. Proxy servers that authenticate the user need to decrypt the 242 body in order to view the user identity in the AIB. Such proxy 243 servers can be located at adjacent and/or non-adjacent to the UA. 245 The AIB could be included in all request/response messages. The 246 proxy server needs to view it in request messages in order to 247 authenticate users. Another proxy server sometimes needs to view it 248 in response messages for user authentication. 250 2.2.3.2 User Authentication in HTTP Digest Authentication 252 User authentication data for HTTP Digest authentication [8] includes 253 potentially private information, such as a user name. The user 254 authentication data can be set only in a SIP header of request 255 messages. This information needs to be transmitted securely to 256 servers that authenticate users, located either adjacently and/or 257 non-adjacently to the UA. 259 2.2.4 Media-related Services 261 Firewall traversal is an example of services based on media 262 information in a message body, such as the Session Description 263 Protocol (SDP) [9]. A firewall entity that supports the SIP 264 protocol, or a midcom [10] agent co-located with a proxy server, 265 controls a firewall based on the address and port information of 266 media streams in the SDP offer/answer. The address and port 267 information in the SDP needs to be transmitted securely to recipient 268 UAs and the proxy server operating as a midcom agent. Therefore, 269 there is a need for a proxy server to be able to decrypt the SDP, as 270 well as to verify the integrity of the SDP. 272 When the SDP includes key parameters for Secure RTP (SRTP) [11], the 273 key parameters need to be encrypted only for end-to-end 274 confidentiality. 276 3. Scope of End-to-Middle Security 278 End-to-middle security consists of user authentication, data 279 integrity, and data confidentiality. Providing data integrity 280 requires authenticating peer who creates the data. However, this 281 document only describes requirements for data confidentiality and 282 data integrity, since end-to-middle authentication is covered by 283 existing mechanisms such as HTTP Digest authentication, S/MIME 284 Cryptographic Message Syntax (CMS) SignedData body [12], or an AIB. 286 As for data integrity, the CMS SignedData body can be used for 287 verification of the data integrity and authentication of the signer 288 by any entities. The CMS SignedData body can be used for 289 end-to-middle security and end-to-end security simultaneously. 290 However, a proxy server generally don't verify the data integrity 291 using the CMS SignedData body, and there is no way for a UA to 292 request the proxy server to verify the message. Therefore some new 293 mechanisms are needed to achieve data integrity for end-to-middle 294 security. 296 This document mainly discusses requirements for data confidentiality 297 and the integrity of end-to-middle security. 299 4. Requirements for a Solution 301 We describe here requirements for a solution. The requirements are 302 mainly applied during the phase of a dialog creation or sending a 303 MESSAGE request. 305 4.1 General Requirements 307 The following are general requirements for end-to-middle 308 confidentiality and integrity. 310 REQ-GEN-1: The solution SHOULD have little impact on the way a UA 311 handles S/MIME-secured messages. 313 REQ-GEN-2: It SHOULD NOT have an impact on proxy servers that do not 314 provide services based on S/MIME-secured bodies in terms 315 of handling the existing SIP headers. 317 REQ-GEN-3: It SHOULD NOT violate the standardized mechanism of proxy 318 servers in terms of handling message bodies. 320 REQ-GEN-4: It SHOULD allow a UA to discover security policies of 321 proxy servers. Security policies imply what data is 322 needed to disclose and/or verify in a message. 324 This requirement is necessary when the UA does not know 325 statically which proxy servers or domains need 326 disclosing data and/or verification. 328 4.2 Requirements for End-to-Middle Confidentiality 330 REQ-CONF-1: The solution MUST allow encrypted data to be shared with 331 the recipient UA and a proxy server, when a UA wants. 333 REQ-CONF-2: It MUST NOT violate end-to-end encryption when the 334 encrypted data does not need to be shared with any proxy 335 servers. 337 REQ-CONF-3: It SHOULD allow a UA to request a proxy server to view 338 specific message bodies. The request itself SHOULD be 339 secure, namely be authenticated for the UA and be 340 verified for the data integrity. 342 REQ-CONF-4: It MAY allow a UA to request that the recipient UA 343 disclose information to the proxy server, to which the 344 requesting UA is initially disclosing information. The 345 request itself SHOULD be secure, namely be authenticated 346 for the UA and be verified for the data integrity. 348 This requirement is necessary when a provider 349 operating the proxy server allows its security 350 policies to be revealed to the provider serving the 351 recipient UA. 353 4.3 Requirements for End-to-Middle Integrity 355 This section enumerates the requirements for the end-to-middle 356 integrity. Verifying the data integrity requires seeing if the data 357 is created by the authenticated user, not forged by a malicious user. 358 Therefore verification of the data integrity requires the user 359 authentication. 361 REQ-INT-1: The solution SHOULD work even when the SIP end-to-end 362 authentication and integrity services are enabled. 364 REQ-INT-2: It SHOULD allow a UA to request a proxy server to verify 365 specific message bodies and authenticate the user. The 366 request itself SHOULD be secure, namely be authenticated 367 for the UA and be verified for the data integrity. 369 REQ-INT-3: It SHOULD allow a UA to request the recipient UA to send 370 the verification data of the same information that the 371 requesting UA is providing to the proxy server. The 372 request itself SHOULD be secure, namely authenticated for 373 the UA and be verified for the data integrity. 375 This requirement is necessary when a provider operating 376 the proxy server allows its security policies to be 377 revealed to the provider serving the recipient UA. 379 5. Security Considerations 381 This document describes the requirements for confidentiality and 382 integrity between a UA and a proxy server. Although this document 383 does not cover any requirements for authentication, verifying the 384 data integrity requires peer authentication. Also, peer 385 authentication is important in order to prevent attacks from 386 malicious users and servers. 388 The end-to-middle security requires additional processing on message 389 bodies, such as unpacking MIME structure, data decryption, and/or 390 signature verification to proxy servers. Therefore the proxy servers 391 that enable end-to-middle security are vulnerable to a 392 Denial-of-Services attack. A threat model is where a malicious user 393 sends many complicated-MIME-structure messages to a proxy server, 394 containing user authentication data obtained by eavesdropping. 395 Another threat model is where a malicious proxy server sends many 396 complicated-MIME-structure messages to a proxy server, containing the 397 source IP address and the Via header of an adjacent proxy server. 398 These attacks will slow down the overall performance of target proxy 399 servers. 401 To prevent these attacks, user and server authentication mechanism 402 needs to be protected against replay attack. Or the user and server 403 authentication always needs to be executed simultaneously with 404 protection of data integrity. In order to prevent these attacks, the 405 following requirements should be met. 407 o The solution MUST support mutual authentication, data 408 confidentiality and data integrity protection between a UA and a 409 proxy server. 411 o It SHOULD support protection against a replay attack for user 412 authentication. 414 o It SHOULD simultaneously support user authentication and data 415 integrity protection. 417 These last two requirements are met by HTTP Digest 418 authentication. 420 o It MUST support mutual authentication, data confidentiality and 421 data integrity protection between proxy servers. 423 o It SHOULD support protection against a replay attack for server 424 authentication. 426 o It SHOULD simultaneously support server authentication and data 427 integrity protection. 429 These last three requirements are met by TLS. 431 6. IANA Considerations 433 This document requires no additional considerations. 435 7. Acknowledgments 437 The authors would like to thank to Rohan Mahy and Cullen Jennings for 438 their initial support of this concept, and to Jon Peterson, Gonzalo 439 Camarillo, Sean Olson, Mark Baugher and Mary Barnes and others for 440 their reviews and constructive comments. 442 8. Changes 444 [Note to RFC editor. Please remove this entire section when this 445 draft is published as an RFC.] 447 o Changes from 05.txt 449 * Updated Ascii art in Section 2.1. 450 * Aligned terminology with the reference[6] to Section 2.2.2. 451 * Added more text to Section 3, for note that data integrity is 452 not provided without peer authentication. 453 * Added more text to Section 4.3. 454 * Added a threat model by a malicious server to the "Security 455 Consideration" section. 456 * Updated references. 457 * More editorial changes. 459 o Changes from 04.txt 461 * Updated references. 462 * Fixed editorial errors. 464 o Changes from 03.txt 466 * Removed some of the text that described an illegal behavior of 467 a proxy server and the scope of session policies in the 468 "Examples of Scenarios" section. 469 * Added notes to describe the requirements met by session 470 policies in the "Requirements for a Solution" section. 471 * Added a note to describe the requirements met by an existing 472 mechanism. 473 * Changed the last requirements of end-to-middle confidentiality 474 and integrity from "SHOULD" to "MAY", and added the conditions 475 of the requirements. 476 * Categorized references to normative and informative ones. 478 o Changes from 02.txt 480 * Changed the text about the use case of SDP-based service in 481 order to decrease the dependency on session policies 482 discussion. The title was changed to "media-related service". 483 * Simplified the "Scope of End-to-Middle Security" section. 484 * Removed some of the text that described detailed information on 485 mechanisms in the "Requirements for a Solution" section. 486 * Closed open issues as follows: 487 + Deleted an open issue described in the "General 488 Requirements" section, since it is no longer an issue. The 489 issue was concerning the necessity for the proxy server to 490 notify the UAS after receiving a response, which is not 491 necessary, because proxy servers' security policies or 492 services have no dependencies on the information in a 493 response. 494 + Deleted an open issue described in the "Requirements for 495 End-to-Middle Confidentiality" section, since it is not an 496 issue of requirements, but that of a mechanism. 497 * Changed the last item of the general requirements from 498 proxy-driven to UA-driven. 499 * Deleted the text in the requirements that describes the 500 relation between the requirements and the service examples. 501 * Added some text in the "Security Consideration" section. 502 * Many editorial correction. 504 o "Changes from 01.txt" 505 * Extracted use cases from the Introduction section, and created 506 a new section to describe the use cases in more detail. The 507 use cases are also updated. 508 * Deleted a few "may" words from the "Problem with Existing 509 Situations" section to avoid confusion with "MAY" as a key 510 word. 511 * Added the relation between the requirements and the service 512 examples. 513 * Deleted the redundant requirements for discovery of the 514 targeted-middle. The requirement is described only in the 515 "Generic Requirements", not in the "Requirements for 516 End-to-Middle Confidentiality/Integrity". 517 * Changed the 4th requirement of end-to-middle confidentiality 518 from "MUST" to "SHOULD". 519 * Changed the 3rd requirement of end-to-middle integrity from 520 "MUST" to "SHOULD". 521 * Added some text about DoS attack prevention in the "Security 522 Consideration" section. 524 o "Changes from 00.txt" 526 * Reworked the subsections in Section 4 to clarify the 527 objectives, separating end-to-middle confidentiality and 528 integrity. 530 9. References 532 9.1 Normative References 534 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 535 Levels", RFC 2119, BCP 14, March 1997. 537 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 538 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 539 Session Initiation Protocol", RFC 3261, June 2002. 541 9.2 Informative References 543 [3] Allen, C. and T. Dierks, "The TLS Protocol Version 1.0", 544 RFC 2246, January 1999. 546 [4] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 547 (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 548 2004. 550 [5] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 551 D. Gurle, "Session Initiation Protocol (SIP) Extension for 552 Instant Messaging", RFC 3428, December 2002. 554 [6] Peterson, J., "A Presence-based GEOPRIV Location Object 555 Format", Internet-Draft draft-ietf-geopriv-pidf-lo-03, 556 September 2004. 558 [7] Peterson, J., "Session Initiation Protocol (SIP) Authenticated 559 Identity Body (AIB) Format", RFC 3893, September 2004. 561 [8] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 562 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 563 Basic and Digest Access Authentication", RFC 2617, June 1999. 565 [9] Handley, M. and V. Jacobson, "SDP: Session Description 566 Protocol", RFC 2327, April 1998. 568 [10] Srisuresh, P., Kuthan, J., Rosenberg, J., Brim, S., Molitor, A. 569 and A. Rayhan, "Middlebox communication architecture and 570 framework", RFC 3303, August 2002. 572 [11] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. 573 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 574 RFC 3711, March 2004. 576 [12] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, 577 July 2004. 579 Authors' Addresses 581 Kumiko Ono 582 Network Service Systems Laboratories 583 NTT Corporation 584 9-11, Midori-Cho 3-Chome 585 Musashino-shi, Tokyo 180-8585 586 Japan 588 Email: ono.kumiko@lab.ntt.co.jp 590 Shinya Tachimoto 591 Network Service Systems Laboratories 592 NTT Corporation 593 9-11, Midori-Cho 3-Chome 594 Musashino-shi, Tokyo 180-8585 595 Japan 597 Email: tachimoto.shinya@lab.ntt.co.jp 599 Intellectual Property Statement 601 The IETF takes no position regarding the validity or scope of any 602 Intellectual Property Rights or other rights that might be claimed to 603 pertain to the implementation or use of the technology described in 604 this document or the extent to which any license under such rights 605 might or might not be available; nor does it represent that it has 606 made any independent effort to identify any such rights. Information 607 on the procedures with respect to rights in RFC documents can be 608 found in BCP 78 and BCP 79. 610 Copies of IPR disclosures made to the IETF Secretariat and any 611 assurances of licenses to be made available, or the result of an 612 attempt made to obtain a general license or permission for the use of 613 such proprietary rights by implementers or users of this 614 specification can be obtained from the IETF on-line IPR repository at 615 http://www.ietf.org/ipr. 617 The IETF invites any interested party to bring to its attention any 618 copyrights, patents or patent applications, or other proprietary 619 rights that may cover technology that may be required to implement 620 this standard. Please address the information to the IETF at 621 ietf-ipr@ietf.org. 623 Disclaimer of Validity 625 This document and the information contained herein are provided on an 626 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 627 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 628 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 629 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 630 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 631 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 633 Copyright Statement 635 Copyright (C) The Internet Society (2005). This document is subject 636 to the rights, licenses and restrictions contained in BCP 78, and 637 except as set forth therein, the authors retain all their rights. 639 Acknowledgment 641 Funding for the RFC Editor function is currently provided by the 642 Internet Society.