idnits 2.17.00 (12 Aug 2021) /tmp/idnits58919/draft-elwell-sip-e164-problem-statement-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 369. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 15, 2008) is 5208 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group J. Elwell 3 Internet-Draft Siemens 4 Intended status: Informational February 15, 2008 5 Expires: August 18, 2008 7 SIP E.164 Problem Statement 8 draft-elwell-sip-e164-problem-statement-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 18, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 SIP has long supported the use of both email-style addresses 42 (user@host) and telephone-style addresses (number@host) in the 43 "From:" address. A significant number of SIP deployments use the 44 latter style with E.164 numbers. This document describes the 45 problems that occur when such E.164 numbers are used in SIP. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Domain part of a SIP URI . . . . . . . . . . . . . . . . . 3 52 2.2. E.164 numbers as From: URIs . . . . . . . . . . . . . . . . 4 53 2.3. Authenticating a From: URI . . . . . . . . . . . . . . . . 5 54 2.4. Using a received From: URI . . . . . . . . . . . . . . . . 5 55 3. Summary of problem . . . . . . . . . . . . . . . . . . . . . . 6 56 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 60 8. Informative References . . . . . . . . . . . . . . . . . . . . 7 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 Intellectual Property and Copyright Statements . . . . . . . . . . 9 64 1. Introduction 66 The use of phone numbers with SIP was introduced with the TEL URL 67 scheme [RFC3966]. In particular, this covered the use of E.164 68 numbers [ITU.E164.1991], as used in the public switched telephone 69 network (PSTN). In RFC 3966, domain names were not used with fully- 70 qualified E.164 phone numbers. 72 SIP URIs always have domain names. In SIP [RFC3261], a translation 73 between SIP URIs and TEL URLs was described. When translating from a 74 SIP URI to a TEL URL, the domain name from the SIP URI is simply 75 dropped. When translating in the other direction (or simply 76 generating a SIP URI from an E.164 number) it is not clear how to 77 populate the domain name. 79 2. Discussion 81 2.1. Domain part of a SIP URI 83 When an E.164 number is represented as a SIP URI, it includes a 84 domain part. Unfortunately there is no clear definition of what the 85 domain part should contain. On the one hand, it is clear that, in 86 common with any SIP URI, the domain denoted by the domain part should 87 at least be able to route the request onwards towards the 88 destination. Therefore if a SIP URI containing an E.164 number is 89 the target of a SIP request, the request can be routed to the domain 90 given in the domain part and that domain will be able to route the 91 request onwards. 93 However, this still leaves scope for putting different values into 94 the domain part, subject to the identified domain being able to route 95 requests onwards towards their correct destinations. It has been 96 suggested that the domain part should be the domain that "owns" the 97 E.164 number, but the concept of ownership is unclear. Does an 98 enterprise domain "own" the E.164 numbers assigned to it? Does a 99 public service provider "own" the E.164 numbers assigned to an 100 enterprise that it serves? What if the enterprise obtains services 101 associated with these numbers from multiple public service providers? 102 Does a service provider "own" E.164 numbers assigned to an end user? 103 Who is the "owner" in number portability situations? 105 In practice, for a given E.164 number, different domain names tend to 106 be used, although such use is perhaps not the original intent of 107 [RFC3261]. For example, a service provider might always use its own 108 domain name, regardless of whether the URI represents a number 109 assigned to one of its users, a number assigned to a different 110 service provider but served by that first service provider, or some 111 other number. A service provider that hosts enterprise users might 112 use the service provider's own domain name rather than that of the 113 hosted enterprise. An ENUM look-up on an E.164 number might yield a 114 SIP URI with a domain via which the user of that number can be 115 reached, but not necessarily the end domain of the user. When E.164 116 numbers are represented as SIP URIs in fields of SIP messages, the 117 domain part often changes as the message progresses through different 118 domains. These considerations have a number of consequences. 120 2.2. E.164 numbers as From: URIs 122 When a UA receives an E.164 number represented as a SIP URI in a From 123 header field, what does this say about the source of the request? Of 124 course, it should indicate that the request originated at a user who 125 has a right to use that E.164 number and who can be reached by 126 submitting a request targeted at that E.164 number. However, the 127 domain part means very little. At the most it means that the request 128 has, at some stage, passed through the domain, and that a return 129 request to that E.164 number can be routed via that domain. The 130 request did not necessarily originate at that domain, but could 131 simply have transited that domain. For example, a request could 132 originate with the following From URI: 134 sip:+123456789@example1.com;user=phone 136 The request then passes through the service provider domain 137 example2.com, which changes it to: 139 sip:+123456789@example2.com;user=phone 141 Furthermore the domain in the received From URI is not necessarily 142 the "owner" of that E.164 number. 144 Similar considerations apply to E.164 numbers received as SIP URIs in 145 the P-Asserted-Identity header field [RFC3325]. 147 In the PSTN world there is a concept of user-provided and network- 148 provided caller numbers. The two can differ when the user-provided 149 number has been provided by an enterprise network (PBX) and denotes 150 the particular enterprise user, whereas the network-provided number 151 (the only one that the public network is able to authenticate) is the 152 default number for the enterprise. It depends on the particular 153 operator whether a network delivers the user-provided number, the 154 network-provided number of both to the called user. The user- 155 provided number is more useful for making a return call. If a SIP 156 service provider modifies the From URI to provide the equivalent of a 157 network-provided number, the domain part might no longer reflect the 158 true identity of the originator of the request. 160 2.3. Authenticating a From: URI 162 SIP Identity [RFC4474] provides a means of authenticating a SIP URI 163 in the From header field. The Identity header field contains a 164 signature that can be generated only by the domain that appears in 165 the SIP URI in the From header field. This means the request must 166 have originated at or passed through that domain. If a domain 167 changes the From URI, any existing Identity signature will be 168 invalidated and should be removed, but of course that domain can 169 insert its own Identity signature, signing the new From URI. 171 Note that although changing the From URI can be a reason for 172 generating a new Identity signature, also the converse is true. An 173 Identity signature can be invalidated because other signed 174 information (e.g., IP addresses and ports in SDP) has changed, and 175 because a domain can sign only when its own domain name is in the 176 From URI, it must change the From URI before signing. 178 2.4. Using a received From: URI 180 Even when authenticated, a received From URI can only indicate a 181 domain through which a request has passed, not necessarily the domain 182 in which it has originated. This can be an issue if the UAS expects 183 it to indicate a particular originating domain but in fact it 184 indicates the domain of an intermediate service provider. For 185 example: 187 Suppose the UAS has a white list of particular URIs or domains 188 from which it accepts communications. The domain at which a 189 request originated might be in the white list, but if the From URI 190 indicates another domain through which the request passed, the 191 check against the white list might fail. 193 Requests from the same originating domain but all routed through 194 different intermediate domains might all arrive with different 195 From URIs. Attempts to correlate these requests will probably 196 fail. 198 Any attempt by a UAS to correlate a received URI with that of a 199 known communication partner and as a result provide relevant 200 information to the user will fail if URIs are compared but the 201 domain part of the received URI is different from that expected. 203 If a user expects a particular communication to be to/from a 204 particular domain (e.g., the user's bank), yet the authenticated 205 From URI in an received request indicates a service provider's 206 domain, the user might not be prepared to proceed with that 207 communication, or might proceed but withhold information of a 208 sensitive nature. 210 Some of these issues can be resolved if the domain part is ignored 211 and only the E.164 number is used for comparison. However, the last 212 of these issues is a far more serious problem: the user expects a 213 communication partner to be from a particular domain (the E.164 214 number is not necessarily an important factor). Seeing that domain 215 in the From: URI, coupled with authentication by means of the 216 Identity header field, would satisfy the user's expectation. Seeing 217 a different domain, that of an intermediate service provider, which 218 may or may not be known to the user, would not satisfy the user's 219 expectation. The user might not be prepared to accept the unexpected 220 URI and might decide not to proceed with the communication. 222 This last point is particularly important when the media are to be 223 secured using SRTP. As a basis for this security, the communication 224 partner with which encrypted and integrity-protected RTP packets are 225 exchanged must be authenticated as the expected or an acceptable 226 communication partner. If this involves knowing the domain of the 227 communication partner, then it is important that the From URI 228 indicates the domain of the partner and not that of some intermediate 229 service provider. If the Identity signature also covers the 230 fingerprint of the certificate used by the partner for establishing 231 SRTP keys, then this binds the secure media stream to the From URI. 232 If the From URI is not acceptable, the media stream cannot be 233 regarded as secure. 235 3. Summary of problem 237 A SIP URI containing an E.164 number received in a From header field 238 is not a reliable source domain of a request, even when authenticated 239 by means of the Identity header field. Only the E.164 number itself 240 can be considered reliable, and only the E.164 itself is suitable for 241 comparing with known identities at the destination (e.g., in a white 242 list, in an address book). The inability to depend on the domain 243 part of an E.164 SIP URI is a serious deficiency in some situations. 245 4. Requirements 247 A solution addressing the problem must satisfy the following 248 requirements: 250 REQ1: When a UAS receives a SIP request originated by a user 251 identified by an E.164 number, the UAS must receive a SIP or SIPS 252 URI containing that E.164 number and containing the originator's 253 domain in the domain part. 255 REQ2: When a UAS receives a SIP request that includes a SIP or SIPS 256 URI identifying the originating user, if that URI contains an 257 E.164 number that number alone, when placed in a TEL URI, must be 258 suitable for routing a request back to the originating user. 260 REQ3: When a UAS receives a SIP request that includes a SIP or SIPS 261 URI identifying the originating user, if that URI contains an 262 E.164 number and the originating domain it must be possible to 263 include in the request cryptographic evidence from that 264 originating domain that binds secure media to that SIP URI. 266 REQ1 is in principle met by the From URI, but not if it is modified 267 by intermediate domains between the originating domain and the UAS. 268 Obviously elimination of such practices would in theory be sufficient 269 to satisfy REQ1, but this might not be achievable. Therefore it 270 might require new techniques. 272 REQ2 requires new techniques. 274 REQ3 can in theory be met by the Identity header field, but this is 275 true only if intermediate domains do not modify the From URI or other 276 signed information, such as IP addresses and ports in SDP (these are 277 often changed by Session Border Controllers, SBCs) and contact URIs 278 (these too are often changed by SBCs and other B2BUAs). Therefore to 279 solve this in a way that will work in most practical situations 280 requires new techniques. 282 5. IANA Considerations 284 None; this document is informational. 286 6. Security Considerations 288 [[This section will be completed in a later version of this 289 document.]] 291 7. Acknowledgements 293 The author thanks Dan Wing for encouraging the writing of this 294 document. 296 8. Informative References 298 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 299 Authenticated Identity Management in the Session 300 Initiation Protocol (SIP)", RFC 4474, August 2006. 302 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 303 A., Peterson, J., Sparks, R., Handley, M., and E. 304 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 305 June 2002. 307 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 308 RFC 3966, December 2004. 310 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 311 Extensions to the Session Initiation Protocol (SIP) for 312 Asserted Identity within Trusted Networks", RFC 3325, 313 November 2002. 315 [ITU.E164.1991] 316 International Telecommunications Union, "The International 317 Public Telecommunication Numbering Plan", ITU- 318 T Recommendation E.164, 1991. 320 Author's Address 322 John Elwell 323 Siemens Enterprise Communications GmbH & Co KG 324 Hofmannstrasse 51 325 D-81379 Munich 326 Germany 328 Phone: +44 115 943 4989 329 Email: john.elwell@siemens.com 331 Full Copyright Statement 333 Copyright (C) The IETF Trust (2008). 335 This document is subject to the rights, licenses and restrictions 336 contained in BCP 78, and except as set forth therein, the authors 337 retain all their rights. 339 This document and the information contained herein are provided on an 340 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 341 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 342 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 343 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 344 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 345 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 347 Intellectual Property 349 The IETF takes no position regarding the validity or scope of any 350 Intellectual Property Rights or other rights that might be claimed to 351 pertain to the implementation or use of the technology described in 352 this document or the extent to which any license under such rights 353 might or might not be available; nor does it represent that it has 354 made any independent effort to identify any such rights. Information 355 on the procedures with respect to rights in RFC documents can be 356 found in BCP 78 and BCP 79. 358 Copies of IPR disclosures made to the IETF Secretariat and any 359 assurances of licenses to be made available, or the result of an 360 attempt made to obtain a general license or permission for the use of 361 such proprietary rights by implementers or users of this 362 specification can be obtained from the IETF on-line IPR repository at 363 http://www.ietf.org/ipr. 365 The IETF invites any interested party to bring to its attention any 366 copyrights, patents or patent applications, or other proprietary 367 rights that may cover technology that may be required to implement 368 this standard. Please address the information to the IETF at 369 ietf-ipr@ietf.org. 371 Acknowledgment 373 Funding for the RFC Editor function is provided by the IETF 374 Administrative Support Activity (IASA).