idnits 2.17.1 draft-ietf-sipping-e2m-sec-reqs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ietf-sipping-end2middle-security-reqs-00', but the file name used is 'draft-ietf-sipping-e2m-sec-reqs-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 20, 2003) is 7492 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) == Unused Reference: '10' is defined on line 347, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 352, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 355, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 358, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2633 (ref. '4') (Obsoleted by RFC 3851) ** Downref: Normative reference to an Informational RFC: RFC 3303 (ref. '5') -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2630 (ref. '8') (Obsoleted by RFC 3369, RFC 3370) == Outdated reference: A later version (-04) exists of draft-ono-sipping-end2middle-security-00 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-02) exists of draft-ietf-sipping-session-policy-req-00 -- Possible downref: Normative reference to a draft: ref. '10' ** Obsolete normative reference: RFC 2234 (ref. '13') (Obsoleted by RFC 4234) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 4 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: April 19, 2004 NTT Corporation 5 October 20, 2003 7 Requirements for End-to-middle Security for the Session Initiation 8 Protocol (SIP) 9 draft-ietf-sipping-end2middle-security-reqs-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 19, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 A SIP UA does not always trust all proxy servers in a request path to 40 decide whether to inspect the message bodies and/or headers contained 41 in a message. The UA might want to protect the message bodies and/or 42 headers from proxy servers excluding the particular proxy that 43 provides some features based on reading them. This situation 44 requires a mechanism for securing information passed between the UA 45 and an intermediary proxy, also called "end-to-middle security", 46 which can work with end-to-end security. This document defines a set 47 of requirements for a mechanism to achieve end-to-middle security. 49 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC-2119 [1]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Problems with the Existing Situations . . . . . . . . . . . . 5 58 3. Requirements for a Solution . . . . . . . . . . . . . . . . . 7 59 3.1 Requirements from UA's Perspective . . . . . . . . . . . . . . 7 60 3.2 Requirements from Proxy's Perspective . . . . . . . . . . . . 8 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 64 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 66 Intellectual Property and Copyright Statements . . . . . . . . 14 68 1. Introduction 70 The Session Initiation Protocol (SIP) [2] supports hop-by-hop 71 security using TLS [3] and end-to-end security using S/MIME [4]. 72 This assumes that a SIP UA trusts all proxy servers in a request path 73 to decide whether or not to inspect the message bodies contained in a 74 message. 76 However, there is a model where trusted and partially-trusted proxy 77 servers are mixed along a message path. The partially-trusted proxy 78 servers are only trusted in terms of the SIP routing. Hop-by-hop 79 confidentiality services using TLS are not suitable for this model. 80 End-to-end confidentiality services using S/MIME are also not 81 suitable when the intermediaries provide features based on reading 82 the message bodies and/or headers. This problem is described in 83 Section 23 of [2]. 85 One example of such features is firewall traversal. A firewall 86 entity that supports SIP protocol or a midcom [5] agent co-located 87 with a proxy server controls a firewall based on certain SDP 88 attributes in a SIP transaction. 90 Another example is transcoding [6]. A transcoder related to a SIP 91 proxy transfers coding based on certain SDP attributes in a SIP 92 transaction or transfers text-to-speech based on a message body in 93 the MESSAGE [7] method. 95 A third example is the archiving of instant messaging traffic, where 96 the archiving function co-located with a proxy server logs the 97 message bodies in the MESSAGE method. This feature is deployed for 98 financial or health care applications. 100 In these cases, a UA might want to protect the message bodies and/or 101 headers from proxy servers excluding the particular proxy that 102 provides these features. Conversely, a proxy might want to view the 103 message bodies and/or headers to provide these features. Such a proxy 104 is not always the first hop for the UA. These situations require 105 security between the UA and the intermediary proxy for the message 106 bodies and/or message headers. We call this "end-to-middle security". 108 End-to-middle security consists of authentication, message integrity, 109 and message confidentiality. As for authentication, HTTP digest 110 authentication described in [2] is used for user-to-proxy and 111 proxy-to-user authentication. The authenticating proxy is not limited 112 to the first hop for the UA. Thus, HTTP digest authentication can be 113 used for end-to-middle security. Digital signatures in a Public Key 114 Infrastructure, that is S/MIME CMS [8] SignedData body with 115 certificate, can also be used for authentication. As for message 116 integrity, S/MIME CMS SignedData body can be used. S/MIME CMS 117 SignedData body is created with the original data and the 118 originator's private key, and anyone can verify the integrity using 119 the originator's public key and the certificate. Thus, S/MIME CMS 120 SignedData body can be used for end-to-middle security at the same 121 time as end-to-end security. However, proxy servers usually transfer 122 SIP messages without interpreting the S/MIME bodies. 124 This document mainly discusses requirements for the message 125 confidentiality and integrity of end-to-middle security. Proposed 126 mechanisms are discussed in [9]. 128 2. Problems with the Existing Situations 130 We describe here examples of models in which trusted and 131 partially-trusted proxy servers are mixed along a message path. These 132 situations demonstrate the reasons for requiring end-to-middle 133 security. 135 The following example is that User#1 does not know the features or 136 security policy on Proxy #1. User#1 sends an INVITE request including 137 encrypted SDP for end-to-end security as shown in Figure 1. Proxy #1 138 may reject the request because of the impossibility of offering a 139 firewall traversal feature. Or Proxy#1 may drop the encrypted data 140 based on a security policy that prevents the sending of unknown data. 141 Thus, there is a problem of discovering an intermediary's feature or 142 security policy that may conflict with end-to-end confidentiality. 144 Home network 145 +---------------------+ 146 | +-----+ +-----+ | +-----+ +-----+ 147 User#1------| | C |-----| * |-----| * |-----| C |-- User#2 148 | +-----+ +-----+ | +-----+ +-----+ 149 | UA#1 Proxy#1 | Proxy#2 UA#2 150 +---------------------+ 152 C: Content that UA#1 allows the entity to inspect 153 *: Content that UA#1 prevent the entity from inspecting 155 Figure 1: Deployment example#1 157 In the second example, Proxy server#1 (Proxy#1) is the home proxy 158 server of User#1 using UA#1. User#1 communicates with User#2 through 159 Proxy#1 and Proxy#2 as shown in Figure 2. UA#1 already knows the 160 public key certificate of Proxy#1, and it allows Proxy#1 to inspect 161 the message bodies in a request for some purpose. However, User#1 162 does not know whether Proxy#2 is trustworthy, and thus wants to 163 protect the message bodies in the request. Thus, there is the 164 problem of granting a trusted intermediary permission to inspect 165 message bodies while preserving their confidentiality with respect to 166 other intermediaries. 168 Even if UA#1's request message authorizes a selected proxy (Proxy#1) 169 to see the message body, UA#1 is unable to authorize the same proxy 170 to see the message body in the response from UA#2. Thus, there is the 171 problem of designating and sharing a key that can be reused as a CEK 172 for bidirectional exchanges of S/MIME-secured messages within SIP. 174 Home network 175 +---------------------+ 176 | +-----+ +-----+ | +-----+ +-----+ 177 User#1------| | C |-----| C |-----| * |-----| C |-- User#2 178 | +-----+ +-----+ | +-----+ +-----+ 179 | UA#1 Proxy#1 | Proxy#2 UA#2 180 +---------------------+ 182 C: Content that UA#1 needs to disclose 183 *: Content that UA#1 needs to protect 185 Figure 2: Deployment example#2 187 In the third example, User#1 connects UA#1 to a proxy server in a 188 visited network, e.g. a hotspot service or a roaming service. Since 189 User#1 wants to utilize certain home network services, UA#1 connects 190 to a home proxy server, Proxy#1. However, UA#1 must connect to 191 Proxy#1 via the proxy server of the visited network (Proxy A), 192 because User#1 must follow the policy of that network. Proxy A may 193 perform access control based on the destination addresses of calls. 194 As shown in Figure 3, User#1 trusts Proxy A to route requests, but 195 not to inspect the message bodies they contain. User#1 trusts Proxy#1 196 both to route requests and to inspect the message bodies for some 197 purpose. 199 The same problems as in the second example exist. 201 Visited network 202 +---------------------+ 203 | +-----+ +-----+ | +-----+ +-----+ +-----+ 204 User#1 -- | | C |-----| * |-----| C |-----| * |-----| C | 205 | +-----+ +-----+ | +-----+ +-----+ +-----+ 206 | UA#1 Proxy A | Proxy#1 Proxy#2 UA#2 207 +---------------------+ 209 C: Content that UA#1 needs to disclose 210 *: Content that UA#1 needs to protect 212 Figure 3: Deployment example#3 214 3. Requirements for a Solution 216 We describe here requirements for a solution. The requirements are 217 mainly applied for the phase of a dialog creation or sending MESSAGE 218 method. 220 3.1 Requirements from UA's Perspective 222 1. The solution MUST work even with SIP end-to-end encryption for 223 confidentiality service enabled. 225 2. It SHOULD work even with SIP end-to-end integrity service 226 enabled. 228 3. It SHOULD have little impact on the way of a UA handles messages 229 with S/MIME bodies. 231 4. It SHOULD allow a UA to discover which proxy needs to view some 232 data in a request/response for a certain feature. 234 This requirement is for the case that the UA does not know the 235 proxy or domain that provides the feature in advance. 237 5. It SHOULD allow a UA to discover what data in a request/response 238 the proxy needs to view in order to provide the feature. 240 This requirement is for the above case. 242 6. It MUST allow a UA to request selected proxy servers to view 243 selected message bodies. The request itself SHOULD be secure. 245 7. It SHOULD allow a UA to request the UA on the opposite-side to 246 impose the same type of data on the same proxy server. The 247 request itself SHOULD be secure. 249 It is not appropriate for the UA on the opposite-side to have 250 knowledge of the public key certificate of the proxy server on 251 the originating network. This last requirement can be modified 252 into the following: 254 + The solution SHOULD allow a UA to request the opposite-side 255 UA to reuse a content-encryption-key in subsequent messages 256 during a dialog. 258 + It SHOULD allow a UA to request a selected proxy server to 259 keep a content-encryption-key in a message during a dialog. 260 The requests themselves SHOULD be secure. 262 8. It MAY allow a UA to notify the opposite-side UA which proxy 263 needs to view some data in a request/response for the services. 265 9. It MAY allow a UA to notify the opposite-side UA what data the 266 proxy is permitted to view in a request/response for the 267 services. 269 These last two requirements might be applied for a 270 registration phase. 272 3.2 Requirements from Proxy's Perspective 274 1. It SHOULD have no impact on proxy servers that do not provide 275 features based on S/MIME bodies in terms of handling the existing 276 SIP headers. 278 2. It SHOULD have little impact on standardized mechanism of proxy 279 servers that provide features based on S/MIME bodies. 281 When a proxy server receives an S/MIME message, it should be 282 able to quickly and easily determine the need to investigate 283 the S/MIME body. This last requirement can be modified into 284 the following: 286 + It SHOULD allow proxy servers to quickly and easily 287 determine whether to handle S/MIME bodies and, if so, how 288 and which ones. 290 3. It SHOULD allow a proxy to notify a UA its own security policy 291 for a request/response. 293 4. It SHOULD allow a proxy to notify a UA what data in a request/ 294 response is needed in order to provide a feature. 296 4. Security Considerations 298 This documents presents requirements including security viewpoints in 299 Section 3. 301 5. IANA Considerations 303 This document requires no additional considerations. 305 6. Acknowledgments 307 Thanks to Rohan Mahy and Cullen Jennings for their initial support of 308 this concept, and to Jon Peterson, Gonzalo Camarillo, and Sean Olson 309 for their helpful comments. 311 References 313 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 314 Levels", RFC 2119, BCP 14, March 1997. 316 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 317 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 318 Session Initiation Protocol", RFC 3261, June 2002. 320 [3] Allen, C. and T. Dierks, "The TLS Protocol Version 1.0", RFC 321 2246, January 1999. 323 [4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 324 2633, June 1992. 326 [5] Srisuresh, P., Kuthan, J., Rosenberg, J., Brim, S., Molitor, A. 327 and A. Rayhan, "Middlebox communication architecture and 328 framework", RFC 3303, August 2002. 330 [6] Camarillo, G., "Framework for trasnscoding with the Session 331 Initiation Protocol", 332 draft-camarillo-sipping-transc-framework-00.txt (work in 333 progress), August 2003. 335 [7] Campbell, Ed., B., Rosenberg, J., Schulzrinne, H., Huitema, C. 336 and D. Gurle, "Session Initiation Protocol (SIP) Extension for 337 Instant Messaging", RFC 3428, December 2002. 339 [8] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 340 1999. 342 [9] Ono, K. and S. Tachimoto, "End-to-middle security in the 343 Session Initiation Protocol(SIP)", 344 draft-ono-sipping-end2middle-security-00 (work in progress), 345 June 2003. 347 [10] Rosenberg, J., "Requirements for Session Policy for the Session 348 Initiation Protocol (SIP)", 349 draft-ietf-sipping-session-policy-req-00 (work in progress), 350 June 2003. 352 [11] Farrell, S. and S. Turner, "Reuse of CMS Content Encryption 353 Keys", RFC 3185, October 2001. 355 [12] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 356 November 2002. 358 [13] Crocker, D. and P. Overell, "Augmented BNF for Syntax 359 Specifications: ABNF", RFC 2234, November 1997. 361 Authors' Addresses 363 Kumiko Ono 364 Network Service Systems Laboratories 365 NTT Corporation 366 9-11, Midori-Cho 3-Chome 367 Musashino-shi, Tokyo 180-8585 368 Japan 370 EMail: ono.kumiko@lab.ntt.co.jp 372 Shinya Tachimoto 373 Network Service Systems Laboratories 374 NTT Corporation 375 9-11, Midori-Cho 3-Chome 376 Musashino-shi, Tokyo 180-8585 377 Japan 379 EMail: tachimoto.shinya@lab.ntt.co.jp 381 Intellectual Property Statement 383 The IETF takes no position regarding the validity or scope of any 384 intellectual property or other rights that might be claimed to 385 pertain to the implementation or use of the technology described in 386 this document or the extent to which any license under such rights 387 might or might not be available; neither does it represent that it 388 has made any effort to identify any such rights. Information on the 389 IETF's procedures with respect to rights in standards-track and 390 standards-related documentation can be found in BCP-11. Copies of 391 claims of rights made available for publication and any assurances of 392 licenses to be made available, or the result of an attempt made to 393 obtain a general license or permission for the use of such 394 proprietary rights by implementors or users of this specification can 395 be obtained from the IETF Secretariat. 397 The IETF invites any interested party to bring to its attention any 398 copyrights, patents or patent applications, or other proprietary 399 rights which may cover technology that may be required to practice 400 this standard. Please address the information to the IETF Executive 401 Director. 403 Full Copyright Statement 405 Copyright (C) The Internet Society (2003). All Rights Reserved. 407 This document and translations of it may be copied and furnished to 408 others, and derivative works that comment on or otherwise explain it 409 or assist in its implementation may be prepared, copied, published 410 and distributed, in whole or in part, without restriction of any 411 kind, provided that the above copyright notice and this paragraph are 412 included on all such copies and derivative works. However, this 413 document itself may not be modified in any way, such as by removing 414 the copyright notice or references to the Internet Society or other 415 Internet organizations, except as needed for the purpose of 416 developing Internet standards in which case the procedures for 417 copyrights defined in the Internet Standards process must be 418 followed, or as required to translate it into languages other than 419 English. 421 The limited permissions granted above are perpetual and will not be 422 revoked by the Internet Society or its successors or assignees. 424 This document and the information contained herein is provided on an 425 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 426 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 427 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 428 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 429 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 431 Acknowledgement 433 Funding for the RFC Editor function is currently provided by the 434 Internet Society.